RE: [Patch, microblaze]: Add support for TLS in MicroBlaze

[David Holsgrove]

Hi Michael,

> -Original Message-
> From: Michael Eager [mailto:ea...@eagerm.com]
> Sent: Thursday, 14 March 2013 1:34 am
> To: David Holsgrove
> Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail;
> Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui
> Subject: Re: [Patch, microblaze]: Add support for TLS in MicroBlaze
> 
> On 03/12/2013 01:47 PM, David Holsgrove wrote:
> > Add support for thread local storage (general dynamic and local dynamic
> models) in MicroBlaze.
> >
> >
> > gcc/Changelog
> >
> > 2013-03-13  Edgar E. Iglesias 
> >  David Holsgrove 
> >
[--snip--]
> >
> > Signed-off-by: Edgar E. Iglesias 
> > Signed-off-by: David Holsgrove 
> 
> Hi David --
> 
> The patch is OK except for a number of minor formatting problems to meet GNU
> standards.
> - Comments are supposed to end with ".  */".
> - Extra spacing around parens or between "!" and "TARGET...".
> - && or || at start of line continuing a condition rather that at end of 
> previous line
> - Some places where the indenting is incorrect
> 

Thanks for the review, we inherited some of the style deviations when basing off
of other archs TLS functions I'm afraid. I've fixed the formatting in v2 of the 
patch
attached.

> Should this patch be combined with the other patch adding TLS checking to
> configure?
> 

I've combined both patches into the attached - looking back at the ARM TLS patch
it was submitted this way, so we'll follow precedence there if that’s okay with
you.

Updated Changelog would be;

2013-03-14 Edgar E. Iglesias 
   David Holsgrove 

 * configure.ac: Add MicroBlaze TLS support detection.
 * configure: Regenerate.
 * config/microblaze/microblaze-protos.h: (microblaze_cannot_force_const_mem,
   microblaze_tls_referenced_p, symbol_mentioned_p,
   label_mentioned_p): Add prototypes.
 * config/microblaze/microblaze.c (microblaze_address_type): Add ADDRESS_TLS
   and tls_reloc address types.
   (microblaze_address_info): Add tls_reloc.
   (TARGET_HAVE_TLS): Define.
   (get_tls_get_addr, microblaze_tls_symbol_p, microblaze_tls_operand_p_1,
microblaze_tls_referenced_p, microblaze_cannot_force_const_mem,
symbol_mentioned_p, label_mentioned_p, tls_mentioned_p, load_tls_operand,
microblaze_call_tls_get_addr, microblaze_legitimize_tls_address): New 
functions.
   (microblaze_classify_unspec): Handle UNSPEC_TLS.
   (get_base_reg): Use microblaze_tls_symbol_p.
   (microblaze_classify_address): Handle TLS.
   (microblaze_legitimate_pic_operand): Use symbol_mentioned_p, 
label_mentioned_p
and microblaze_tls_referenced_p.
   (microblaze_legitimize_address): Handle TLS.
   (microblaze_address_insns): Handle ADDRESS_TLS.
   (pic_address_needs_scratch): Handle TLS.
   (print_operand_address): Handle TLS.
   (microblaze_expand_prologue): Check TLS_NEEDS_GOT.
   (microblaze_expand_move): Handle TLS.
   (microblaze_legitimate_constant_p): Check microblaze_cannot_force_const_mem
and microblaze_tls_symbol_p.
   (TARGET_CANNOT_FORCE_CONST_MEM): Define.
 * config/microblaze/microblaze.h (TLS_NEEDS_GOT): Define
   (PIC_OFFSET_TABLE_REGNUM): Set.
 * config/microblaze/linux.h (TLS_NEEDS_GOT): Define.
 * config/microblaze/microblaze.md (UNSPEC_TLS): Define.
   (addsi3, movsi_internal2, movdf_internal): Update constraints
 * config/microblaze/predicates.md (arith_plus_operand): Define
   (move_operand): Redefine as move_src_operand, check 
microblaze_tls_referenced_p.

Signed-off-by: Edgar E. Iglesias 
Signed-off-by: David Holsgrove 


thanks again,
David

> 
> --
> Michael Eager  ea...@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077





0001-Patch-microblaze-Add-support-for-TLS-in-MicroBlaze.patch
Description: 0001-Patch-microblaze-Add-support-for-TLS-in-MicroBlaze.patch

Re: [PATCH] Fix -print-multi-os-directory for aarch64

[Marcus Shawcroft]

On 8 March 2013 09:32, Jakub Jelinek  wrote:
> On Fri, Mar 08, 2013 at 09:04:19AM +, Marcus Shawcroft wrote:
>> On 07/03/13 16:45, Jakub Jelinek wrote:
>> >On Thu, Mar 07, 2013 at 08:29:06AM -0800, Andrew Pinski wrote:
>> >>On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek  wrote:
>> >>>AFAIK aarch64 libraries are supposed to go into /usr/lib64 etc.
>> >>>directories similarly to x86-64 etc., but as aarch64 isn't a true
>> >>>multilib target (having two different backends for 32-bit vs. 64-bit 
>> >>>code),
>> >>>currently gcc -print-multi-os-directory prints . instead of ../lib64.
>> >>
>> >>I think glibc is broken also. So after this change, the build using
>> >>the released 2.17 and this new gcc breaks.
>> >
>> >Then glibc will need patching too.  Distros using multiarch aren't affected
>> >by this, others IMHO will want it in */lib64 and for aarch64 IMHO it isn't
>> >still too late for that change.
>>
>> Hi, Moving from /lib to /lib64 will affect binutils 2.23 (ld) and
>> glibc 2.17.  This seems to me to be a rather disruptive change this
>> late in the day.
>
> Yes, it does affect them, on the binutils side it would be about
> setting LIBPATH_SUFFIX=64 in ld/emulparams/aarch64linux.sh when appropriate
> (grep LIBPATH_SUFFIX=64 ld/emulparams/*.sh to see what other targets do),
> on the glibc side for other targets sysdeps/gnu/configure.in
> is where libc_cv_slibdir and libc_cv_libdir are tweaked.
> Note, this change doesn't affect multiarch, so Debian/Ubuntu is unaffected,
> for others there can be an easy workaround for transitional period
> (just add */lib64 -> */lib symlinks (or vice versa)).
> The point of using */lib64 is that it is consistent with how most other
> important 64-bit architectures are handled (x86_64, ppc64, s390x, sparc64,
> mips64) and that even if you don't expect coexistence of 32-bit arm and
> 64-bit aarch64 libraries on the same filesystem right now, using */lib64
> allows that in the future.  Even if some distros use lib64 -> lib or vice
> versa symlinks for some time if they choose so, if there is agreement to go
> with lib64 path suffixes, it means packages that need to know this can be
> changed, rather than adding horrible hacks to see what library suffixes
> should be used.

My concern about the disruption associated with this change aside, I
agree that the change needs to happen in order to avoid long term
pain.  I see no objections on this thread or the related thread over
at glibc-ports, so go ahead and commit the patch.

/Marcus

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Richard Biener]

On Wed, 13 Mar 2013, Diego Novillo wrote:

> This patch adds an initial implementation for a new helper type for
> generating GIMPLE statements.
> 
> The type is called gimple_builder.  There are two main variants:
> gimple_builder_normal and gimple_builder_ssa.  The difference between
> the two is the temporaries they create.  The 'normal' builder creates
> temporaries in normal form (i.e., VAR_DECLs).  The 'ssa' builder
> creates SSA names.
> 
> The basic functionality is described in
> http://gcc.gnu.org/wiki/cxx-conversion/gimple-generation.  I expect it
> to evolve as I address feedback on this initial implementation.
> 
> The patch implements the initial builder.  It has enough functionality
> to simplify the generation of 3 address assignments (the bulk of all
> generated code).
> 
> To use the builder:
> 
> 1- Declare an instance 'gb' of gimple_builder_normal or
>gimple_builder_ssa.  E.g., gimple_builder_ssa gb;
> 
> 2- Use gb.add_* to add a new statement to it.  This
>returns an SSA name or VAR_DECL with the value of the added
>statement.
> 
> 3- Call gb.insert_*() to insert the sequence of statements in the
>builder into a statement iterator.
> 
> For instance, in asan.c we generate the expression:
> 
> (shadow != 0) & (base_addr & 7) + (size_in_bytes - 1)) >= shadow).
> 
> with the following code:
> 
> -
>   gimple_builder_ssa gb(location);
>   t = gb.add (NE_EXPR, shadow, 0);
>   tree t1 = gb.add (BIT_AND_EXPR, base_addr, 7);
>   t1 = gb.add_type_cast (shadow_type, t1);
>   if (size_in_bytes > 1)
>   t1 = gb.add (PLUS_EXPR, t1, size_in_bytes - 1);
>   t1 = gb.add (GE_EXPR, t1, shadow);
>   t = gb.add (BIT_AND_EXPR, t, t1);
>   gb.insert_after (&gsi, GSI_NEW_STMT);
> -
> 
> 
> In contrast, the original code needed to generate the same expression
> is significantly longer:

May I propose instead to first (we'll then see whether the facility
you propose still makes sense) beat some C++ sense into the
existing gimple-assign building?  Like using overloading to be able
to say

g = gimple_build_assign (gsi, NE_EXPR, auto (), shadow, 0);
g2 = gimple_build_assign (gsi, BIT_AND_EXPR, auto (), base_addr, 7);
g = gimple_build_assign (gsi, NOP_EXPR, auto (), g2);

?  Or to get static number of argument checking make it a template on the
operation code.

That is, try to do as much as you do with your facility with the
core interface first.

Please.

Instead of using special objects to select an overload that creates
a new SSA name that could be done with overloading on the number of
arguments, too.  Instead of passing a gsi you could pass a sequence, too,
or the stmt to append after.

Note that all the automatic type inference you do, like for

t1 = gb.add (PLUS_EXPR, t1, size_in_bytes - 1)

is of course a recipie for problems.

That's why I would be very much more comfortable with seeing
incremental improvements to the existing interface (and features
added) than a whole new facility that is not very much used
which just dumps a whole lot of new "features" on us.

Thanks,
Richard.


> -
>   g = gimple_build_assign_with_ops (NE_EXPR,
>   make_ssa_name (boolean_type_node,
>  NULL),
>   shadow,
>   build_int_cst (shadow_type, 0));
>   gimple_set_location (g, location);
>   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
>   t = gimple_assign_lhs (g);
> 
>   g = gimple_build_assign_with_ops (BIT_AND_EXPR,
>   make_ssa_name (uintptr_type,
>  NULL),
>   base_addr,
>   build_int_cst (uintptr_type, 7));
>   gimple_set_location (g, location);
>   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> 
>   g = gimple_build_assign_with_ops (NOP_EXPR,
>   make_ssa_name (shadow_type,
>  NULL),
>   gimple_assign_lhs (g), NULL_TREE);
>   gimple_set_location (g, location);
>   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
>   if (size_in_bytes > 1)
>   {
> g = gimple_build_assign_with_ops (PLUS_EXPR,
>   make_ssa_name (shadow_type,
>  NULL),
>   gimple_assign_lhs (g),
>   build_int_cst (shadow_type,
>  size_in_bytes - 1));
> gimple_set_lo

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Richard Biener]

On Wed, 13 Mar 2013, Xinliang David Li wrote:

> Nice -- GCC LOC will be significantly reduced with these interfaces.
> 
> Using 'add' as interface name can be confusing -- new, or new_stmt, or
> new_assignment/new_call etc might be better -- but we can delay the
> bike shedding later.

Note that we already have a perfectly working "short" interface for this.

  t = force_gimple_operand_gsi (... fold_build ())

where you can in one place construct a recursive tree.

Richard.

> David.
> 
> On Wed, Mar 13, 2013 at 2:55 PM, Diego Novillo  wrote:
> > This patch adds an initial implementation for a new helper type for
> > generating GIMPLE statements.
> >
> > The type is called gimple_builder.  There are two main variants:
> > gimple_builder_normal and gimple_builder_ssa.  The difference between
> > the two is the temporaries they create.  The 'normal' builder creates
> > temporaries in normal form (i.e., VAR_DECLs).  The 'ssa' builder
> > creates SSA names.
> >
> > The basic functionality is described in
> > http://gcc.gnu.org/wiki/cxx-conversion/gimple-generation.  I expect it
> > to evolve as I address feedback on this initial implementation.
> >
> > The patch implements the initial builder.  It has enough functionality
> > to simplify the generation of 3 address assignments (the bulk of all
> > generated code).
> >
> > To use the builder:
> >
> > 1- Declare an instance 'gb' of gimple_builder_normal or
> >gimple_builder_ssa.  E.g., gimple_builder_ssa gb;
> >
> > 2- Use gb.add_* to add a new statement to it.  This
> >returns an SSA name or VAR_DECL with the value of the added
> >statement.
> >
> > 3- Call gb.insert_*() to insert the sequence of statements in the
> >builder into a statement iterator.
> >
> > For instance, in asan.c we generate the expression:
> >
> > (shadow != 0) & (base_addr & 7) + (size_in_bytes - 1)) >= shadow).
> >
> > with the following code:
> >
> > -
> >   gimple_builder_ssa gb(location);
> >   t = gb.add (NE_EXPR, shadow, 0);
> >   tree t1 = gb.add (BIT_AND_EXPR, base_addr, 7);
> >   t1 = gb.add_type_cast (shadow_type, t1);
> >   if (size_in_bytes > 1)
> > t1 = gb.add (PLUS_EXPR, t1, size_in_bytes - 1);
> >   t1 = gb.add (GE_EXPR, t1, shadow);
> >   t = gb.add (BIT_AND_EXPR, t, t1);
> >   gb.insert_after (&gsi, GSI_NEW_STMT);
> > -
> >
> >
> > In contrast, the original code needed to generate the same expression
> > is significantly longer:
> >
> >
> > -
> >   g = gimple_build_assign_with_ops (NE_EXPR,
> > make_ssa_name (boolean_type_node,
> >NULL),
> > shadow,
> > build_int_cst (shadow_type, 0));
> >   gimple_set_location (g, location);
> >   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> >   t = gimple_assign_lhs (g);
> >
> >   g = gimple_build_assign_with_ops (BIT_AND_EXPR,
> > make_ssa_name (uintptr_type,
> >NULL),
> > base_addr,
> > build_int_cst (uintptr_type, 7));
> >   gimple_set_location (g, location);
> >   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> >
> >   g = gimple_build_assign_with_ops (NOP_EXPR,
> > make_ssa_name (shadow_type,
> >NULL),
> > gimple_assign_lhs (g), NULL_TREE);
> >   gimple_set_location (g, location);
> >   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> >   if (size_in_bytes > 1)
> > {
> >   g = gimple_build_assign_with_ops (PLUS_EXPR,
> > make_ssa_name (shadow_type,
> >NULL),
> > gimple_assign_lhs (g),
> > build_int_cst (shadow_type,
> >size_in_bytes - 
> > 1));
> >   gimple_set_location (g, location);
> >   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> > }
> >
> >   g = gimple_build_assign_with_ops (GE_EXPR,
> > make_ssa_name (boolean_type_node,
> >NULL),
> > gimple_assign_lhs (g),
> > shadow);
> >   gimple_set_location (g, location);
> >   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> >

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Richard Biener]

On Thu, 14 Mar 2013, Richard Biener wrote:

> On Wed, 13 Mar 2013, Diego Novillo wrote:
> 
> > This patch adds an initial implementation for a new helper type for
> > generating GIMPLE statements.
> > 
> > The type is called gimple_builder.  There are two main variants:
> > gimple_builder_normal and gimple_builder_ssa.  The difference between
> > the two is the temporaries they create.  The 'normal' builder creates
> > temporaries in normal form (i.e., VAR_DECLs).  The 'ssa' builder
> > creates SSA names.
> > 
> > The basic functionality is described in
> > http://gcc.gnu.org/wiki/cxx-conversion/gimple-generation.  I expect it
> > to evolve as I address feedback on this initial implementation.
> > 
> > The patch implements the initial builder.  It has enough functionality
> > to simplify the generation of 3 address assignments (the bulk of all
> > generated code).
> > 
> > To use the builder:
> > 
> > 1- Declare an instance 'gb' of gimple_builder_normal or
> >gimple_builder_ssa.  E.g., gimple_builder_ssa gb;
> > 
> > 2- Use gb.add_* to add a new statement to it.  This
> >returns an SSA name or VAR_DECL with the value of the added
> >statement.
> > 
> > 3- Call gb.insert_*() to insert the sequence of statements in the
> >builder into a statement iterator.
> > 
> > For instance, in asan.c we generate the expression:
> > 
> > (shadow != 0) & (base_addr & 7) + (size_in_bytes - 1)) >= shadow).
> > 
> > with the following code:
> > 
> > -
> >   gimple_builder_ssa gb(location);
> >   t = gb.add (NE_EXPR, shadow, 0);
> >   tree t1 = gb.add (BIT_AND_EXPR, base_addr, 7);
> >   t1 = gb.add_type_cast (shadow_type, t1);
> >   if (size_in_bytes > 1)
> > t1 = gb.add (PLUS_EXPR, t1, size_in_bytes - 1);
> >   t1 = gb.add (GE_EXPR, t1, shadow);
> >   t = gb.add (BIT_AND_EXPR, t, t1);
> >   gb.insert_after (&gsi, GSI_NEW_STMT);
> > -
> > 
> > 
> > In contrast, the original code needed to generate the same expression
> > is significantly longer:
> 
> May I propose instead to first (we'll then see whether the facility
> you propose still makes sense) beat some C++ sense into the
> existing gimple-assign building?  Like using overloading to be able
> to say
> 
> g = gimple_build_assign (gsi, NE_EXPR, auto (), shadow, 0);
> g2 = gimple_build_assign (gsi, BIT_AND_EXPR, auto (), base_addr, 7);
> g = gimple_build_assign (gsi, NOP_EXPR, auto (), g2);
> 
> ?  Or to get static number of argument checking make it a template on the
> operation code.
> 
> That is, try to do as much as you do with your facility with the
> core interface first.
> 
> Please.
> 
> Instead of using special objects to select an overload that creates
> a new SSA name that could be done with overloading on the number of
> arguments, too.  Instead of passing a gsi you could pass a sequence, too,
> or the stmt to append after.
> 
> Note that all the automatic type inference you do, like for
> 
> t1 = gb.add (PLUS_EXPR, t1, size_in_bytes - 1)
> 
> is of course a recipie for problems.

That said - can we please pass in the type of the operation (and thus
the newly created result temporary) _explicitely_ please?  Thus

   gimple_builder_ssa gb(location);
   t = gb.add (NE_EXPR, boolean_type_node, shadow, 0);
   tree t1 = gb.add (BIT_AND_EXPR, TREE_TYPE (base_addr), base_addr, 
7);
   t1 = gb.add_type_cast (shadow_type, t1);
   if (size_in_bytes > 1)
   t1 = gb.add (PLUS_EXPR, TREE_TYPE (t1), t1, size_in_bytes - 1);
   t1 = gb.add (GE_EXPR, boolean_type_node, t1, shadow);
   t = gb.add (BIT_AND_EXPR, boolean_type_node, t, t1);
   gb.insert_after (&gsi, GSI_NEW_STMT);

we are writing a compiler after all, not some web javascript code.

Richard.

> That's why I would be very much more comfortable with seeing
> incremental improvements to the existing interface (and features
> added) than a whole new facility that is not very much used
> which just dumps a whole lot of new "features" on us.
> 
> Thanks,
> Richard.
> 
> 
> > -
> >   g = gimple_build_assign_with_ops (NE_EXPR,
> > make_ssa_name (boolean_type_node,
> >NULL),
> > shadow,
> > build_int_cst (shadow_type, 0));
> >   gimple_set_location (g, location);
> >   gsi_insert_after (&gsi, g, GSI_NEW_STMT);
> >   t = gimple_assign_lhs (g);
> > 
> >   g = gimple_build_assign_with_ops (BIT_AND_EXPR,
> > make_ssa_name (uintptr_type,
> >NULL),
> > base_addr,
> > build_int_cst (u

Re: [PATCH] Introduce -Waggressive-loop-optimizations (PR tree-optimization/53265)

[Richard Biener]

On Wed, 13 Mar 2013, Jakub Jelinek wrote:

> Hi!
> 
> This patch is an attempt to warn about undefined behavior in simple loops
> with known constant number of latch executions, which probably is the most
> common case where gcc 4.8 started to turn finite loops involving undefined
> behavior before reaching last iteration into endless loops.
> 
> Of course the patch doesn't guarantee warning for all such mistakes, and for
> loops without known constant number of latch executions it is question on
> what exactly we should warn about.  Honza has some prototype patch, perhaps
> that could be done if loop->warned_aggressive_loop_optimizations is still
> false.
> 
> To avoid false positives in some cases (e.g. exp_ch7.adb during bootstrap),
> I had to start warning only later on (with the advantage that at that point
> loops are preserved and thus we can set flag in the loop structure whether
> we've warned already).
> 
> I had to tweak a couple of testcases (pr49518.c clearly can result in
> undefined behavior conditionally, longbranch2.C also had obvious undefined
> behavior (I've verified that r8 cc1plus generated exactly same size and
> insn type code with original and fixed testcase, the only thing that
> differed were immediates in some instructions due to different field sizes).
> In cunroll-10.c we no longer do anything as it had known constant number of
> latch executions, thus no undefined behavior discovery is performed.
> In libgcc, the DW_CFA_GNU_window_save handling code was hardcoding SPARC
> register window setup, but that is also undefined behavior on targets that
> have fewer than 32 DWARF_FRAME_REGISTERS.  I've just shut it up there, after
> all DW_CFA_GNU_window_save is only ever used on SPARC anyway.
> 
> I've bootstrapped/regtested the patch together with a debugging patch to
> show where the last hunk in estimate_numbers_of_iterations_loop actually
> changed anything.  It happened in
> ../../gcc/ada/exp_ch7.adb:3540 (see the PR, in dead code), we'd need a
> copyprop pass with cfgcleanup before cunrolli to avoid that,
> then in {sse4_2,avx}-vpcmp{i,e}strm-{1,2}.c
> /usr/src/gcc/gcc/testsuite/gcc.target/i386/sse4_2-pcmpstr.h:339
> (reduced testcase -O2:
> short t[8];
> static inline void bar (int x, int y)
> {
>   short s[8]; int i, d = (x & 1) == 0 ? 16 : 8;
>   if (x & 0x40) for (i = 0; i < d; i++) if (d == 8) s[i] = (y & (1 << i)) ? 
> -1 : 0;
>   __builtin_memcpy (t, s, sizeof s);
> }
> void foo (int y)
> {
>   bar (0x26, y);
> }
> ) - here number_of_latch_iterations returns 0, apparently because it finds
> out that the loop will be never executed.
> Then gcc.dg/torture/pr49518.c:11 (see above, ok) and gcc.dg/pr53265.c
> (expected, many).  So, I think we're fine.
> 
> Ok for 4.8?

Looks good to me.

Ok,

Thanks,
Richard.

> 2013-03-13  Jakub Jelinek  
> 
>   PR tree-optimization/53265
>   * common.opt (Waggressive-loop-optimizations): New option.
>   * tree-ssa-loop-niter.c: Include tree-pass.h.
>   (do_warn_aggressive_loop_optimizations): New function.
>   (record_estimate): Call it.  Don't add !is_exit bounds to loop->bounds
>   if number_of_latch_executions returned constant.
>   (estimate_numbers_of_iterations_loop): Call number_of_latch_executions
>   early.  If number_of_latch_executions returned constant, set
>   nb_iterations_upper_bound back to it.
>   * cfgloop.h (struct loop): Add warned_aggressive_loop_optimizations
>   field.
>   * Makefile.in (tree-ssa-loop-niter.o): Depend on $(TREE_PASS_H).
>   * doc/invoke.texi (-Wno-aggressive-loop-optimizations): Document.
> 
>   * gcc.dg/pr53265.c: New test.
>   * gcc.dg/torture/pr49518.c: Add -Wno-aggressive-loop-optimizations
>   to dg-options.
>   * g++.dg/opt/longbranch2.C (EBCOTLut): Double sizes of a2 and a3
>   arrays.
>   * gcc.dg/tree-ssa/cunroll-10.c (main): Rename to foo.  Add argument
>   n, use it as high bound instead of 4.
> 
>   * unwind-dw2.c (execute_cfa_program): Avoid
>   -Waggressive-array-optimizations warnings for DW_CFA_GNU_window_save
>   on targets with DWARF_FRAME_REGISTERS < 32.
> 
>   * testsuite/libmudflap.c/fail37-frag.c: Add optimization barrier.
> 
> --- gcc/common.opt.jj 2013-03-12 09:59:34.692099982 +0100
> +++ gcc/common.opt2013-03-12 13:47:08.922161154 +0100
> @@ -505,6 +505,10 @@ Waggregate-return
>  Common Var(warn_aggregate_return) Warning
>  Warn about returning structures, unions or arrays
>  
> +Waggressive-loop-optimizations
> +Common Var(warn_aggressive_loop_optimizations) Init(1) Warning
> +Warn if a loop with constant number of iterations triggers undefined behavior
> +
>  Warray-bounds
>  Common Var(warn_array_bounds) Warning
>  Warn if an array is accessed out of bounds
> --- gcc/tree-ssa-loop-niter.c.jj  2013-03-12 09:59:34.740099692 +0100
> +++ gcc/tree-ssa-loop-niter.c 2013-03-13 11:19:02.100060913 +0100
> @@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.
>  #include "f

Re: [PATCH][IRA] Analysis of register usage of functions for usage by IRA.

[Tom de Vries]

On 13/02/13 23:35, Vladimir Makarov wrote:
> On 13-02-07 2:11 PM, Tom de Vries wrote:
>> Vladimir,
>>
>> On 25/01/13 16:36, Vladimir Makarov wrote:
>>> On 01/25/2013 08:05 AM, Tom de Vries wrote:
 Vladimir,

 this patch adds analysis of register usage of functions for usage by IRA.

 The patch:
 - adds analysis in pass_final to track which hard registers are set or 
 clobbered
 by the function body, and stores that information in a struct 
 cgraph_node.
 - adds a target hook fn_other_hard_reg_usage to list hard registers that 
 are
 set or clobbered by a call to a function, but are not listed as such 
 in the
 function body, such as f.i. registers clobbered by veneers inserted by 
 the
 linker.
 - adds a reg-note REG_CALL_DECL, to be able to easily link call_insns to 
 their
 corresponding declaration, even after the calls may have been split 
 into an
 insn (set register to function address) and a call_insn (call 
 register), which
 can happen for f.i. sh, and mips with -mabi-calls.
 - uses the register analysis in IRA.
 - adds an option -fuse-caller-save to control the optimization, on by 
 default
 at -Os and -O2 and higher.
>> 
>>
 Bootstrapped and reg-tested on x86_64, Ada inclusive. Build and reg-tested 
 on
 mips, arm, ppc and sh. No issues found. OK for stage1 trunk?


>>> Thanks for the patch.  I'll look at it during the next week.
>>>
>> Did you get a chance to look at this?
> Sorry for the delay with the answer.  I was and am quite busy with other 
> more urgent things.  I'll work on it when I have more free time.  In any 
> case, I'll do it before stage1 to have your patch ready.

Vladimir,

do you have an ETA on this review?

>>> Right now I see that the code is based on reload which uses
>>> caller-saves.c.  LRA does not use caller-saves.c at all.  Right now we
>>> have LRA support only for x86/x86-64 but the next version will probably
>>> have a few more targets based on LRA.  Fortunately, LRA modification
>>> will be pretty easy with all this machinery.
>>>
>> I see, thanks for noticing that. Btw I'm now working on a testsuite construct
>> dg-size-compare to be able to do
>>dg-size-compare "text" "-fuse-caller-save" "<" "-fno-use-caller-save"
>> which I could have used to create a generic testcase, which would have
>> demonstrated that the optimization didn't work for x86_64.
> I thought about implementing your optimization for LRA by myself. But it 
> is ok if you decide to work on it.  At least, I am not going to start 
> this work for a month.
>> I'm also currently looking at how to use the analysis in LRA.
>> AFAIU, in lra-constraints.c we do a backward scan over the insns, and keep 
>> track
>> of how many calls we've seen (calls_num), and mark insns with that number. 
>> Then
>> when looking at a live-range segment consisting of a def or use insn a and a
>> following use insn b, we can compare the number of calls seen for each insn, 
>> and
>> if they're not equal there is at least one call between the 2 insns, and if 
>> the
>> corresponding hard register is clobbered by calls, we spill after insn a and
>> restore before insn b.
>>
>> That is too coarse-grained to use with our analysis, since we need to know 
>> which
>> calls occur in between insn a and insn b, and more precisely which registers
>> those calls clobbered.
> 
>> I wonder though if we can do something similar: we keep an array
>> call_clobbers_num[FIRST_PSEUDO_REG], initialized at 0 when we start scanning.
>> When encountering a call, we increase the call_clobbers_num entries for the 
>> hard
>> registers clobbered by the call.
>> When encountering a use, we set the call_clobbers_num field of the use to
>> call_clobbers_num[reg_renumber[original_regno]].
>> And when looking at a live-range segment, we compare the clobbers_num field 
>> of
>> insn a and insn b, and if it is not equal, the hard register was clobbered 
>> by at
>> least one call between insn a and insn b.
>> Would that work? WDYT?
>>
> As I understand you looked at live-range splitting code in 
> lra-constraints.c.  To get necessary info you should look at ira-lives.c.

Unfortunately I haven't been able to find time to work further on the LRA part.
So if you're still willing to pick up that part, that would be great.

Thanks,
- Tom

[committed] Fix up graphite tests for PR53265

[Jakub Jelinek]

Hi!

Usually I bootstrap/regtest without graphite, so haven't seen these 3 test
FAILs with my recent patch.  Fixed thusly, tested on x86_64-linux, committed
to trunk as obvious.

2013-03-14  Jakub Jelinek  

PR tree-optimization/53265
* gcc.dg/graphite/scop-3.c (toto): Increase array size to avoid
undefined behavior.
* gcc.dg/graphite/id-6.c (test): Likewise.
* gcc.dg/graphite/pr35356-2.c: Adjust regexp patterns to only look for
MIN_EXPR and MAX_EXPR in GIMPLE stmts.

--- gcc/testsuite/gcc.dg/graphite/scop-3.c.jj   2009-08-03 09:42:19.0 
+0200
+++ gcc/testsuite/gcc.dg/graphite/scop-3.c  2013-03-14 11:37:25.719648369 
+0100
@@ -1,7 +1,7 @@
 int toto()
 {
   int i, j, k;
-  int a[100][100];
+  int a[100][200];
   int b[100];
 
   for (i = 1; i < 100; i++)
--- gcc/testsuite/gcc.dg/graphite/id-6.c.jj 2009-08-03 09:42:19.0 
+0200
+++ gcc/testsuite/gcc.dg/graphite/id-6.c2013-03-14 11:37:36.628586994 
+0100
@@ -2,7 +2,7 @@
 void foo (int);
 int test ()
 {
-  int a[N];
+  int a[N + 8];
   unsigned i;
 
   for (i = 0; i < N; i++)
--- gcc/testsuite/gcc.dg/graphite/pr35356-2.c.jj2011-02-15 
15:31:56.0 +0100
+++ gcc/testsuite/gcc.dg/graphite/pr35356-2.c   2013-03-14 11:47:54.655777100 
+0100
@@ -39,6 +39,6 @@ foo (int bar, int n, int k)
 */
 
 
-/* { dg-final { scan-tree-dump-times "MIN_EXPR" 4 "graphite" } } */
-/* { dg-final { scan-tree-dump-times "MAX_EXPR" 4 "graphite" } } */
+/* { dg-final { scan-tree-dump-times "MIN_EXPR\[^\\n\\r]*;" 4 "graphite" } } */
+/* { dg-final { scan-tree-dump-times "MAX_EXPR\[^\\n\\r]*;" 4 "graphite" } } */
 /* { dg-final { cleanup-tree-dump "graphite" } } */

Jakub

Re: [wwwdocs] gcc-4.8/porting_to.html

[Alexander Monakov]

It still references memcpy in -Wsizeof-pointer-memaccess section.  Let me
suggest instead:

To fix, properly pass the size of cleared memory as the last argument:
either dereference the pointer argument to sizeof when clearing *one
pointed-to element*, or in addition to that multiply sizeof(*p) by the
number of elements to clear in the pointed-to array (which may not be
known at the point of memset call without additional code changes).



I suppose a good chunk of problematic code hitting this warning would be doing
something like:

void foo(int a[])
{
  memset(a, 0, sizeof(a));
}

... in which case dereferencing a in sizeof is probably the wrong thing to do.


Alexander

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Michael Matz]

Hi,

On Thu, 14 Mar 2013, Richard Biener wrote:

> That said - can we please pass in the type of the operation (and thus 
> the newly created result temporary) _explicitely_ please?  Thus

I'm mostly with you (not adding gimple_builder_ssa, but improving the 
existing interface), except for this one.  Most of the unary and binary 
arithmetic and logical operations will have the the type of the first 
argument as result type.  Spelling that out adds useless noise, so it 
shuoldn't be required.  We'd need some good way to specify a type for the 
rest that makes sure that you can't use the easy way with those tree 
codes.


Ciao,
Michael.

Re: [wwwdocs] gcc-4.8/porting_to.html

[Jakub Jelinek]

On Thu, Mar 14, 2013 at 03:07:36PM +0400, Alexander Monakov wrote:
> 
> It still references memcpy in -Wsizeof-pointer-memaccess section.  Let me
> suggest instead:
> 
> To fix, properly pass the size of cleared memory as the last argument:
> either dereference the pointer argument to sizeof when clearing *one
> pointed-to element*, or in addition to that multiply sizeof(*p) by the
> number of elements to clear in the pointed-to array (which may not be
> known at the point of memset call without additional code changes).
> 
> 
> 
> I suppose a good chunk of problematic code hitting this warning would be doing
> something like:
> 
> void foo(int a[])
> {
>   memset(a, 0, sizeof(a));
> }
> 
> ... in which case dereferencing a in sizeof is probably the wrong thing to do.

The has different wording for the different cases, can suggest you to
1) remove addressof
2) provide an explicit length
3) dereference it

E.g. 1) is for cases like memset (&a, 0, sizeof (&a)); where removing the &
is usually the right thing to do.

Jakub

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Michael Matz]

Hi,

On Wed, 13 Mar 2013, Diego Novillo wrote:

> To use the builder:
> 
> 1- Declare an instance 'gb' of gimple_builder_normal or
>gimple_builder_ssa.  E.g., gimple_builder_ssa gb;
> 
> 2- Use gb.add_* to add a new statement to it.  This
>returns an SSA name or VAR_DECL with the value of the added
>statement.
> 
> 3- Call gb.insert_*() to insert the sequence of statements in the
>builder into a statement iterator.

I'm reiterating everything I said in 
  http://gcc.gnu.org/ml/gcc/2012-11/msg00230.html
Actually your interface now is worse than what Lawrence proposed back in 
November in that the add_* methods return a tree, instead of a gimple 
statement.

I haven't seen any convincing reason why the builder class is necessary, 
instead of improving the current interface.  IOW I don't like it much.


Ciao,
Michael.

[Patch, AArch64] Implement framework for Tree/Gimple Implementation of NEON intrinsics.

[Tejas Belagod]

Hi,

Attached is a patch that implements the framework necessary for implementing
NEON Intrinsics' builtins in Tree/Gimple rather than RTL. For this it uses the
target hook TARGET_FOLD_BUILTIN and folds all the builtins for NEON Intrinsics
into equivalent trees. This framework is accompanied by an example
implementation of vaddv_f<32, 64> intrinsics using the framework.

Regression tested on aarch64-none-elf. OK for trunk?

Thanks,
Tejas Belagod
ARM.

Changelog:

2013-03-14  Tejas Belagod  

gcc/
* config/aarch64/aarch64-builtins.c (aarch64_fold_builtin): New.
* config/aarch64/aarch64-protos.h (aarch64_fold_builtin): Declare.
* config/aarch64/aarch64-simd-builtins.def: New entry for reduc_splus.
* config/aarch64/aarch64.c (TARGET_FOLD_BUILTIN): Define.
* config/aarch64/arm_neon.h (vaddv_f32, vaddvq_f32, vaddvq_f64): New.

testsuite/
* gcc.target/aarch64/vaddv-intrinsic-compile.c: New.
* gcc.target/aarch64/vaddv-intrinsic.c: New.diff --git a/gcc/config/aarch64/aarch64-builtins.c 
b/gcc/config/aarch64/aarch64-builtins.c
index 35475ba..a1bd032 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -1254,6 +1254,31 @@ aarch64_builtin_vectorized_function (tree fndecl, tree 
type_out, tree type_in)
 
   return NULL_TREE;
 }
+
+#undef VAR1
+#define VAR1(T, N, MAP, A) \
+  case AARCH64_SIMD_BUILTIN_##N##A:
+
+tree
+aarch64_fold_builtin (tree fndecl, int n_args ATTRIBUTE_UNUSED, tree *args,
+ bool ignore ATTRIBUTE_UNUSED)
+{
+  int fcode = DECL_FUNCTION_CODE (fndecl);
+  tree type = TREE_TYPE (TREE_TYPE (fndecl));
+
+  switch (fcode)
+{
+  BUILTIN_VDQF (UNOP, reduc_splus_, 10)
+   return fold_build1 (REDUC_PLUS_EXPR, type, args[0]);
+   break;
+
+  default:
+   break;
+}
+
+  return NULL_TREE;
+}
+
 #undef AARCH64_CHECK_BUILTIN_MODE
 #undef AARCH64_FIND_FRINT_VARIANT
 #undef BUILTIN_DX
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 5d0072f..1bb33e8 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -177,6 +177,7 @@ rtx aarch64_simd_gen_const_vector_dup (enum machine_mode, 
int);
 bool aarch64_simd_mem_operand_p (rtx);
 rtx aarch64_simd_vect_par_cnst_half (enum machine_mode, bool);
 rtx aarch64_tls_get_addr (void);
+tree aarch64_fold_builtin (tree, int, tree *, bool);
 unsigned aarch64_dbx_register_number (unsigned);
 unsigned aarch64_trampoline_size (void);
 void aarch64_asm_output_labelref (FILE *, const char *);
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
b/gcc/config/aarch64/aarch64-simd-builtins.def
index e18e3f3..1dd4ad6 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -238,6 +238,9 @@
   BUILTIN_VDQF (BINOP, fmax, 0)
   BUILTIN_VDQF (BINOP, fmin, 0)
 
+  /* Implemented by reduc_splus_.  */
+  BUILTIN_VDQF (UNOP, reduc_splus_, 10)
+
   /* Implemented by 3.  */
   BUILTIN_VDQ_BHSI (BINOP, smax, 3)
   BUILTIN_VDQ_BHSI (BINOP, smin, 3)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 45c4106..156c20e 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7829,6 +7829,9 @@ aarch64_vectorize_vec_perm_const_ok (enum machine_mode 
vmode,
 #undef TARGET_EXPAND_BUILTIN_VA_START
 #define TARGET_EXPAND_BUILTIN_VA_START aarch64_expand_builtin_va_start
 
+#undef TARGET_FOLD_BUILTIN
+#define TARGET_FOLD_BUILTIN aarch64_fold_builtin
+
 #undef TARGET_FUNCTION_ARG
 #define TARGET_FUNCTION_ARG aarch64_function_arg
 
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 5e25c77..6198f99 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -19731,6 +19731,29 @@ vaddd_u64 (uint64x1_t __a, uint64x1_t __b)
   return __a + __b;
 }
 
+/* vaddv */
+
+__extension__ static __inline float32_t __attribute__ ((__always_inline__))
+vaddv_f32 (float32x2_t __a)
+{
+  float32x2_t t = __builtin_aarch64_reduc_splus_v2sf (__a);
+  return vget_lane_f32 (t, 0);
+}
+
+__extension__ static __inline float32_t __attribute__ ((__always_inline__))
+vaddvq_f32 (float32x4_t __a)
+{
+  float32x4_t t = __builtin_aarch64_reduc_splus_v4sf (__a);
+  return vgetq_lane_f32 (t, 0);
+}
+
+__extension__ static __inline float64_t __attribute__ ((__always_inline__))
+vaddvq_f64 (float64x2_t __a)
+{
+  float64x2_t t = __builtin_aarch64_reduc_splus_v2df (__a);
+  return vgetq_lane_f64 (t, 0);
+}
+
 /* vceq */
 
 __extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
diff --git a/gcc/testsuite/gcc.target/aarch64/vaddv-intrinsic-compile.c 
b/gcc/testsuite/gcc.target/aarch64/vaddv-intrinsic-compile.c
new file mode 100644
index 000..c736c0d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/vaddv-intrinsic-compile.c
@@ -0,0 +1,36 @@
+
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+#include "arm_neon.h"
+
+float32_t
+tes

[AArch64, Patch] Implement framework for Tree/Gimple Implementation of NEON intrinsics.

[Tejas Belagod]

Hi,

Attached is a patch that implements the framework necessary for implementing
NEON Intrinsics' builtins in Tree/Gimple rather than RTL. For this it uses the
target hook TARGET_FOLD_BUILTIN and folds all the builtins for NEON Intrinsics
into equivalent trees. This framework is accompanied by an example
implementation of vaddv_f<32, 64> intrinsics using the framework.

Regression tested on aarch64-none-elf. OK for trunk?

Thanks,
Tejas Belagod
ARM.

2013-03-14  Tejas Belagod  

gcc/
* config/aarch64/aarch64-builtins.c (aarch64_fold_builtin): New.
* config/aarch64/aarch64-protos.h (aarch64_fold_builtin): Declare.
* config/aarch64/aarch64-simd-builtins.def: New entry for reduc_splus.
* config/aarch64/aarch64.c (TARGET_FOLD_BUILTIN): Define.
* config/aarch64/arm_neon.h (vaddv_f32, vaddvq_f32, vaddvq_f64): New.

testsuite/
* gcc.target/aarch64/vaddv-intrinsic-compile.c: New.
* gcc.target/aarch64/vaddv-intrinsic.c: New.diff --git a/gcc/config/aarch64/aarch64-builtins.c 
b/gcc/config/aarch64/aarch64-builtins.c
index 35475ba..a1bd032 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -1254,6 +1254,31 @@ aarch64_builtin_vectorized_function (tree fndecl, tree 
type_out, tree type_in)
 
   return NULL_TREE;
 }
+
+#undef VAR1
+#define VAR1(T, N, MAP, A) \
+  case AARCH64_SIMD_BUILTIN_##N##A:
+
+tree
+aarch64_fold_builtin (tree fndecl, int n_args ATTRIBUTE_UNUSED, tree *args,
+ bool ignore ATTRIBUTE_UNUSED)
+{
+  int fcode = DECL_FUNCTION_CODE (fndecl);
+  tree type = TREE_TYPE (TREE_TYPE (fndecl));
+
+  switch (fcode)
+{
+  BUILTIN_VDQF (UNOP, reduc_splus_, 10)
+   return fold_build1 (REDUC_PLUS_EXPR, type, args[0]);
+   break;
+
+  default:
+   break;
+}
+
+  return NULL_TREE;
+}
+
 #undef AARCH64_CHECK_BUILTIN_MODE
 #undef AARCH64_FIND_FRINT_VARIANT
 #undef BUILTIN_DX
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 5d0072f..1bb33e8 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -177,6 +177,7 @@ rtx aarch64_simd_gen_const_vector_dup (enum machine_mode, 
int);
 bool aarch64_simd_mem_operand_p (rtx);
 rtx aarch64_simd_vect_par_cnst_half (enum machine_mode, bool);
 rtx aarch64_tls_get_addr (void);
+tree aarch64_fold_builtin (tree, int, tree *, bool);
 unsigned aarch64_dbx_register_number (unsigned);
 unsigned aarch64_trampoline_size (void);
 void aarch64_asm_output_labelref (FILE *, const char *);
diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def 
b/gcc/config/aarch64/aarch64-simd-builtins.def
index e18e3f3..1dd4ad6 100644
--- a/gcc/config/aarch64/aarch64-simd-builtins.def
+++ b/gcc/config/aarch64/aarch64-simd-builtins.def
@@ -238,6 +238,9 @@
   BUILTIN_VDQF (BINOP, fmax, 0)
   BUILTIN_VDQF (BINOP, fmin, 0)
 
+  /* Implemented by reduc_splus_.  */
+  BUILTIN_VDQF (UNOP, reduc_splus_, 10)
+
   /* Implemented by 3.  */
   BUILTIN_VDQ_BHSI (BINOP, smax, 3)
   BUILTIN_VDQ_BHSI (BINOP, smin, 3)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 45c4106..156c20e 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7829,6 +7829,9 @@ aarch64_vectorize_vec_perm_const_ok (enum machine_mode 
vmode,
 #undef TARGET_EXPAND_BUILTIN_VA_START
 #define TARGET_EXPAND_BUILTIN_VA_START aarch64_expand_builtin_va_start
 
+#undef TARGET_FOLD_BUILTIN
+#define TARGET_FOLD_BUILTIN aarch64_fold_builtin
+
 #undef TARGET_FUNCTION_ARG
 #define TARGET_FUNCTION_ARG aarch64_function_arg
 
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 5e25c77..6198f99 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -19731,6 +19731,29 @@ vaddd_u64 (uint64x1_t __a, uint64x1_t __b)
   return __a + __b;
 }
 
+/* vaddv */
+
+__extension__ static __inline float32_t __attribute__ ((__always_inline__))
+vaddv_f32 (float32x2_t __a)
+{
+  float32x2_t t = __builtin_aarch64_reduc_splus_v2sf (__a);
+  return vget_lane_f32 (t, 0);
+}
+
+__extension__ static __inline float32_t __attribute__ ((__always_inline__))
+vaddvq_f32 (float32x4_t __a)
+{
+  float32x4_t t = __builtin_aarch64_reduc_splus_v4sf (__a);
+  return vgetq_lane_f32 (t, 0);
+}
+
+__extension__ static __inline float64_t __attribute__ ((__always_inline__))
+vaddvq_f64 (float64x2_t __a)
+{
+  float64x2_t t = __builtin_aarch64_reduc_splus_v2df (__a);
+  return vgetq_lane_f64 (t, 0);
+}
+
 /* vceq */
 
 __extension__ static __inline uint8x8_t __attribute__ ((__always_inline__))
diff --git a/gcc/testsuite/gcc.target/aarch64/vaddv-intrinsic-compile.c 
b/gcc/testsuite/gcc.target/aarch64/vaddv-intrinsic-compile.c
new file mode 100644
index 000..c736c0d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/vaddv-intrinsic-compile.c
@@ -0,0 +1,36 @@
+
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+#include "arm_neon.h"
+
+float32_t
+test_vaddv_v2s

C++ PATCH for c++/56614 (bogus error with initializer list in default argument)

[Jason Merrill]

Removing the DECL_ARTIFICIAL check meant warning about TARGET_EXPR 
temporaries, which we don't want; instead, let's check for 'this' directly.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2139bd24c219d1b665738d2b630e90dd25cc9cd1
Author: Jason Merrill 
Date:   Thu Mar 14 08:35:24 2013 -0400

	PR c++/56614
	* decl.c (local_variable_p_walkfn): Check DECL_ARTIFICIAL again.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 92114ff..0e66840 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10803,9 +10803,8 @@ static tree
 local_variable_p_walkfn (tree *tp, int *walk_subtrees,
 			 void * /*data*/)
 {
-  /* Check DECL_NAME to avoid including temporaries.  We don't check
- DECL_ARTIFICIAL because we do want to complain about 'this'.  */
-  if (local_variable_p (*tp) && DECL_NAME (*tp))
+  if (local_variable_p (*tp)
+  && (!DECL_ARTIFICIAL (*tp) || DECL_NAME (*tp) == this_identifier))
 return *tp;
   else if (TYPE_P (*tp))
 *walk_subtrees = 0;
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-defarg1.C b/gcc/testsuite/g++.dg/cpp0x/initlist-defarg1.C
new file mode 100644
index 000..45eb2d5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-defarg1.C
@@ -0,0 +1,36 @@
+// PR c++/56614
+// { dg-require-effective-target c++11 }
+
+#include 
+
+namespace std
+{
+template
+struct allocator
+{ };
+
+template >
+struct vector
+{
+vector(std::initializer_list, const Alloc& = Alloc()) { }
+};
+}
+
+void func() { }
+
+enum E { ee };
+
+struct C
+{
+template
+C(T, std::vector = std::vector({ ee }))
+{ }
+};
+
+struct G
+{
+void gen()
+{
+C c(&func);
+}
+};

[PATCH][0/n] tree LIM TLC - series part for backporting, limit LIM

[Richard Biener]

This extracts pieces from the already posted patch series that are
most worthwhile and applicable for backporting to both 4.8 and 4.7.
It also re-implements the limiting of the maximum number of memory
references to consider for LIMs dependence analysis.  This limiting
is now done per loop-nest and disables optimizing outer loops
only.  The limiting requires backporting introduction of the
shared unalalyzable mem-ref - it works by marking that as stored
in loops we do not want to compute dependences for - which makes
dependence computation for mems in those loops linear, as that
mem-ref, which conveniently has ID 0, is tested first.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

The current limit of 1000 datarefs is quite low (well, for LIMs
purposes, that is), and I only bothered to care about -O1 for
backports (no caching of the affine combination).  With the
limit in place and at -O1 LIM now takes

 tree loop invariant motion:   0.55 ( 1%) usr

for the testcase in PR39326.  Four patches in total, we might
consider not backporting the limiting, without it this
insane testcase has, at ~2GB memory usage (peak determined by IRA)

 tree loop invariant motion: 533.30 (77%) usr

but avoids running into the DSE / combine issue (and thus stays
managable overall at -O1).  With limiting it requires -fno-dse
to not blow up (>5GB of memory use).

Richard.

2013-03-12  Richard Biener  

PR tree-optimization/39326
* tree-ssa-loop-im.c (refs_independent_p): Exploit symmetry.

Index: trunk/gcc/tree-ssa-loop-im.c
===
--- trunk.orig/gcc/tree-ssa-loop-im.c   2013-03-14 12:36:28.881446232 +0100
+++ trunk/gcc/tree-ssa-loop-im.c2013-03-14 12:36:49.808682841 +0100
@@ -2255,15 +2255,26 @@ ref_always_accessed_p (struct loop *loop
 static bool
 refs_independent_p (mem_ref_p ref1, mem_ref_p ref2)
 {
-  if (ref1 == ref2
-  || bitmap_bit_p (ref1->indep_ref, ref2->id))
+  if (ref1 == ref2)
 return true;
-  if (bitmap_bit_p (ref1->dep_ref, ref2->id))
-return false;
+
   if (!MEM_ANALYZABLE (ref1)
   || !MEM_ANALYZABLE (ref2))
 return false;
 
+  /* Reference dependence in a loop is symmetric.  */
+  if (ref1->id > ref2->id)
+{
+  mem_ref_p tem = ref1;
+  ref1 = ref2;
+  ref2 = tem;
+}
+
+  if (bitmap_bit_p (ref1->indep_ref, ref2->id))
+return true;
+  if (bitmap_bit_p (ref1->dep_ref, ref2->id))
+return false;
+
   if (dump_file && (dump_flags & TDF_DETAILS))
 fprintf (dump_file, "Querying dependency of refs %u and %u: ",
 ref1->id, ref2->id);
@@ -2272,7 +2283,6 @@ refs_independent_p (mem_ref_p ref1, mem_
&memory_accesses.ttae_cache))
 {
   bitmap_set_bit (ref1->dep_ref, ref2->id);
-  bitmap_set_bit (ref2->dep_ref, ref1->id);
   if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "dependent.\n");
   return false;
@@ -2280,7 +2290,6 @@ refs_independent_p (mem_ref_p ref1, mem_
   else
 {
   bitmap_set_bit (ref1->indep_ref, ref2->id);
-  bitmap_set_bit (ref2->indep_ref, ref1->id);
   if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "independent.\n");
   return true;


2013-03-14  Richard Biener  

PR tree-optimization/39326
* tree-ssa-loop-im.c (struct mem_ref): Replace mem member with
ao_ref typed member.
(MEM_ANALYZABLE): Adjust.
(memref_eq): Likewise.
(mem_ref_alloc): Likewise.
(gather_mem_refs_stmt): Likewise.
(mem_refs_may_alias_p): Use the ao_ref to query the alias oracle.
(execute_sm_if_changed_flag_set): Adjust.
(execute_sm): Likewise.
(ref_always_accessed_p): Likewise.
(refs_independent_p): Likewise.
(can_sm_ref_p): Likewise.

Index: trunk/gcc/tree-ssa-loop-im.c
===
*** trunk.orig/gcc/tree-ssa-loop-im.c   2013-03-14 12:36:49.0 +0100
--- trunk/gcc/tree-ssa-loop-im.c2013-03-14 12:43:16.180191012 +0100
*** typedef struct mem_ref_locs
*** 117,126 
  
  typedef struct mem_ref
  {
-   tree mem;   /* The memory itself.  */
unsigned id;/* ID assigned to the memory reference
   (its index in memory_accesses.refs_list)  */
hashval_t hash; /* Its hash value.  */
bitmap stored;  /* The set of loops in that this memory location
   is stored to.  */
vec accesses_in_loop;
--- 117,130 
  
  typedef struct mem_ref
  {
unsigned id;/* ID assigned to the memory reference
   (its index in memory_accesses.refs_list)  */
hashval_t hash; /* Its hash value.  */
+ 
+   /* The memory access itself and associated caching of alias-oracle
+  query meta-data.  */
+   ao_r

[C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

[James Greenhalgh]

Hi,

As it stands, potential_constant_expression_1 does not handle
REDUC_PLUS_EXPR trees.

For some cross-lane add-reduce neon intrinsics we would like to
use the TARGET_FOLD_BUILTIN hook to fold these calls to a
REDUC_PLUS_EXPR. As an example, see Tejas Belagod's patch at:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00502.html

If we do that, the C++11 front-end is not able to evaluate
them as a potential constant expression and we get an
"unexpected AST of kind REDUC_PLUS_EXPR" error.

I am about as far from a C++11 expert as you can get, so I
don't know whether this is the correct fix, but to my naieve
mind I don't see why REDUC_PLUS_EXPR is different from any
other unary operator...

I have tested the patch on aarch64-none-elf with no regressions,
and it fixed the problem I was seeing previously.

Is this OK to commit to 4.9 when stage 1 opens up?

Thanks,
James Greenhalgh

---
gcc/cp/

* semantics.c
(potential_constant_expression_1): Add case for REDUC_PLUS_EXPR.diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 9446f83..232057a 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -8600,6 +8600,7 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
 case ABS_EXPR:
 case TRUTH_NOT_EXPR:
 case FIXED_CONVERT_EXPR:
+case REDUC_PLUS_EXPR:
 case UNARY_PLUS_EXPR:
   return potential_constant_expression_1 (TREE_OPERAND (t, 0), rval,
 	  flags);

Re: [1/2] Document HLE / RTM intrinsics

[Uros Bizjak]

Hello!

> >> >From: Andi Kleen 
> >>
> >> >+Returns _XBEGIN_STARTED when the transaction
> >> >+started successfully (not this is not 0, so the constant has to be
> >>
> >> not this is not 0? Or note?
> >
> > "note"
> >
> > Thanks. Will fix before comitting.
>
> I think (somewhere else) we agreed to only document intrinsics,
> not the __builtin_ia32_ variants (they are an implementation detail).
> Yes, we're not consistent with that, but we do miss a lot of
> documentation for these kind of builtins.  I suppose we also do not
> document all intrinsics either (though that's desired, as we provide
> those headers - even manpages would be nice for them I suppose).
>
> Target maintainers?

The proposed documentation does mention that these intrinsics are for
internal use only.

I think that the patch in its latest version is OK

Thanks,
Uros.

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Marc Glisse]

On Wed, 13 Mar 2013, Diego Novillo wrote:


This patch adds an initial implementation for a new helper type for
generating GIMPLE statements.


I hope you'll forgive the naive newbie question: why is the gimplifier 
used so little outside of the gimplification pass? For instance, after a 
call to fold in a gimple pass, we test valid_gimple_rhs_p and give up if 
it returns false, instead of trying to gimplify whatever fold returned. 
The connection with your patch is that generic trees are easier to build 
than gimple statements, so for a long expression one could imagine 
building a tree and having a single gimplification call at the end (the 
time wasted should be quite limited).


(Note that I encourage the efforts to simplify the gimple interface, I am 
just taking the occasion to ask a vaguely related question)


--
Marc Glisse

Re: [PATCH][IRA] Analysis of register usage of functions for usage by IRA.

[Vladimir Makarov]

On 03/14/2013 05:34 AM, Tom de Vries wrote:

On 13/02/13 23:35, Vladimir Makarov wrote:


Sorry for the delay with the answer.  I was and am quite busy with other
more urgent things.  I'll work on it when I have more free time.  In any
case, I'll do it before stage1 to have your patch ready.

Vladimir,

do you have an ETA on this review?


Actually, I am done with it.  In general, it is ok.  Although I have 
some minors comments:


In Changelog, you missed '*" before cgraph.h:

* haifa-sched.c (recompute_todo_spec, check_clobbered_conditions): Add
new argument to find_all_hard_reg_sets call.
cgraph.h (struct cgraph_node): Add function_used_regs,
function_used_regs_initialized and function_used_regs_valid fields.


@@ -3391,6 +3394,7 @@ df_get_call_refs (struct df_collection_r
 }
 }
   else if (TEST_HARD_REG_BIT (regs_invalidated_by_call, i)

I'd remove the test of regs_invalidated_by_call.

+   && TEST_HARD_REG_BIT (fn_reg_set_usage, i)
/* no clobbers for regs that are the result of the call */
&& !TEST_HARD_REG_BIT (defs_generated, i)

+static void
+collect_fn_hard_reg_usage (void)
+{
+  rtx insn;
+  int i;
+  struct cgraph_node *node;
+  struct hard_reg_set_container other_usage;
+
+  if (!flag_use_caller_save)
+return;
+
+  node = cgraph_get_node (current_function_decl);
+  gcc_assert (node != NULL);
+
+  gcc_assert (!node->function_used_regs_initialized);
+  node->function_used_regs_initialized = 1;
+
+  for (insn = get_insns (); insn != NULL_RTX; insn = next_insn (insn))
+{
+  HARD_REG_SET insn_used_regs;
+
+  if (!NONDEBUG_INSN_P (insn))
+continue;
+
+  find_all_hard_reg_sets (insn, &insn_used_regs, false);
+
+  if (CALL_P (insn)
+  && !get_call_reg_set_usage (insn, &insn_used_regs, 
call_used_reg_set))

+{
+  CLEAR_HARD_REG_SET (node->function_used_regs);
+  return;
+}
+

I'd put it before find_all_hard_reg_sets

+  IOR_HARD_REG_SET (node->function_used_regs, insn_used_regs);
+}
+



But you can ignore my two last 2 comments.

The patch is ok for me for trunk at stage1.  But I think you need a 
formal approval for df-scan.c, arm.c, mips.c, GCC testsuite expect files 
(lib/target-supports.exp and gcc.target/mips/mips.exp) as I am not a 
maintainer of these parts although these changes look ok for me.


Thanks for your hard work and sorry for the review delay.

I guess you need to pay attention to reported problems for some time 
after you commit the patch as it affects all targets.

[PATCH, AArch64] Support EXTR in backend

[Ian Bolton]

We couldn't generate EXTR for AArch64 ... until now!

This patch includes the pattern and a test.

Full regression testing for Linux and bare-metal passed.

OK for trunk stage-1?

Thanks,
Ian


2013-03-14  Ian Bolton  

gcc/
* config/aarch64/aarch64.md (*extr5_insn): New pattern.
(*extrsi5_insn_uxtw): Likewise.

testsuite/
* gcc.target/aarch64/extr.c: New test.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 73d86a7..ef1c0f3 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -2703,6 +2703,34 @@
(set_attr "mode" "")]
 )
 
+(define_insn "*extr5_insn"
+  [(set (match_operand:GPI 0 "register_operand" "=r")
+   (ior:GPI (ashift:GPI (match_operand:GPI 1 "register_operand" "r")
+(match_operand 3 "const_int_operand" "n"))
+(lshiftrt:GPI (match_operand:GPI 2 "register_operand" "r")
+  (match_operand 4 "const_int_operand" "n"]
+  "UINTVAL (operands[3]) < GET_MODE_BITSIZE (mode) &&
+   (UINTVAL (operands[3]) + UINTVAL (operands[4]) == GET_MODE_BITSIZE 
(mode))"
+  "extr\\t%0, %1, %2, %4"
+  [(set_attr "v8type" "shift")
+   (set_attr "mode" "")]
+)
+
+;; zero_extend version of the above
+(define_insn "*extrsi5_insn_uxtw"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (zero_extend:DI
+(ior:SI (ashift:SI (match_operand:SI 1 "register_operand" "r")
+   (match_operand 3 "const_int_operand" "n"))
+(lshiftrt:SI (match_operand:SI 2 "register_operand" "r")
+ (match_operand 4 "const_int_operand" "n")]
+  "UINTVAL (operands[3]) < 32 &&
+   (UINTVAL (operands[3]) + UINTVAL (operands[4]) == 32)"
+  "extr\\t%w0, %w1, %w2, %4"
+  [(set_attr "v8type" "shift")
+   (set_attr "mode" "SI")]
+)
+
 (define_insn "*_ashl"
   [(set (match_operand:GPI 0 "register_operand" "=r")
(ANY_EXTEND:GPI
diff --git a/gcc/testsuite/gcc.target/aarch64/extr.c 
b/gcc/testsuite/gcc.target/aarch64/extr.c
new file mode 100644
index 000..a78dd8d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/extr.c
@@ -0,0 +1,34 @@
+/* { dg-options "-O2 --save-temps" } */
+/* { dg-do run } */
+
+extern void abort (void);
+
+int
+test_si (int a, int b)
+{
+  /* { dg-final { scan-assembler "extr\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+, 27\n" 
} } */
+  return (a << 5) | ((unsigned int) b >> 27);
+}
+
+long long
+test_di (long long a, long long b)
+{
+  /* { dg-final { scan-assembler "extr\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+, 45\n" 
} } */
+  return (a << 19) | ((unsigned long long) b >> 45);
+}
+
+int
+main ()
+{
+  int v;
+  long long w;
+  v = test_si (0x0004, 0x3000);
+  if (v != 0x0086)
+abort();
+  w = test_di (0x0001040040040004ll, 0x00700500ll);
+  if (w != 0x2002002000200380ll)
+abort();
+  return 0;
+}
+
+/* { dg-final { cleanup-saved-temps } } */

[PATCH, AArch64] Support ROR in backend

[Ian Bolton]

We couldn't generate ROR (preferred alias of EXTR when both source
registers are the same) for AArch64, when rotating by an immediate,
... until now!

This patch includes the pattern and a test.

Full regression testing for Linux and bare-metal passed.

OK for trunk stage-1?

Thanks,
Ian


2013-03-14  Ian Bolton  

gcc/
* config/aarch64/aarch64.md (*ror3_insn): New pattern.
(*rorsi3_insn_uxtw): Likewise.

testsuite/
* gcc.target/aarch64/ror.c: New test.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index ef1c0f3..367c0e3 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -2731,6 +2731,34 @@
(set_attr "mode" "SI")]
 )
 
+(define_insn "*ror3_insn"
+  [(set (match_operand:GPI 0 "register_operand" "=r")
+   (rotate:GPI (match_operand:GPI 1 "register_operand" "r")
+   (match_operand 2 "const_int_operand" "n")))]
+  "UINTVAL (operands[2]) < GET_MODE_BITSIZE (mode)"
+{
+  operands[3] = GEN_INT ( - UINTVAL (operands[2]));
+  return "ror\\t%0, %1, %3";
+}
+  [(set_attr "v8type" "shift")
+   (set_attr "mode" "")]
+)
+
+;; zero_extend version of the above
+(define_insn "*rorsi3_insn_uxtw"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (zero_extend:DI
+(rotate:SI (match_operand:SI 1 "register_operand" "r")
+   (match_operand 2 "const_int_operand" "n"]
+  "UINTVAL (operands[2]) < 32"
+{
+  operands[3] = GEN_INT (32 - UINTVAL (operands[2]));
+  return "ror\\t%w0, %w1, %3";
+}
+  [(set_attr "v8type" "shift")
+   (set_attr "mode" "SI")]
+)
+
 (define_insn "*_ashl"
   [(set (match_operand:GPI 0 "register_operand" "=r")
(ANY_EXTEND:GPI
diff --git a/gcc/testsuite/gcc.target/aarch64/ror.c 
b/gcc/testsuite/gcc.target/aarch64/ror.c
new file mode 100644
index 000..4d266f0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/ror.c
@@ -0,0 +1,34 @@
+/* { dg-options "-O2 --save-temps" } */
+/* { dg-do run } */
+
+extern void abort (void);
+
+int
+test_si (int a)
+{
+  /* { dg-final { scan-assembler "ror\tw\[0-9\]+, w\[0-9\]+, 27\n" } } */
+  return (a << 5) | ((unsigned int) a >> 27);
+}
+
+long long
+test_di (long long a)
+{
+  /* { dg-final { scan-assembler "ror\tx\[0-9\]+, x\[0-9\]+, 45\n" } } */
+  return (a << 19) | ((unsigned long long) a >> 45);
+}
+
+int
+main ()
+{
+  int v;
+  long long w;
+  v = test_si (0x0203050);
+  if (v != 0x4060a00)
+abort();
+  w = test_di (0x020506010304ll);
+  if (w != 0x102830081820ll)
+abort();
+  return 0;
+}
+
+/* { dg-final { cleanup-saved-temps } } */

Re: [Patch, microblaze]: Add support for TLS in MicroBlaze

[Michael Eager]

On 03/14/2013 01:07 AM, David Holsgrove wrote:

Hi Michael,


-Original Message-
From: Michael Eager [mailto:ea...@eagerm.com]
Sent: Thursday, 14 March 2013 1:34 am
To: David Holsgrove
Cc: gcc-patches@gcc.gnu.org; Edgar Iglesias; John Williams; Vinod Kathail;
Vidhumouli Hunsigida; Nagaraju Mekala; Tom Shui
Subject: Re: [Patch, microblaze]: Add support for TLS in MicroBlaze

On 03/12/2013 01:47 PM, David Holsgrove wrote:

Add support for thread local storage (general dynamic and local dynamic

models) in MicroBlaze.



gcc/Changelog

2013-03-13  Edgar E. Iglesias 
  David Holsgrove 


[--snip--]


Signed-off-by: Edgar E. Iglesias 
Signed-off-by: David Holsgrove 


Hi David --

The patch is OK except for a number of minor formatting problems to meet GNU
standards.
- Comments are supposed to end with ".  */".
- Extra spacing around parens or between "!" and "TARGET...".
- && or || at start of line continuing a condition rather that at end of 
previous line
- Some places where the indenting is incorrect



Thanks for the review, we inherited some of the style deviations when basing off
of other archs TLS functions I'm afraid. I've fixed the formatting in v2 of the 
patch
attached.


Should this patch be combined with the other patch adding TLS checking to
configure?



I've combined both patches into the attached - looking back at the ARM TLS patch
it was submitted this way, so we'll follow precedence there if that’s okay with
you.

Updated Changelog would be;

2013-03-14 Edgar E. Iglesias 
David Holsgrove 

  * configure.ac: Add MicroBlaze TLS support detection.
  * configure: Regenerate.
  * config/microblaze/microblaze-protos.h: (microblaze_cannot_force_const_mem,
microblaze_tls_referenced_p, symbol_mentioned_p,
label_mentioned_p): Add prototypes.
  * config/microblaze/microblaze.c (microblaze_address_type): Add ADDRESS_TLS
and tls_reloc address types.
(microblaze_address_info): Add tls_reloc.
(TARGET_HAVE_TLS): Define.
(get_tls_get_addr, microblaze_tls_symbol_p, microblaze_tls_operand_p_1,
 microblaze_tls_referenced_p, microblaze_cannot_force_const_mem,
 symbol_mentioned_p, label_mentioned_p, tls_mentioned_p, load_tls_operand,
 microblaze_call_tls_get_addr, microblaze_legitimize_tls_address): New 
functions.
(microblaze_classify_unspec): Handle UNSPEC_TLS.
(get_base_reg): Use microblaze_tls_symbol_p.
(microblaze_classify_address): Handle TLS.
(microblaze_legitimate_pic_operand): Use symbol_mentioned_p, 
label_mentioned_p
 and microblaze_tls_referenced_p.
(microblaze_legitimize_address): Handle TLS.
(microblaze_address_insns): Handle ADDRESS_TLS.
(pic_address_needs_scratch): Handle TLS.
(print_operand_address): Handle TLS.
(microblaze_expand_prologue): Check TLS_NEEDS_GOT.
(microblaze_expand_move): Handle TLS.
(microblaze_legitimate_constant_p): Check microblaze_cannot_force_const_mem
 and microblaze_tls_symbol_p.
(TARGET_CANNOT_FORCE_CONST_MEM): Define.
  * config/microblaze/microblaze.h (TLS_NEEDS_GOT): Define
(PIC_OFFSET_TABLE_REGNUM): Set.
  * config/microblaze/linux.h (TLS_NEEDS_GOT): Define.
  * config/microblaze/microblaze.md (UNSPEC_TLS): Define.
(addsi3, movsi_internal2, movdf_internal): Update constraints
  * config/microblaze/predicates.md (arith_plus_operand): Define
(move_operand): Redefine as move_src_operand, check 
microblaze_tls_referenced_p.

Signed-off-by: Edgar E. Iglesias 
Signed-off-by: David Holsgrove 


Thanks for cleaning up the patch.  There were a few other places where I fixed
indent and other formatting issues.

Committed revision 196659.

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

[PATCH, AArch64] Support SBC in the backend

[Ian Bolton]

We couldn't generate SBC for AArch64 ... until now!

This really patch includes the main pattern, a zero_extend form
of it and a test.

Full regression testing for Linux and bare-metal passed.

OK for trunk stage-1?

Thanks,
Ian


2013-03-14  Ian Bolton  

gcc/
* config/aarch64/aarch64.md (*sub3_carryin): New pattern.
(*subsi3_carryin_uxtw): Likewise.

testsuite/
* gcc.target/aarch64/sbc.c: New test.

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 4358b44..c99e188 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1790,6 +1790,34 @@
(set_attr "mode" "SI")]
 )
 
+(define_insn "*sub3_carryin"
+  [(set
+(match_operand:GPI 0 "register_operand" "=r")
+(minus:GPI (minus:GPI
+   (match_operand:GPI 1 "register_operand" "r")
+   (ltu:GPI (reg:CC CC_REGNUM) (const_int 0)))
+  (match_operand:GPI 2 "register_operand" "r")))]
+   ""
+   "sbc\\t%0, %1, %2"
+  [(set_attr "v8type" "adc")
+   (set_attr "mode" "")]
+)
+
+;; zero_extend version of the above
+(define_insn "*subsi3_carryin_uxtw"
+  [(set
+(match_operand:DI 0 "register_operand" "=r")
+(zero_extend:DI
+ (minus:SI (minus:SI
+   (match_operand:SI 1 "register_operand" "r")
+   (ltu:SI (reg:CC CC_REGNUM) (const_int 0)))
+  (match_operand:SI 2 "register_operand" "r"]
+   ""
+   "sbc\\t%w0, %w1, %w2"
+  [(set_attr "v8type" "adc")
+   (set_attr "mode" "SI")]
+)
+
 (define_insn "*sub_uxt_multp2"
   [(set (match_operand:GPI 0 "register_operand" "=rk")
(minus:GPI (match_operand:GPI 4 "register_operand" "r")
diff --git a/gcc/testsuite/gcc.target/aarch64/sbc.c 
b/gcc/testsuite/gcc.target/aarch64/sbc.c
new file mode 100644
index 000..e479910
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sbc.c
@@ -0,0 +1,41 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps" } */
+
+extern void abort (void);
+
+typedef unsigned int u32int;
+typedef unsigned long long u64int;
+
+u32int
+test_si (u32int w1, u32int w2, u32int w3, u32int w4)
+{
+  u32int w0;
+  /* { dg-final { scan-assembler "sbc\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+\n" } } 
*/
+  w0 = w1 - w2 - (w3 < w4);
+  return w0;
+}
+
+u64int
+test_di (u64int x1, u64int x2, u64int x3, u64int x4)
+{
+  u64int x0;
+  /* { dg-final { scan-assembler "sbc\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+\n" } } 
*/
+  x0 = x1 - x2 - (x3 < x4);
+  return x0;
+}
+
+int
+main ()
+{
+  u32int x;
+  u64int y;
+  x = test_si (7, 8, 12, 15);
+  if (x != -2)
+abort();
+  y = test_di (0x987654321ll, 0x123456789ll, 0x345345345ll, 0x123123123ll);
+  if (y != 0x8641fdb98ll)
+abort();
+  return 0;
+}
+
+/* { dg-final { cleanup-saved-temps } } */

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Xinliang David Li]

I am with you for simple cases where straightline code is generated.

Helper class will be very useful when control flow manipulation is
involved.  People can simply just write 'straight line like code'
using gimple_label, goto_label etc without worrying about how split
blocks and create new cfg edges. The 'end/finalize' method of the
builder helper will do the magic.

David

On Thu, Mar 14, 2013 at 4:25 AM, Michael Matz  wrote:
> Hi,
>
> On Wed, 13 Mar 2013, Diego Novillo wrote:
>
>> To use the builder:
>>
>> 1- Declare an instance 'gb' of gimple_builder_normal or
>>gimple_builder_ssa.  E.g., gimple_builder_ssa gb;
>>
>> 2- Use gb.add_* to add a new statement to it.  This
>>returns an SSA name or VAR_DECL with the value of the added
>>statement.
>>
>> 3- Call gb.insert_*() to insert the sequence of statements in the
>>builder into a statement iterator.
>
> I'm reiterating everything I said in
>   http://gcc.gnu.org/ml/gcc/2012-11/msg00230.html
> Actually your interface now is worse than what Lawrence proposed back in
> November in that the add_* methods return a tree, instead of a gimple
> statement.
>
> I haven't seen any convincing reason why the builder class is necessary,
> instead of improving the current interface.  IOW I don't like it much.
>
>
> Ciao,
> Michael.

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Xinliang David Li]

On Thu, Mar 14, 2013 at 7:55 AM, Marc Glisse  wrote:
> On Wed, 13 Mar 2013, Diego Novillo wrote:
>
>> This patch adds an initial implementation for a new helper type for
>> generating GIMPLE statements.
>
>
> I hope you'll forgive the naive newbie question: why is the gimplifier used
> so little outside of the gimplification pass? For instance, after a call to
> fold in a gimple pass, we test valid_gimple_rhs_p and give up if it returns
> false, instead of trying to gimplify whatever fold returned. The connection
> with your patch is that generic trees are easier to build than gimple
> statements, so for a long expression one could imagine building a tree and
> having a single gimplification call at the end (the time wasted should be
> quite limited).

It also creates more garbage and increase ggc overhead?

David
>
> (Note that I encourage the efforts to simplify the gimple interface, I am
> just taking the occasion to ask a vaguely related question)
>
> --
> Marc Glisse

[4.7, go] Backport godump.c patch

[Rainer Orth]

Since Solaris 11.1, libgo compilation was failing with

sysinfo.go:676:267: error: use of undefined type '_ns_postinit_s'

sysinfo.go had

type _netstack struct { netstack_u struct { nu_modules [20+1]*byte; }; 
netstack_m_state [20+1]uint32; netstack_lock _kmutex_t; netstack_next 
*_netstack; netstack_stackid int32; netstack_numzones int32; netstack_refcnt 
int32; netstack_flags int32; netstack_postinit *_ns_postinit_s; }
const _sizeof_netstack = 200
type _netstack_t struct { netstack_u struct { nu_modules [20+1]*byte; }; 
netstack_m_state [20+1]uint32; netstack_lock _kmutex_t; netstack_next 
*_netstack; netstack_stackid int32; netstack_numzones int32; netstack_refcnt 
int32; netstack_flags int32; netstack_postinit *_ns_postinit_s; }

but no definition of _ns_postinit_s.  For a long time, I had a local
patch in my tree to just omit the related _netstack, _netstack_t, and
_netstack_registry types in mksysinfo.sh to avoid this.  When I tried
without this patch on mainline, I noticed that the build worked just
fine, while on the 4.7 branch it still fails.

I found that this patch

2012-12-04  Ian Lance Taylor  

* godump.c (find_dummy_types): Output a dummy type if we couldn't
output the real type.

diff --git a/gcc/godump.c b/gcc/godump.c
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -1,5 +1,5 @@
 /* Output Go language descriptions of types.
-   Copyright (C) 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
+   Copyright (C) 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
Written by Ian Lance Taylor .
 
 This file is part of GCC.
@@ -1164,9 +1164,11 @@ find_dummy_types (const void *ptr, void 
   struct godump_container *data = (struct godump_container *) adata;
   const char *type = (const char *) ptr;
   void **slot;
+  void **islot;
 
   slot = htab_find_slot (data->type_hash, type, NO_INSERT);
-  if (slot == NULL)
+  islot = htab_find_slot (data->invalid_hash, type, NO_INSERT);
+  if (slot == NULL || islot != NULL)
 fprintf (go_dump_file, "type _%s struct {}\n", type);
   return true;
 }


fixes the problem, so I'd like to backport it.

i386-pc-solaris2.11 bootstrap still running, ok for 4.7 branch if it
passes?

One additional question: the patch updates the copyright date by adding
2012.  How do we hande this for a backport?  Keep it that way or update
for 2013 instead?

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Richard Biener]

Xinliang David Li  wrote:

>I am with you for simple cases where straightline code is generated.
>
>Helper class will be very useful when control flow manipulation is
>involved.  People can simply just write 'straight line like code'
>using gimple_label, goto_label etc without worrying about how split
>blocks and create new cfg edges. The 'end/finalize' method of the
>builder helper will do the magic.

That won't work with the magic in the builder to create ssa names for the 
results. Then people need to think about cfg merges and phi nodes. So much for 
labels and gotos...

I'd rather have people know about the context they are working in. Otherwise 
they cannot exploit its property either.

Richard.
>David
>
>On Thu, Mar 14, 2013 at 4:25 AM, Michael Matz  wrote:
>> Hi,
>>
>> On Wed, 13 Mar 2013, Diego Novillo wrote:
>>
>>> To use the builder:
>>>
>>> 1- Declare an instance 'gb' of gimple_builder_normal or
>>>gimple_builder_ssa.  E.g., gimple_builder_ssa gb;
>>>
>>> 2- Use gb.add_* to add a new statement to it.  This
>>>returns an SSA name or VAR_DECL with the value of the added
>>>statement.
>>>
>>> 3- Call gb.insert_*() to insert the sequence of statements in the
>>>builder into a statement iterator.
>>
>> I'm reiterating everything I said in
>>   http://gcc.gnu.org/ml/gcc/2012-11/msg00230.html
>> Actually your interface now is worse than what Lawrence proposed back
>in
>> November in that the add_* methods return a tree, instead of a gimple
>> statement.
>>
>> I haven't seen any convincing reason why the builder class is
>necessary,
>> instead of improving the current interface.  IOW I don't like it
>much.
>>
>>
>> Ciao,
>> Michael.

Re: [PATCH] Fix -print-multi-os-directory for aarch64

[Matthias Klose]

Am 14.03.2013 16:37, schrieb Marcus Shawcroft:
> On 8 March 2013 09:32, Jakub Jelinek  wrote:
>> On Fri, Mar 08, 2013 at 09:04:19AM +, Marcus Shawcroft wrote:
>>> On 07/03/13 16:45, Jakub Jelinek wrote:
 On Thu, Mar 07, 2013 at 08:29:06AM -0800, Andrew Pinski wrote:
> On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek  wrote:
>> AFAIK aarch64 libraries are supposed to go into /usr/lib64 etc.
>> directories similarly to x86-64 etc., but as aarch64 isn't a true
>> multilib target (having two different backends for 32-bit vs. 64-bit 
>> code),
>> currently gcc -print-multi-os-directory prints . instead of ../lib64.
>
> I think glibc is broken also. So after this change, the build using
> the released 2.17 and this new gcc breaks.

 Then glibc will need patching too.  Distros using multiarch aren't affected
 by this, others IMHO will want it in */lib64 and for aarch64 IMHO it isn't
 still too late for that change.
>>>
>>> Hi, Moving from /lib to /lib64 will affect binutils 2.23 (ld) and
>>> glibc 2.17.  This seems to me to be a rather disruptive change this
>>> late in the day.
>>
>> Yes, it does affect them, on the binutils side it would be about
>> setting LIBPATH_SUFFIX=64 in ld/emulparams/aarch64linux.sh when appropriate
>> (grep LIBPATH_SUFFIX=64 ld/emulparams/*.sh to see what other targets do),
>> on the glibc side for other targets sysdeps/gnu/configure.in
>> is where libc_cv_slibdir and libc_cv_libdir are tweaked.
>> Note, this change doesn't affect multiarch, so Debian/Ubuntu is unaffected,
>> for others there can be an easy workaround for transitional period
>> (just add */lib64 -> */lib symlinks (or vice versa)).
>> The point of using */lib64 is that it is consistent with how most other
>> important 64-bit architectures are handled (x86_64, ppc64, s390x, sparc64,
>> mips64) and that even if you don't expect coexistence of 32-bit arm and
>> 64-bit aarch64 libraries on the same filesystem right now, using */lib64
>> allows that in the future.  Even if some distros use lib64 -> lib or vice
>> versa symlinks for some time if they choose so, if there is agreement to go
>> with lib64 path suffixes, it means packages that need to know this can be
>> changed, rather than adding horrible hacks to see what library suffixes
>> should be used.
> 
> My concern about the disruption associated with this change aside, I
> agree that the change needs to happen in order to avoid long term
> pain.  I see no objections on this thread or the related thread over
> at glibc-ports, so go ahead and commit the patch.

sorry, didn't comment about this patch because it didn't seem to affect
multiarch.  However this patch assumes that every system does have at least a
*/lib64 symlink, if it doesn't have a */lib64 directory.  I think that is a
wrong assumption.  Things like

$ gcc --print-file-name libc.so
/usr/lib/gcc/aarch64-linux-gnu/4.8.0/../../../lib64/libc.so

would point to a non-existing path.

Attaching a patch which uses a check to only set this to ../lib64 if it does
exist, as done for other multilib configurations.

  Matthias

Index: gcc/config/aarch64/t-aarch64-linux
===
--- gcc/config/aarch64/t-aarch64-linux	(revision 196661)
+++ gcc/config/aarch64/t-aarch64-linux	(working copy)
@@ -22,4 +22,4 @@
 LIB1ASMFUNCS = _aarch64_sync_cache_range
 
 AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be)
-MULTILIB_OSDIRNAMES = .=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)
+MULTILIB_OSDIRNAMES = .=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib64),../lib64,../lib)$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)

Re: [4.7, go] Backport godump.c patch

[Ian Lance Taylor]

On Thu, Mar 14, 2013 at 9:53 AM, Rainer Orth wrote:

> I found that this patch
>
> 2012-12-04 Ian Lance Taylor
> * godump.c (find_dummy_types): Output a dummy type if we couldn't
>  output the real type.
>
>
>
> fixes the problem, so I'd like to backport it.
>
> i386-pc-solaris2.11 bootstrap still running, ok for 4.7 branch if it
> passes?

It's fine with me though I guess it needs to be approved by a release
branch manager.

> One additional question: the patch updates the copyright date by adding
> 2012. How do we hande this for a backport? Keep it that way or update
> for 2013 instead?

Keep it as 2012 since that is when the code was written.

Ian

Re: [PATCH] Fix -print-multi-os-directory for aarch64

[Jakub Jelinek]

On Fri, Mar 15, 2013 at 02:07:12AM +0800, Matthias Klose wrote:
> sorry, didn't comment about this patch because it didn't seem to affect
> multiarch.  However this patch assumes that every system does have at least a
> */lib64 symlink, if it doesn't have a */lib64 directory.  I think that is a
> wrong assumption.  Things like

Why do you think the patch assumes it?  And why do you care for multiarch?
It just adjusts where the libraries are searched.

In a cross, I see (for non-multiarch):
grep '^  \$ \.\.' ../config.log; strace -v -s1024 ./xgcc -B ./ 
-print-file-name=libc.so 2>&1 | grep access.*libc.so
  $ ../configure --target aarch64-linux --enable-languages=c,c++
access("./aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or 
directory)
access("./libc.so", R_OK)   = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/libc.so", R_OK) = 
-1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/libc.so", R_OK) = -1 ENOENT (No such 
file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/aarch64-linux/4.8.0/libc.so",
 R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/../lib64/libc.so",
 R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/libc.so",
 R_OK) = -1 ENOENT (No such file or directory)

for multiarch:
grep '^  \$ \.\.' ../config.log; strace -v -s1024 ./xgcc -B ./ 
-print-file-name=libc.so 2>&1 | grep access.*libc.so
  $ ../configure --target aarch64-linux --enable-languages=c,c++ 
--enable-multiarch
access("./aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or 
directory)
access("./aarch64-linux-gnu/libc.so", R_OK) = -1 ENOENT (No such file or 
directory)
access("./libc.so", R_OK)   = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/libc.so", R_OK) 
= -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux-gnu/libc.so", R_OK) = 
-1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/libc.so", R_OK) = -1 ENOENT (No such 
file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/aarch64-linux/4.8.0/libc.so",
 R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/aarch64-linux-gnu/libc.so",
 R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/../lib64/libc.so",
 R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/libc.so",
 R_OK) = -1 ENOENT (No such file or directory)

as you can see, if lib64 paths don't exist, it just goes on to look in */lib 
(like it does on x86_64 etc).
And, for multiarch, it looks first in multiarch directories.

Checking for lib64 directory or symlink is what I'd prefer to avoid.

Jakub

Re: RFC: add some static probes to libstdc++

[Tom Tromey]

Tom> 2013-02-27  Tom Tromey  
Tom>* libsupc++/unwind-cxx.h: Include sys/sdt.h if detected.
Tom>(PROBE2): New macro.
Tom>* libsupc++/eh_throw.cc (__cxa_throw, __cxa_rethrow): Add probe.
Tom>* libsupc++/eh_catch.cc (__cxa_begin_catch): Add probe.
Tom>* configure.ac: Check for sys/sdt.h.
Tom>* configure, config.h.in: Rebuild.

FWIW the gdb patches relying on this have all been submitted.
They are pending comments, but also this patch going in.

In particular:

Using the probes in gdb:
http://sourceware.org/ml/gdb-patches/2013-03/msg00242.html

Using the probes to implement the $_exception convenience variable:
http://sourceware.org/ml/gdb-patches/2013-03/msg00243.html

Using the probes to implement filtering for exception catchpoints:
http://sourceware.org/ml/gdb-patches/2013-03/msg00245.html

Tom

Re: [cxx-conversion] RFC - Helper types for building GIMPLE

[Xinliang David Li]

On Thu, Mar 14, 2013 at 10:54 AM, Richard Biener  wrote:
> Xinliang David Li  wrote:
>
>>I am with you for simple cases where straightline code is generated.
>>
>>Helper class will be very useful when control flow manipulation is
>>involved.  People can simply just write 'straight line like code'
>>using gimple_label, goto_label etc without worrying about how split
>>blocks and create new cfg edges. The 'end/finalize' method of the
>>builder helper will do the magic.
>
> That won't work with the magic in the builder to create ssa names for the 
> results. Then people need to think about cfg merges and phi nodes. So much 
> for labels and gotos...
>
> I'd rather have people know about the context they are working in. Otherwise 
> they cannot exploit its property either.

I am not sure what you mean. The builder helper class should contain
all the context information which should be accessible if user wants
to take a peek. The low level information is usually needed for
analysis, but not needs to be exposed for transformation.

David



>
> Richard.
>>David
>>
>>On Thu, Mar 14, 2013 at 4:25 AM, Michael Matz  wrote:
>>> Hi,
>>>
>>> On Wed, 13 Mar 2013, Diego Novillo wrote:
>>>
 To use the builder:

 1- Declare an instance 'gb' of gimple_builder_normal or
gimple_builder_ssa.  E.g., gimple_builder_ssa gb;

 2- Use gb.add_* to add a new statement to it.  This
returns an SSA name or VAR_DECL with the value of the added
statement.

 3- Call gb.insert_*() to insert the sequence of statements in the
builder into a statement iterator.
>>>
>>> I'm reiterating everything I said in
>>>   http://gcc.gnu.org/ml/gcc/2012-11/msg00230.html
>>> Actually your interface now is worse than what Lawrence proposed back
>>in
>>> November in that the add_* methods return a tree, instead of a gimple
>>> statement.
>>>
>>> I haven't seen any convincing reason why the builder class is
>>necessary,
>>> instead of improving the current interface.  IOW I don't like it
>>much.
>>>
>>>
>>> Ciao,
>>> Michael.
>
>

Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

[Jason Merrill]

On 03/14/2013 09:48 AM, James Greenhalgh wrote:

Is this OK to commit to 4.9 when stage 1 opens up?


Yes, but please add the other new tree codes as well.

Jason

Re: Patch for 4.7: Avoid subreg'ing VFP D registers in big-endian mode

[Eric Botcazou]

> 2013-02-20 Seth LaForge 
> 
>   Backport
>   2012-10-22  Julian Brown  
>   * config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Avoid subreg'ing
>   VFP D registers in big-endian mode.

Applied to the 4.7 branch after QEMU-testing for arm-eabi in big-endian mode.
It also fixes a fair number of execution failures in the testsuite.

-- 
Eric Botcazou

Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

[Jakub Jelinek]

On Thu, Mar 14, 2013 at 02:51:30PM -0400, Jason Merrill wrote:
> On 03/14/2013 09:48 AM, James Greenhalgh wrote:
> >Is this OK to commit to 4.9 when stage 1 opens up?
> 
> Yes, but please add the other new tree codes as well.

I wonder if it wouldn't be better to fold the target builtins only later on
(e.g. guard the folding with cfun && gimple_in_ssa_p (cfun) (or if we have
any predicate that is set starting with gimplification or so)).
Having all the FEs have to deal with myriads of weird tree codes etc. isn't
IMHO desirable.

Jakub

Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

[Gabriel Dos Reis]

On Thu, Mar 14, 2013 at 1:55 PM, Jakub Jelinek  wrote:
> On Thu, Mar 14, 2013 at 02:51:30PM -0400, Jason Merrill wrote:
>> On 03/14/2013 09:48 AM, James Greenhalgh wrote:
>> >Is this OK to commit to 4.9 when stage 1 opens up?
>>
>> Yes, but please add the other new tree codes as well.
>
> I wonder if it wouldn't be better to fold the target builtins only later on
> (e.g. guard the folding with cfun && gimple_in_ssa_p (cfun) (or if we have
> any predicate that is set starting with gimplification or so)).
> Having all the FEs have to deal with myriads of weird tree codes etc. isn't
> IMHO desirable.

Agreed.

-- Gaby

Re: FW: [PATCH] [MIPS] microMIPS gcc support

[Richard Sandiford]

"Moore, Catherine"  writes:
>> -Original Message-
>> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>> Sent: Tuesday, March 05, 2013 4:06 PM
>> To: Moore, Catherine
>> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
>> Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support:
>> 
>> We have a few internal-only undocumented constraints that aren't used
>> much, so we should be able to move them to the "Y" space instead.  The
>> patch below does this for "T" and "U".  Then we could use "U" for new,
>> longer constraints.
>> 
>> 
>> U
>> 
>> where  is:
>> 
>>   s for signed
>>   u for unsigned
>>   d for decremented unsigned (-1 ... N)
>>   i for incremented unsigned (1 ... N)
>> 
>> where  is:
>> 
>>   b for "byte" (*1)
>>   h for "halfwords" (*2)
>>   w for "words" (*4)
>>   d for "doublewords" (*8) -- useful for 64-bit MIPS16 but probably not
>>   needed for 32-bit microMIPS
>> 
>> and where  is the number of bits.   and  could be
>> replaced with an ad-hoc two-letter combination for special cases.
>> E.g. "Uas9" ("add stack") for ADDISUP.
>> 
>> Just a suggestion though.  I'm not saying these names are totally intuitive 
>> or
>> anything, but they should at least be better than arbitrary letters.
>> 
>> Also,  could be two digits if necessary, or we could just use hex 
>> digits.
>
> I extended this proposal a bit by:
> 1.  Adding a  e for encoded.  The constraint will start with Ue,
> when the operand is an encoded value.
> 2. I decided to use two digits for .
> 3. The ad-hoc combination is used for anything else.

First of all, thanks for coming up with a counter-suggestion.  I'm hopeless
at naming things, so I was hoping there would be at least some pushback.

"e" for "encoded" sounds good.  I'm less keen on the mixture of single-
and double-digit widths though (single digit for some "Ue"s, double
digits for other "U"s.)  I think we should either:

(a) use the same number of digits for all "U" constraints.  That leaves
one character for the "Ue" type, which isn't as mnemonic, but is in
line with what we do elsewhere.

(b) avoid digits in the "Ue" forms and just have an ad-hoc letter combination.

Please keep "U" for constants though.  The memory constraints should go
under "Z" instead (and therefore be only two letters long).  The idea is
that the first letter of the constraint tells you what type it is.

I don't think there's any need for the "Ue" constraints to have
predicates of the same name.  We can go with longer, mnemonic,
names instead.  The idea behind suggesting "sb4_operand", etc.,
was that (a) every character was predictable and (b) I'm not sure
the extra verbosity of (say) "signed_byte_4_operand" would help.
But "addiur2_operand" would be good.

> +(define_constraint "Udb07"
> +  "@internal
> +   A decremented unsigned constant of 7 bits."
> +  (match_operand 0 "Udb07_operand" ""))

Very minor nit, but these "" are redundant.

> +(define_constraint "Ueim4"
> +  "@internal
> +   A microMIPS encoded ADDIUR2 immediate operand."
> +  (match_operand 0 "Ueim4_operand" ""))

Again minor, but the name doesn't really seem to match the description.
Is this constraint needed for things other than ADDIUR2?  If so, it might
be worth giving a second example, otherwise it might be better to make
the name a bit less general.  Unless this name comes from the manual,
of course :-)  (The microMIPS link on the MIPS website was still
broken last time I checked, but I haven't tried it again in the
last couple of weeks.)

> +(define_predicate "Umem0_operand"
> +  (and (match_code "mem")
> +   (match_test "umips_lwsp_swsp_address_p (XEXP (op, 0), mode)")))
> +
> +(define_predicate "Uload_operand"
> +  (and (match_code "mem")
> +   (match_test "umips_address_p (XEXP (op, 0), true, mode)")))
> +
> +(define_predicate "Ustore_operand"
> +  (and (match_code "mem")
> +   (match_test "umips_address_p (XEXP (op, 0), false, mode)")))

With the two-letter Z constraints, these should have descriptive names.

> +(define_predicate "Udb07_operand"
> +  (and (match_code "const_int")
> +   (match_test "mips_unsigned_immediate_p (INTVAL (op) + 1, 7, 0)")))

Please drop the "U"s in the predicate names.

> +(define_attr "compression" "none,all,micromips,mips16"
> +  (const_string "none"))

Thinking about it a bit more, it would probably be better to leave the
"all" and "mips16" values out until we need them.

> +(define_attr "enabled" "no,yes"
> +  (if_then_else (ior (eq_attr "compression" "all")
> +  (eq_attr "compression" "none")
> +  (and (eq_attr "compression" "micromips")
> +   (match_test "TARGET_MICROMIPS")))
> + (const_string "yes")
> + (const_string "no")))

FWIW (probably not much after the above), it's also possible to write:

(eq_attr "compression" "all,none")

> @@ -5237,6 +5271,12 @@
>return "\t%0,%1,%2";
>  }
>[(set_attr "type" "shift")
> +   (set_attr_alternative "compression"
> + [

RE: [Patch] Add microMIPS jraddiusp support

[Moore, Catherine]

Hi Richard,

I updated this patch using your suggestions.  I'm having a problem though, that 
I'm having trouble nailing.  Building libstdc++ for microMIPS is failing trying 
to generate dwarf2 CFI info:

_Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*)
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   <*free_inline_summary> 
 
Assembling functions:
 _Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*)
mm.cc: In function '_Unwind_Ptr base_of_encoded_value(unsigned char, 
_Unwind_Context*)':
mm.cc:34:1: internal compiler error: in maybe_record_trace_start, at 
dwarf2cfi.c:2209
0x8570656 maybe_record_trace_start
/scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2209
0x857113f create_trace_edges
/scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2301
0x8572505 scan_trace
/scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2514
0x85726b3 create_cfi_notes
/scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2540
0x8572703 execute_dwarf2_frame
/scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2897
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I've attached a testcase hoping that you might have some ideas.   I plan to 
keep debugging in the meanwhile.  I was able to reproduce with ./cc1plus 
-mmicromips -Os mm.ii.

Thanks,
Catherine


> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Tuesday, March 05, 2013 4:10 PM
> To: Moore, Catherine
> Cc: gcc-patches@gcc.gnu.org; Rozycki, Maciej
> Subject: Re: [Patch] Add microMIPS jraddiusp support
> 
> "Moore, Catherine"  writes:
> > Index: config/mips/micromips.md
> >
> ==
> =
> > --- config/mips/micromips.md(revision 196341)
> > +++ config/mips/micromips.md(working copy)
> > @@ -95,6 +95,19 @@
> > (set_attr "mode" "SI")
> > (set_attr "can_delay" "no")])
> >
> > +;; For JRADDIUSP.
> > +(define_insn "jraddiusp"
> > +  [(parallel [(return)
> > +  (use (reg:SI 31))
> > + (set (reg:SI 29)
> > +  (plus:SI (reg:SI 29)
> > +   (match_operand 0 "const_int_operand")))])]
> 
> Since this is a generic pattern (not depending on UNSPECs, etc.), I think we
> should use a specific predicate instead of const_int_operand.
> From the suggestion in the thread about addition, this would be a "uw5", i.e.
> uw5_operand.
> 
> > Index: config/mips/mips.c
> >
> ==
> =
> > --- config/mips/mips.c  (revision 196341)
> > +++ config/mips/mips.c  (working copy)
> > @@ -11364,6 +11364,7 @@
> >const struct mips_frame_info *frame;
> >HOST_WIDE_INT step1, step2;
> >rtx base, adjust, insn;
> > +  bool use_jraddiusp_p = false;
> >
> >if (!sibcall_p && mips_can_use_return_insn ())
> >  {
> > @@ -11453,6 +11454,14 @@
> >mips_for_each_saved_gpr_and_fpr (frame->total_size - step2,
> >mips_restore_reg);
> >
> > +  /* Check if we can use JRADDIUSP.  */
> > +  use_jraddiusp_p = (TARGET_MICROMIPS
> > +&& !crtl->calls_eh_return
> > +&& !sibcall_p
> > +&& step2 > 0
> > +&& (step2 & 3) == 0
> > +&& step2 <= (31 << 2));
> > +
> >if (cfun->machine->interrupt_handler_p)
> > {
> >   HOST_WIDE_INT offset;
> > @@ -11480,8 +11489,9 @@
> >   mips_emit_move (gen_rtx_REG (word_mode, K0_REG_NUM),
> mem);
> >   offset -= UNITS_PER_WORD;
> >
> > - /* If we don't use shadow register set, we need to update SP.  */
> > - if (!cfun->machine->use_shadow_register_set_p)
> > + /* If we don't use shadow register set or the microMIPS
> > + JRADDIUSP insn, we need to update SP.  */
> > + if (!cfun->machine->use_shadow_register_set_p &&
> !use_jraddiusp_p)
> > mips_deallocate_stack (stack_pointer_rtx, GEN_INT (step2), 0);
> >   else
> > /* The choice of position is somewhat arbitrary in this case.
> > */
> 
> We shouldn't use JRADDIUSP in an interrupt handler, so I think it would be
> better to move the use_jraddiusp_p condition into the else branch and drop
> the hunk above.
> 
> > @@ -11492,11 +11502,14 @@
> > gen_rtx_REG (SImode, K0_REG_NUM)));
> > }
> >else
> > -   /* Deallocate the final bit of the frame.  */
> > -   mips_deallocate_stack (stack_pointer_rtx, GEN_INT (step2), 0);
> > +   /* Deallocate the final bit of the frame unless using the microMIPS
> > +   JRADDIUSP insn.  */
> > +   if (!use_jraddiusp_p)
> > + mips_deallocate_stack (stack_pointer_rtx, GEN_INT 

Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

[Marc Glisse]

On Thu, 14 Mar 2013, Jakub Jelinek wrote:


I wonder if it wouldn't be better to fold the target builtins only later on
(e.g. guard the folding with cfun && gimple_in_ssa_p (cfun) (or if we have
any predicate that is set starting with gimplification or so)).
Having all the FEs have to deal with myriads of weird tree codes etc. isn't
IMHO desirable.


Wouldn't that prevent from using those builtins in constant expressions? 
That seems undesirable. Maybe an alternative could be to push some of the 
functionality from potential_constant_expression_1 to the middle-end?


--
Marc Glisse

Re: [Patch] Add microMIPS jraddiusp support

[Richard Sandiford]

"Moore, Catherine"  writes:
> Hi Richard,
>
> I updated this patch using your suggestions.  I'm having a problem
> though, that I'm having trouble nailing.  Building libstdc++ for
> microMIPS is failing trying to generate dwarf2 CFI info:
>
> _Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*)
> Analyzing compilation unit
> Performing interprocedural optimizations
>  <*free_lang_data>   <*free_inline_summary> 
>  
> Assembling functions:
>  _Unwind_Ptr base_of_encoded_value(unsigned char, _Unwind_Context*)
> mm.cc: In function '_Unwind_Ptr base_of_encoded_value(unsigned char, 
> _Unwind_Context*)':
> mm.cc:34:1: internal compiler error: in maybe_record_trace_start, at 
> dwarf2cfi.c:2209
> 0x8570656 maybe_record_trace_start
> /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2209
> 0x857113f create_trace_edges
> /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2301
> 0x8572505 scan_trace
> /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2514
> 0x85726b3 create_cfi_notes
> /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2540
> 0x8572703 execute_dwarf2_frame
> /scratch/cmoore/umips-elf/src/gcc-4.7-2012.09/gcc/dwarf2cfi.c:2897
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
>
> I've attached a testcase hoping that you might have some ideas.  I
> plan to keep debugging in the meanwhile.  I was able to reproduce with
> ./cc1plus -mmicromips -Os mm.ii.

Ah, sorry, I expect it should be:

  mips_epilogue_set_cfa (stack_pointer_rtx, 0);

instead of:

  mips_epilogue_emit_cfa_restores ();

It would probably be better to call mips_epilogue_set_cfa immediately
after emitting the jraddiusp, if that works (in which case making the
assert conditional is OK).

Richard

[patch] fix libstdc++/56613

[Jonathan Wakely]

This fixes a regression. Technically we shouldn't call construct() for
the node, only for the value within it, but I plan to fix that for
4.9, this just restores the previous behaviour when using a type
meeting the C++03 Allocator requirements.

PR libstdc++/56613
* include/bits/stl_tree.h (_Rb_tree::_M_create_node): Use
allocator_traits instead of calling construct directly.
* testsuite/23_containers/map/56613.cc: New.


Tested x86_64-linux, committed to trunk.
commit 655eef17cd38d23d7c5ad34137224d53f7315811
Author: Jonathan Wakely 
Date:   Thu Mar 14 01:40:13 2013 +

PR libstdc++/56613
* include/bits/stl_tree.h (_Rb_tree::_M_create_node): Use
allocator_traits instead of calling construct directly.
* testsuite/23_containers/map/56613.cc: New.

diff --git a/libstdc++-v3/include/bits/stl_tree.h 
b/libstdc++-v3/include/bits/stl_tree.h
index 59883fc..cb5a8ef 100644
--- a/libstdc++-v3/include/bits/stl_tree.h
+++ b/libstdc++-v3/include/bits/stl_tree.h
@@ -62,6 +62,9 @@
 #include 
 #include 
 #include 
+#if __cplusplus >= 201103L
+#include 
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -400,8 +403,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _Link_type __tmp = _M_get_node();
  __try
{
- _M_get_Node_allocator().construct(__tmp,
-std::forward<_Args>(__args)...);
+ allocator_traits<_Node_allocator>::
+   construct(_M_get_Node_allocator(), __tmp,
+ std::forward<_Args>(__args)...);
}
  __catch(...)
{
diff --git a/libstdc++-v3/testsuite/23_containers/map/56613.cc 
b/libstdc++-v3/testsuite/23_containers/map/56613.cc
new file mode 100644
index 000..9843359
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/map/56613.cc
@@ -0,0 +1,74 @@
+// -*- C++ -*-
+
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// libstdc++/56613
+#include 
+
+// A conforming C++03 allocator, should still work in C++11 mode.
+template
+struct alloc
+{
+typedef T value_type;
+typedef T* pointer;
+typedef const T* const_pointer;
+typedef T& reference;
+typedef const T& const_reference;
+typedef unsigned size_type;
+typedef int difference_type;
+
+template
+struct rebind {
+typedef alloc other;
+};
+
+alloc() { }
+template
+alloc(const alloc&) { }
+
+pointer allocate(size_type n, const void* = 0) { return
+std::allocator().allocate(n); }
+void deallocate(pointer p, size_type n) { std::allocator().deallocate(p,
+n); }
+
+size_type max_size() const { return -1; }
+
+void construct(pointer p, const T& t) { new ((void*) p) T(t); }
+void destroy(pointer p) { p->~T(); }
+
+pointer address(reference x) const throw() { return &x; }
+const_pointer address(const_reference x) const throw() { return &x; }
+};
+
+template
+bool operator==(alloc, alloc) { return true; }
+
+template
+bool operator!=(alloc, alloc) { return false; }
+
+int main()
+{
+  std::map, alloc > m;
+  m[1];
+}