Re: [asan] WIP protection of globals

[Jakub Jelinek]

On Tue, Oct 16, 2012 at 04:19:09PM -0700, Xinliang David Li wrote:
 I am not sure -- fasan is an error detecting feature -- the goal is to
 find bugs -- missing handling of commons etc. are not desirable.
 Besides  if ABI changes consistently for all objects, why does it
 matter?
 
 Or making common/decl_one_only protected under an additional option.

Note that LLVM doesn't protect common vars nor comdat linkage vars either
(at least 3.1 release), as can be seen on

struct A { int a; char b[64]; };
inline A *foo ()
{
  static A a;
  return a;
}
A *(*p) () = foo;

C++ testcase and

int i, j, k;
int l = 26;
struct S { char buf[32]; } m, n = { { 1 } };

C testcase.  Only p, l and n vars are protected.  For common, there is a
possibility to just use -fno-common, unless your sources rely on common
vars.

Jakub

Re: [asan] WIP protection of globals

[Xinliang David Li]

On Tue, Oct 16, 2012 at 11:51 PM, Jakub Jelinek ja...@redhat.com wrote:
 On Tue, Oct 16, 2012 at 04:19:09PM -0700, Xinliang David Li wrote:
 I am not sure -- fasan is an error detecting feature -- the goal is to
 find bugs -- missing handling of commons etc. are not desirable.
 Besides  if ABI changes consistently for all objects, why does it
 matter?

 Or making common/decl_one_only protected under an additional option.

 Note that LLVM doesn't protect common vars nor comdat linkage vars either
 (at least 3.1 release), as can be seen on

 struct A { int a; char b[64]; };
 inline A *foo ()
 {
   static A a;
   return a;
 }
 A *(*p) () = foo;

 C++ testcase and

 int i, j, k;
 int l = 26;
 struct S { char buf[32]; } m, n = { { 1 } };

 C testcase.  Only p, l and n vars are protected.  For common, there is a
 possibility to just use -fno-common, unless your sources rely on common
 vars.

Ok -- but I doubt it is due to the concern of ABI breakage.

Note that the debug version of libstdc++ (for error checking) is ABI
breaking too.

David


 Jakub

[patch] unbreak iq2000 build a bit

[Steven Bosscher]

Hello,

iq2000 build is broken since at least r162089 (July 2010). I'm going
to commit this patch to fix this part of the build problem. It still
fails later one, but I don't care about that, I just want to make sure
my patch to make call_used_regs a function looking at
call_used_reg_set break things even further :-)

(Ceterum censeo targeta non sustentor esse delendam :-)

Ciao!
Steven


* config/iq2000/iq2000.h (call_used_regs): Remove definition.

Index: config/iq2000/iq2000.h
===
--- config/iq2000/iq2000.h  (revision 192525)
+++ config/iq2000/iq2000.h  (working copy)
@@ -560,10 +560,6 @@ while (0)

 #define FUNCTION_MODE SImode

-/* Standard GCC variables that we reference.  */
-
-extern charcall_used_regs[];
-
 /* IQ2000 external variables defined in iq2000.c.  */

 /* Comparison type.  */

Re: [PATCH][RFC] Re-organize how we stream trees in LTO

[Richard Biener]

On Tue, 16 Oct 2012, Diego Novillo wrote:

 On 2012-10-16 10:43 , Richard Biener wrote:
  
  This patch shows work-in-progress (read: implementation uglyness
  hopefully to vanish ...) regarding to moving LTO type merging
  work from WPA to compile stage.
 
 You mean to LTRANS, the stage after WPA, right?

No, to compile stage, before WPA.  Obviously I can only move
the non-merging parts of type merging there ;)

  The patch re-organizes lto_output_tree (the write_tree streamer
  hook for LTO) in a way so that we output all tree fields
  in easy to discover places.  This means that we have forward
  references to trees not yet (fully) written, something the
  current state avoids by inline-expanding forward referenced
  trees at the point of reference (which results in interweaved
  trees on disk).  To be able to achieve this lto_output_tree
  now performs a DFS walk along tree edges to collect trees
  that need to be output and outputs them in SCC chunks
  in a new LTO stream container, LTO_tree_scc.
 
 Nice.  The interleaved output is ugly.
 
  This will allow the reader side at WPA stage to call uniquify
  nodes on each tree SCC, avoiding completely the DFS walks done
  there (hopefully, we do DFS walks for both hashing and comparing
  there - note that WPA gathers type SCCs, not tree SCCs - a subtle
  difference that remains to be seen on whether it is important ...)
  
  One complication is how we handle streaming INTEGER_CSTs.
  When an INTEGER_CST refers to an already input type we can
  allocate it using the build_int_cst_wide routine which takes
  care of putting it into the appropriate hashtables for caching.
  If an INTEGER_CST is part of a SCC (TYPE_DOMAIN values are
  the most obvious cases) we now stream them as regular trees
  (they cannot already exist in any cache as the type is being
  read in) - but the patch does not yet populate the caches
  in case the type ends up prevailing (thus it will produce
  some unshared INTEGER_CSTs for now).
  
  One uglyness of the patch is how I mis-use the streamer hooks
  to switch the tree streamer routines from actually writing
  tree references to performing the DFS walk.  For the DFS walk
  I need information on the edge, thus a 'from' tree argument
  is added to the write_tree hook.  Eventually my plan was
  to transform this to a walk_tree-like interface.
  
  Diego - is PTH still live?  Thus, do I need to bother about
  inventing things in a way that can be hook-ized?
 
 We will eventually revive PPH.  But not in the short term.  I think it will
 come back when/if we start implementing C++ modules.  Jason, Lawrence, is that
 something that you see coming for the next standard?
 
 I suspect that the front end will need to distance itself from 'tree' and have
 its own streamable IL.  So, the hooks may not be something we need to keep
 long term.
 
 Emitting the trees in SCC groups should not affect the C++ streamer too much.
 It already is doing its own strategy of emitting tree headers so it can do
 declaration and type merging.  As long as the trees can be fully materialized
 from the SCC groups, it should be fine.
 
  forsee any complication for PTH or C++ modules the way
  I re-arranged things?  Any good (C++) ideas on how to
  design this lto_walk_tree?
 
 Sorry.  What lto_walk_tree?

Basically I'd like to unify the tree walks done by tree-streamer-out.c
(the recursion inherent in calling the streamer_write_tree hook),
by tree-streamer-in.c (same for streamer_reaad_tree) and eventually
lto_fixup_type by means of a lto_walk_tree which in C terms would
get a function pointer to invoke on each tree field (that LTO
cares about) in a tree.  With C++ instead of a function pointer and
a void * data argument you'd probably use a functor.

With the patch I introduced a third usage, the DFS walk (thus the
idea to somehow factor this out in a more elegant way than how I
have it factored by re-writing the hook)

  --- 44,50 
  tree itself.  The second boolean parameter specifies this for
  the tree itself, the first for all siblings that are streamed.
  The referencing mechanism is up to each streamer to implement.  */
  !   void (*write_tree) (struct output_block *, tree, tree, bool, bool);
 
 You want to document what the new 'tree' argument does here.

Ah, indeed.

  ! #define stream_write_tree_edge_shallow_non_ref(OB, FROM, TO, REF_P) \
  ! streamer_hooks.write_tree(OB, FROM, TO, REF_P, false)
 
 Why the stream_write_tree_edge() naming?  Not sure what you mean by this.

For the DFS walk I need to walk all 'edges' from a tree node, an
edge from tree node a to tree node b is the pair FROM, TO.

Any better idea?

Thanks,
Richard.

Re: Ping: RFA: add lock_length attribute to break branch-shortening cycles

[Richard Biener]

On Tue, Oct 16, 2012 at 9:35 PM, Joern Rennecke
joern.renne...@embecosm.com wrote:
 Quoting Richard Sandiford rdsandif...@googlemail.com:

 Joern Rennecke joern.renne...@embecosm.com writes:

 2012-10-04  Joern Rennecke  joern.renne...@embecosm.com

  * final.c (get_attr_length_1): Use direct recursion rather than
  calling get_attr_length.
  (get_attr_lock_length): New function.
  (INSN_VARIABLE_LENGTH_P): Define.
  (shorten_branches): Take HAVE_ATTR_lock_length into account.
  Don't overwrite non-delay slot insn lengths with the lengths of
  delay slot insns with same uid.
  * genattrtab.c (lock_length_str): New variable.
  (make_length_attrs): New parameter base.
  (main): Initialize lock_length_str.
  Generate lock_lengths attributes.
  * genattr.c (gen_attr): Emit declarations for lock_length
 attribute
 related functions.
 * doc/md.texi (node Insn Lengths): Document lock_length
 attribute.

 http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00383.html


 Sorry, this is really just repeating Richard B's comments, but I still
 don't understand why we need two attributes.  Why can't shorten_branches
 work with the existing length and simply make sure that the length doesn't
 decrease from one iteration to the next?  That seems to be how you
 implement
 CASE_VECTOR_SHORTEN_MODE.  It also means that we can continue to use the
 pessimistic algorithm for -O0.


 That does not really work for ARCompact, non-branch instructions are
 lengthened to align or un-align branch instructions.  Failure to
 correct the size of such instruction downwards when indicated messes
 not only up the directly affected branch, but also gets the alignment
 wrong downstream, and can even cause branches go out of range (blindsiding
 branch shortening) when there are interactions with explicit alignments
 for things like loops.
 Unless you think it's OK to poke the contents of the insn_length array from
 ADJUST_INSN_LENGTH.  That should work, but it'd require an extra parameter
 when you want to hookize this macro.


 You said in your reply that one of the reasons was to avoid
 interesting interactions with ADJUST_INSN_LENGTH.  But the
 previous minimum length would be applied after ADJUST_INSN_LENGTH,
 so I'm not sure why it's a factor.


 Well, for starters, the ARCompact ADJUST_INSN_LENGTH uses
 get_attr_lock_length when processing delayed-branch SEQUENCEs.
 And then there's the short/long instruction opcode distinction (function /
 attribute verify_short), which depends on alignment, and influences
 instruction length and conditional execution calculation.
 Without exact alignment information, branch scheduling becomes a crapshot.

 You might think I could subsume the length effect of the upsized
 instructions
 in the affected branch, but that doesn't work because the exact length is
 needed both for ADJUST_INSN_LENGTH, and in order to output the correct
 branch / jump output template.



 If lock_length is just an optimisation on top of that, then maybe
 it would help to split it out.


 Well, to the extent that branch shortening and scheduling are just
 optimizations, having the lock_length attribute is just an optimization.

 Well, we could split it anyway, and give ports without the need for
 multiple length attributes the benefit of the optimistic algorithm.

 I have attached a patch that implements this.

Looks reasonable to me, though I'm not familiar enough with the code
to approve it.

I'd strongly suggest to try harder to make things work for you without
the new attribute even though I wasn't really able to follow your reasoning
on why that wouldn't work.  It may be easier to motivate this change
once the port is in without that attribute so one can actually look at
the machine description and port details.

Richard.

 I first meant to test it for sh-elf, alas, PR54938 currently makes this
 impossible.
 So I used arm-eabi instead.  regression tests look OK, but libgcc.a and
 libc.a (newlib) are unchanged in size, while libdtfc++.a increaes by twelve
 bytes; more specifically, the size increase happens for the object file
 debug.o, which goes from 11028 to 11040 bytes.
 Likewise, cris-elf and mipsel-elf show a small increase in size of debug.o,
 with the rest of libstdc++.a unchanged in size.

 Generating and comparing the arm intermediate files debug.s shows a
 suspicious
 incidence of pathnames.  Using a longer build directory pathname makes no
 difference, though.
 OTOH, using a longer source directory pathname does.  So that leaves...
 makes no difference for building these libraries.
 It should stop endless looping in shorten_branches, though.  Albeit that
 is only releant for ports that do have some negative shorten_branch
 feedback.

Re: [patch] unbreak iq2000 build a bit

[nick clifton]

Hi Steven,


iq2000 build is broken since at least r162089 (July 2010). I'm going
to commit this patch to fix this part of the build problem.


Thanks.


It still
fails later one, but I don't care about that


FYI I have this patch installed in my local sources that allows the 
iq2000 port to build successfully.  I have not submitted it upstream yet 
because I am not sure if it is the correct fix for the problem.


Cheers
  Nick

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 192527)
+++ gcc/dwarf2out.c (working copy)
@@ -20092,11 +20092,13 @@
   ca_loc-call_arg_loc_note = loc_note;
   ca_loc-next = NULL;
   ca_loc-label = last_label;
-  gcc_assert (prev
-  (CALL_P (prev)
- || (NONJUMP_INSN_P (prev)
-  GET_CODE (PATTERN (prev)) == SEQUENCE
-  CALL_P (XVECEXP (PATTERN (prev), 0, 0);
+  while (prev != NULL_RTX
+ ! CALL_P (prev)
+ ! (NONJUMP_INSN_P (prev)
+   GET_CODE (PATTERN (prev)) == SEQUENCE
+   CALL_P (XVECEXP (PATTERN (prev), 0, 0
+   prev = prev_nonnote_nondebug_insn (prev);
+  gcc_assert (prev != NULL_RTX);
   if (!CALL_P (prev))
prev = XVECEXP (PATTERN (prev), 0, 0);
   ca_loc-tail_call_p = SIBLING_CALL_P (prev);

Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #4

[Joseph S. Myers]

On Tue, 16 Oct 2012, Michael Meissner wrote:

 It occurs to me that now that we've committed to GCC being done in C++, we
 could just make global_options{,_set} be a class instead of a structure.  So
 you could say:
 
   global_options.set_FOO (value)
 
 Or:
 
   global_options.set_FOO ();
   global_options.clear_FOO ();
 
 I could generate the macros (or inline functions) if you would prefer to stick
 the C style of doing things.  However, as an old C dinosaur, I'm not sure of
 all of the ramifications of doing this.  It just seems it would be cleaner to
 use the class structure, instead of passing pointers.

In general, as much as possible should use an instance of struct 
gcc_options that is passed explicitly to the relevant code (or associated 
with the function being compiled, etc.), rather than using global_options 
directly (explicitly or implicitly).

The existing way of doing that is using a pointer to a gcc_options 
structure.  With a class I'd think you'd still need to pass it around as 
either a pointer or a reference (even if you then use member functions for 
some operations on these structures), and I'm not aware of any particular 
advantage of using a reference.  I do not think most functions that happen 
to take a gcc_options pointer (often along with lots of other pointers to 
other pieces of state) are particularly suited to being member functions 
of gcc_options.

Given that existing practice is passing pointers around, I'd think that's 
appropriate for any new such functions / macros, unless and until we have 
some clear notion of when functionality should or should not be a member 
function of gcc_options.

-- 
Joseph S. Myers
jos...@codesourcery.com

[asan] Protection of stack vars (take 3)

[Jakub Jelinek]

On Tue, Oct 16, 2012 at 03:56:31PM -0700, Xinliang David Li wrote:
  1) I am not sure if the stack slot sharing is handled correctly. If I
  read the code correctly, the redzone var will be only created for the
  representative variable in a partition -- will this lead to false
  negatives? As I asked before, should stack slot sharing even turned
  on?
 
  I thought we don't merge stack slots if the vars have different size,
  apparently I've been wrong about that.  So I'll make sure those aren't
  shared with flag_asan.  When the size is the same, there should be no false
  negatives.
 
  2) Performance tuning -- it is probably better to skip those variables
  that are compiler generated -- is there any point guarding them?
 
  In my (admittedly very limited) testing only at -O0 some compiler generated
  vars (SSA_NAMEs) got guards.  The trouble here is -fasan -fstack-protector
  combination.  I wonder if there can be any DECL_ARTIFICIAL (or non-VAR_DECL/
  RESULT_DECL) decls for which stack_protect_decl_phase returns 1 or 2.
  If it is unlikely, the best might be to protect all phase 1 and 2 vars and
  if flag_asan call expand_stack_vars once more for partitions where any of
  the protected vars are user vars, and finally the current expand_stack_vars
  (NULL) which would not do any asan protection.
 
 
 Do we expect people to use -fasan together with -fstack-protector?  Is
 it enough to just skip those DECL_ARTIFICIAL ones? most of the
 ssa_name var decls are already skipped already.

Why can't they?  -fstack-protector is for some distros even on by default,
or others turn it on e.g. in the standard CFLAGS/CXXFLAGS for building
packages.  And -fstack-protector has a value even with -fasan, e.g. if you
call some function not instrumented with -fasan (some other library, etc.)
and pass an address of an automatic array etc. to it.

Anyway, here is (again, very lightly tested just by skimming assembly on a
few testcases) an updated patch that won't do stack slot sharing for
variables with different sizes, and will not put artificial vars/SSA_NAMEs
into protected stack block, but below it, unless -fstack-protector wants to
push those high in the frame.  Also, it attempts to find best var name
for each partition, say if some partition contains both some artificial
variable, some variable without name and some with name, it will pick the
non-artificial one with name.

Ok for asan?

2012-10-17  Jakub Jelinek  ja...@redhat.com

* Makefile.in (asan.o): Depend on $(EXPR_H) $(OPTABS_H).
(cfgexpand.o): Depend on asan.h.
* asan.c: Include expr.h and optabs.h.
(asan_shadow_set): New variable.
(asan_shadow_cst, asan_emit_stack_protection): New functions.
(asan_init_shadow_ptr_types): Initialize also asan_shadow_set.
* cfgexpand.c: Include asan.h.  Define HOST_WIDE_INT heap vector.
(partition_stack_vars): If i is large alignment and j small
alignment or vice versa, break out of the loop instead of continue,
and put the test earlier.  If flag_asan, break out of the loop
if for small alignment size is different.
(struct stack_vars_data): New type.
(expand_stack_vars): Add DATA argument.  Change PRED type to
function taking size_t argument instead of tree.  Adjust pred calls.
Fill DATA in and add needed padding in between variables if -fasan.
(defer_stack_allocation): Defer everything for flag_asan.
(stack_protect_decl_phase_1, stack_protect_decl_phase_2): Take
size_t index into stack_vars array instead of the decl directly.
(asan_decl_phase_3): New function.
(expand_used_vars): Return var destruction sequence.  Adjust
expand_stack_vars calls, add another one for flag_asan.  Call
asan_emit_stack_protection if expand_stack_vars added anything
to the vectors.
(expand_gimple_basic_block): Add disable_tail_calls argument.
(gimple_expand_cfg): Pass true to it if expand_used_vars returned
non-NULL.  Emit the sequence returned by expand_used_vars after
return_label.
* asan.h (asan_emit_stack_protection): New prototype.
(asan_shadow_set): New decl.
(ASAN_RED_ZONE_SIZE, ASAN_STACK_MAGIC_LEFT, ASAN_STACK_MAGIC_MIDDLE,
ASAN_STACK_MAGIC_RIGHT, ASAN_STACK_FRAME_MAGIC): Define.
(asan_protect_stack_decl): New inline.
* toplev.c (process_options): Also disable -fasan on
!FRAME_GROWS_DOWNWARDS targets.

--- gcc/Makefile.in.jj  2012-10-12 23:30:31.635325772 +0200
+++ gcc/Makefile.in 2012-10-15 09:40:40.287706610 +0200
@@ -2204,7 +2204,7 @@ stor-layout.o : stor-layout.c $(CONFIG_H
 asan.o : asan.c asan.h $(CONFIG_H) pointer-set.h \
$(SYSTEM_H) $(TREE_H) $(GIMPLE_H) \
output.h $(DIAGNOSTIC_H) coretypes.h $(TREE_DUMP_H) $(FLAGS_H) \
-   tree-pretty-print.h $(TARGET_H)
+   tree-pretty-print.h $(TARGET_H) $(EXPR_H) $(OPTABS_H)
 tree-ssa-tail-merge.o: 

Re: PR c++/54928 infinite ICE when reporting ICE on macro expansion

[Dodji Seketeli]

Hello Manuel,

Let's CC Gaby on this one as well.

Manuel López-Ibáñez lopeziba...@gmail.com writes:

 The problem is that the macro unwinder code is changing the original
 diagnostic type and not restoring it, so the code detecting that we
 ICE fails to abort, which triggers another ICE, and so on. But there
 is no point in modifying the original diagnostic, we can simply create
 a temporary copy and use that for macro unwinding.

We modify the context as well, and we set it back to its original value
before getting out.  Why not just doing the same for the diagnostic_info
type? I mean, just save diagnostics-kind before changing it, and set it
back to the saved value before getting out?  That is less expensive than
copying all of the diagnostic_info.

I don't intent to fight either way, but I'd be more inclined to just
setting the initial value back.  If the maintainers think otherwise,
I'll abide.

 Dodji, does it look ok? I am not sure how much testsuite coverage we
 have for the macro unwinder, so I hope I didn't mess it up in some
 non-trivial testcase.

The test cases for the unwinder are not really tight.  They are
mainly gcc.dg/cpp/macro-exp-tracking-{1,2,3}.c, AFAICT.

Also, the patch does some cleanup.  Maybe it'd be best to post the
cleanup by removing a useless variable and hoisting some variable
accesses; maybe that cleanup in a separate patch that would be committed
at the same time?

Thank you for your time.

-- 
Dodji

Re: [RFC] Fix spill failure at -O on 64-bit Windows

[Eric Botcazou]

 Does this still happen after my patch from yesterday to use DF_LIVE in IRA?

Yes, it even fails at -O2.

 Maybe add a cost-free dependency on the clobber, so that it's moved
 with the insn?

Maybe.  But I'm a little worried about (1) extending the lifetime of the hard 
register and (2) simply moving around a clobber of a hard register.

 And/or maybe punt on all likely_spilled hard registers if
 -fira-loop-pressure is not in effect, it's unlikely to be a win in any
 case.

I'd like to keep the change minimal, in particular restricted to uninitialized 
hard registers.  The failure mode is very specific (and might be unique to the 
64-bit ABI on Windows) so I'm not sure it's worth generalizing.

-- 
Eric Botcazou

[Patch, Fortran] PR54884 - Fix TREE_PUBLIC()=0 regression for module procedures

[Tobias Burnus]

In GCC 4.8, module variables/procedures are marked as TREE_PUBLIC() if 
they are PRIVATE and not publicly visible used in PUBLIC procedures; the 
latter happens either via generic interfaces or via specification 
expressions. (The bug is old [early 4.8] but due to a recent follow up 
patch, the chance to run into this issue has increased.)


This patch adds the public_use attribute logic (also) to 
resolve_function, before it was only in resolve_symbol.


When doing so, I realized that it was also set for other as the 
specification_expr variable wasn't properly reset. I fixed that but I 
had also to add a few additional specification_expr = true as the 
current code only handled gfc_resolve_array_spec by chance.


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias
2012-10-17  Tobias Burnus  bur...@net-b.de

	PR fortran/54884
	* resolve.c (specification_expr): Change to bool.
	(resolve_formal_arglist, resolve_symbol): Set
	specification_expr to true before resolving the array spec.
	(resolve_variable, resolve_charlen, resolve_fl_variable):
	Properly reset specification_expr.
	(resolve_function): Set public_use when used in
	a specification expr.

2012-10-17  Tobias Burnus  bur...@net-b.de

	PR fortran/54884
	* gfortran.dg/public_private_module_7.f90: New.

diff --git a/gcc/fortran/cpp.c b/gcc/fortran/cpp.c
index c45af39..f54ba96 100644
--- a/gcc/fortran/cpp.c
+++ b/gcc/fortran/cpp.c
@@ -38,6 +38,10 @@ along with GCC; see the file COPYING3.  If not see
 #include cppbuiltin.h
 #include mkdeps.h
 
+#ifndef TARGET_SYSTEM_ROOT
+# define TARGET_SYSTEM_ROOT NULL
+#endif
+
 #ifndef TARGET_CPU_CPP_BUILTINS
 # define TARGET_CPU_CPP_BUILTINS()
 #endif
@@ -267,7 +271,7 @@ gfc_cpp_init_options (unsigned int decoded_options_count,
 
   gfc_cpp_option.multilib = NULL;
   gfc_cpp_option.prefix = NULL;
-  gfc_cpp_option.sysroot = NULL;
+  gfc_cpp_option.sysroot = TARGET_SYSTEM_ROOT;
 
   gfc_cpp_option.deferred_opt = XNEWVEC (gfc_cpp_deferred_opt_t,
 	 decoded_options_count);
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 722e036..ac3021e 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -81,7 +81,7 @@ static int omp_workshare_flag;
 static int formal_arg_flag = 0;
 
 /* True if we are resolving a specification expression.  */
-static int specification_expr = 0;
+static bool specification_expr = false;
 
 /* The id of the last entry seen.  */
 static int current_entry_id;
@@ -278,6 +278,7 @@ resolve_formal_arglist (gfc_symbol *proc)
 {
   gfc_formal_arglist *f;
   gfc_symbol *sym;
+  bool saved_specification_expr;
   int i;
 
   if (proc-result != NULL)
@@ -336,7 +337,10 @@ resolve_formal_arglist (gfc_symbol *proc)
   as = sym-ts.type == BT_CLASS  sym-attr.class_ok
 	   ? CLASS_DATA (sym)-as : sym-as;
 
+  saved_specification_expr = specification_expr;
+  specification_expr = true;
   gfc_resolve_array_spec (as, 0);
+  specification_expr = saved_specification_expr;
 
   /* We can't tell if an array with dimension (:) is assumed or deferred
 	 shape until we know if it has the pointer or allocatable attributes.
@@ -3119,6 +3123,12 @@ resolve_function (gfc_expr *expr)
   return FAILURE;
 }
 
+  if (sym  specification_expr  sym-attr.function
+   gfc_current_ns-proc_name
+   gfc_current_ns-proc_name-attr.flavor == FL_MODULE)
+sym-attr.public_used = 1;
+
+
   /* Switch off assumed size checking and do this again for certain kinds
  of procedure, once the procedure itself is resolved.  */
   need_full_assumed_size++;
@@ -5368,7 +5378,7 @@ resolve_variable (gfc_expr *e)
   gfc_entry_list *entry;
   gfc_formal_arglist *formal;
   int n;
-  bool seen;
+  bool seen, saved_specification_expr;
 
   /* If the symbol is a dummy...  */
   if (sym-attr.dummy  sym-ns == gfc_current_ns)
@@ -5401,7 +5411,8 @@ resolve_variable (gfc_expr *e)
 	}
 
   /* Now do the same check on the specification expressions.  */
-  specification_expr = 1;
+  saved_specification_expr = specification_expr;
+  specification_expr = true;
   if (sym-ts.type == BT_CHARACTER
 	   gfc_resolve_expr (sym-ts.u.cl-length) == FAILURE)
 	t = FAILURE;
@@ -5409,14 +5420,12 @@ resolve_variable (gfc_expr *e)
   if (sym-as)
 	for (n = 0; n  sym-as-rank; n++)
 	  {
-	 specification_expr = 1;
 	 if (gfc_resolve_expr (sym-as-lower[n]) == FAILURE)
 	   t = FAILURE;
-	 specification_expr = 1;
 	 if (gfc_resolve_expr (sym-as-upper[n]) == FAILURE)
 	   t = FAILURE;
 	  }
-  specification_expr = 0;
+  specification_expr = saved_specification_expr;
 
   if (t == SUCCESS)
 	/* Update the symbol's entry level.  */
@@ -10175,28 +10184,35 @@ static gfc_try
 resolve_charlen (gfc_charlen *cl)
 {
   int i, k;
+  bool saved_specification_expr;
 
   if (cl-resolved)
 return SUCCESS;
 
   cl-resolved = 1;
-
+  saved_specification_expr = specification_expr;
+  specification_expr = true;
 
   if 

Re: Do not drop the loop bounds when copying it

[Richard Biener]

On Tue, 16 Oct 2012, Jan Hubicka wrote:

 Hi,
 while looking into cases where loop-iv.c still deduce useful bounds that are 
 not
 recorded by tree level I noticed that we do not duplicate the bounds when 
 copying
 the loop.
 Fixed thus.
 Bootstrapped/regtested x86_64-linux, OK?

Ok.

Thanks,
Richard.

 Honza
 
   * cfgloopmanip.c (copy_loop_info): New function.
   (duplicate_loop): Use it.
   (loop_version): Use it.
   * loop-unswitch.c (unswitch_loop): Use it.
   * cfgloop.h (copy_loop_info): Declare.
 Index: cfgloopmanip.c
 ===
 --- cfgloopmanip.c(revision 192483)
 +++ cfgloopmanip.c(working copy)
 @@ -971,6 +970,20 @@ fix_loop_placements (struct loop *loop, 
  }
  }
  
 +/* Duplicate loop bounds and other information we store about
 +   the loop into its duplicate.  */
 +
 +void
 +copy_loop_info (struct loop *loop, struct loop *target)
 +{
 +  gcc_checking_assert (!target-any_upper_bound  !target-any_estimate);
 +  target-any_upper_bound = loop-any_upper_bound;
 +  target-nb_iterations_upper_bound = loop-nb_iterations_upper_bound;
 +  target-any_estimate = loop-any_estimate;
 +  target-nb_iterations_estimate = loop-nb_iterations_estimate;
 +  target-estimate_state = loop-estimate_state;
 +}
 +
  /* Copies copy of LOOP as subloop of TARGET loop, placing newly
 created loop into loops structure.  */
  struct loop *
 @@ -979,6 +992,8 @@ duplicate_loop (struct loop *loop, struc
struct loop *cloop;
cloop = alloc_loop ();
place_new_loop (cloop);
 + 
 +  copy_loop_info (loop, cloop);
  
/* Mark the new loop as copy of LOOP.  */
set_loop_copy (loop, cloop);
 @@ -1687,6 +1702,8 @@ loop_version (struct loop *loop,
  false /* Do not redirect all edges.  */,
  then_scale, else_scale);
  
 +  copy_loop_info (loop, nloop);
 +
/* loopify redirected latch_edge. Update its PENDING_STMTS.  */
lv_flush_pending_stmts (latch_edge);
  
 Index: loop-unswitch.c
 ===
 --- loop-unswitch.c   (revision 192483)
 +++ loop-unswitch.c   (working copy)
 @@ -454,6 +454,7 @@ unswitch_loop (struct loop *loop, basic_
  BRANCH_EDGE (switch_bb), FALLTHRU_EDGE (switch_bb), true,
  prob, REG_BR_PROB_BASE - prob);
  
 +  copy_loop_info (loop, nloop);
/* Remove branches that are now unreachable in new loops.  */
remove_path (true_edge);
remove_path (false_edge);
 Index: cfgloop.h
 ===
 --- cfgloop.h (revision 192483)
 +++ cfgloop.h (working copy)
 @@ -310,6 +310,7 @@ extern edge create_empty_if_region_on_ed
  extern struct loop *create_empty_loop_on_edge (edge, tree, tree, tree, tree,
  tree *, tree *, struct loop *);
  extern struct loop * duplicate_loop (struct loop *, struct loop *);
 +extern void copy_loop_info (struct loop *loop, struct loop *target);
  extern void duplicate_subloops (struct loop *, struct loop *);
  extern bool duplicate_loop_to_header_edge (struct loop *, edge,
  unsigned, sbitmap, edge,
 
 

-- 
Richard Biener rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend

[PING][Patch, ARM] cleanup prologue_use pattern

[Greta Yorsh]

Ping!

Thanks,
Greta

-Original Message-
From: Greta Yorsh [mailto:greta.yo...@arm.com] 
Sent: 10 October 2012 16:14
To: GCC Patches
Cc: Ramana Radhakrishnan; Richard Earnshaw; ni...@redhat.com;
p...@codesourcery.com
Subject: [Patch, ARM] cleanup prologue_use pattern

The pattern prologue_use is emitted for both prologue and epilogue.
In particular, the assembly comment
@sp needed for prologue
is printed out for both prologue and epilogue.

This patch adds a separate pattern for epilogue_use and replaces
prologue_use with epilogue_use where appropriate.

No regression on qemu for arm-none-eabi.

Ok for trunk?

Thanks,
Greta

2012-09-17  Greta Yorsh  greta.yo...@arm.com

* config/arm/arm.md (UNSPEC_EPILOGUE_USE): New unspec value.
(sibcall_epilogue): Use UNSPEC_EPILOGUE_USE instead of
UNSPEC_PROLOGUE_USE.
(epilogue_use): New define_insn.
(epilogue): Use gen_epilogue_use instead of gen_prologue_use.
* config/arm/arm.c (arm_expand_epilogue): Likewise.
(thumb1_expand_epilogue) Likewise.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index dd073da..f23c2d0 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -22581,7 +22581,7 @@ thumb1_expand_epilogue (void)
 
   /* Emit a USE (stack_pointer_rtx), so that
  the stack adjustment will not be deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
 
   if (crtl-profile || !TARGET_SCHED_PROLOG)
 emit_insn (gen_blockage ());
@@ -22805,7 +22805,7 @@ arm_expand_epilogue (bool really_return)
 
   /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment is not
  deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
 }
   else
 {
@@ -22823,7 +22823,7 @@ arm_expand_epilogue (bool really_return)
   emit_insn (gen_movsi (stack_pointer_rtx, hard_frame_pointer_rtx));
   /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment is not
  deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
 }
 }
   else
@@ -22841,7 +22841,7 @@ arm_expand_epilogue (bool really_return)
  GEN_INT (amount)));
   /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment is
  not deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
 }
 }
 
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index a60e659..6a910a3 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -81,6 +81,7 @@
 ; instructions setting registers for EH handling
 ; and stack frame generation.  Operand 0 is the
 ; register to use.
+  UNSPEC_EPILOGUE_USE   ; Same for epilogue.
   UNSPEC_CHECK_ARCH ; Set CCs to indicate 26-bit or 32-bit mode.
   UNSPEC_WSHUFH ; Used by the intrinsic form of the iWMMXt WSHUFH 
instruction.
   UNSPEC_WACC   ; Used by the intrinsic form of the iWMMXt WACC 
instruction.
@@ -10610,7 +10611,7 @@
   TARGET_EITHER
   
   if (crtl-calls_eh_return)
-emit_insn (gen_prologue_use (gen_rtx_REG (Pmode, 2)));
+emit_insn (gen_epilogue_use (gen_rtx_REG (Pmode, 2)));
   if (TARGET_THUMB1)
{
  thumb1_expand_epilogue ();
@@ -10644,7 +10645,7 @@
 ;; does not think that it is unused by the sibcall branch that
 ;; will replace the standard function epilogue.
 (define_expand sibcall_epilogue
-   [(parallel [(unspec:SI [(reg:SI LR_REGNUM)] UNSPEC_PROLOGUE_USE)
+   [(parallel [(unspec:SI [(reg:SI LR_REGNUM)] UNSPEC_EPILOGUE_USE)
(unspec_volatile [(return)] VUNSPEC_EPILOGUE)])]
TARGET_32BIT

@@ -11267,6 +11268,12 @@
   [(set_attr length 0)]
 )
 
+(define_insn epilogue_use
+  [(unspec:SI [(match_operand:SI 0 register_operand )] 
UNSPEC_EPILOGUE_USE)]
+  
+  %@ %0 needed for epilogue
+  [(set_attr length 0)]
+)
 
 ;; Patterns for exception handling

Re: [PING][Patch, ARM] cleanup prologue_use pattern

[Richard Earnshaw]

On 17/10/12 11:08, Greta Yorsh wrote:

Ping!



I've been pondering why this was being asked for.  As far as I can tell 
it's just a naming issue (mention of the epilogue in the prologue).


The right thing to do is to rename the pattern to reflect the dual use 
rather than add additional patterns with identical NOP behaviour.  Can't 
you just rename the existing pattern?  Something like force_register_use?


R.


Thanks,
Greta

-Original Message-
From: Greta Yorsh [mailto:greta.yo...@arm.com]
Sent: 10 October 2012 16:14
To: GCC Patches
Cc: Ramana Radhakrishnan; Richard Earnshaw; ni...@redhat.com;
p...@codesourcery.com
Subject: [Patch, ARM] cleanup prologue_use pattern

The pattern prologue_use is emitted for both prologue and epilogue.
In particular, the assembly comment
@sp needed for prologue
is printed out for both prologue and epilogue.

This patch adds a separate pattern for epilogue_use and replaces
prologue_use with epilogue_use where appropriate.

No regression on qemu for arm-none-eabi.

Ok for trunk?

Thanks,
Greta

2012-09-17  Greta Yorsh  greta.yo...@arm.com

 * config/arm/arm.md (UNSPEC_EPILOGUE_USE): New unspec value.
 (sibcall_epilogue): Use UNSPEC_EPILOGUE_USE instead of
 UNSPEC_PROLOGUE_USE.
 (epilogue_use): New define_insn.
 (epilogue): Use gen_epilogue_use instead of gen_prologue_use.
 * config/arm/arm.c (arm_expand_epilogue): Likewise.
 (thumb1_expand_epilogue) Likewise.


rename-prolog-use.v2.patch.txt


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index dd073da..f23c2d0 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -22581,7 +22581,7 @@ thumb1_expand_epilogue (void)

/* Emit a USE (stack_pointer_rtx), so that
   the stack adjustment will not be deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));

if (crtl-profile || !TARGET_SCHED_PROLOG)
  emit_insn (gen_blockage ());
@@ -22805,7 +22805,7 @@ arm_expand_epilogue (bool really_return)

/* Emit USE(stack_pointer_rtx) to ensure that stack adjustment is 
not
   deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
  }
else
  {
@@ -22823,7 +22823,7 @@ arm_expand_epilogue (bool really_return)
emit_insn (gen_movsi (stack_pointer_rtx, hard_frame_pointer_rtx));
/* Emit USE(stack_pointer_rtx) to ensure that stack adjustment is 
not
   deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
  }
  }
else
@@ -22841,7 +22841,7 @@ arm_expand_epilogue (bool really_return)
   GEN_INT (amount)));
/* Emit USE(stack_pointer_rtx) to ensure that stack adjustment is
   not deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
  }
  }

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index a60e659..6a910a3 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -81,6 +81,7 @@
  ; instructions setting registers for EH handling
  ; and stack frame generation.  Operand 0 is the
  ; register to use.
+  UNSPEC_EPILOGUE_USE   ; Same for epilogue.
UNSPEC_CHECK_ARCH ; Set CCs to indicate 26-bit or 32-bit mode.
UNSPEC_WSHUFH ; Used by the intrinsic form of the iWMMXt WSHUFH 
instruction.
UNSPEC_WACC   ; Used by the intrinsic form of the iWMMXt WACC 
instruction.
@@ -10610,7 +10611,7 @@
TARGET_EITHER

if (crtl-calls_eh_return)
-emit_insn (gen_prologue_use (gen_rtx_REG (Pmode, 2)));
+emit_insn (gen_epilogue_use (gen_rtx_REG (Pmode, 2)));
if (TARGET_THUMB1)
 {
   thumb1_expand_epilogue ();
@@ -10644,7 +10645,7 @@
  ;; does not think that it is unused by the sibcall branch that
  ;; will replace the standard function epilogue.
  (define_expand sibcall_epilogue
-   [(parallel [(unspec:SI [(reg:SI LR_REGNUM)] UNSPEC_PROLOGUE_USE)
+   [(parallel [(unspec:SI [(reg:SI LR_REGNUM)] UNSPEC_EPILOGUE_USE)
 (unspec_volatile [(return)] VUNSPEC_EPILOGUE)])]
 TARGET_32BIT
 
@@ -11267,6 +11268,12 @@
[(set_attr length 0)]
  )

+(define_insn epilogue_use
+  [(unspec:SI [(match_operand:SI 0 register_operand )] 
UNSPEC_EPILOGUE_USE)]
+  
+  %@ %0 needed for epilogue
+  [(set_attr length 0)]
+)

  ;; Patterns for exception handling

Re: [RFC] VEC interface overhaul

[Richard Biener]

On Tue, 16 Oct 2012, Diego Novillo wrote:

 I have overhauled the interface to VEC over the last few
 weeks.  I implemented most of the plan I outlined in
 http://gcc.gnu.org/ml/gcc/2012-08/msg00268.html.
 
 I have implemented the embedded and space-efficient vectors.  The
 diff for vec.[ch] is sufficiently confusing that I'm just
 attaching both files for review.
 
 In this message, I want to outline the major changes I've done.
 The patch still does not work (gengtype is giving me a LOT of
 problems because vectors are not pointers anymore).
 
 There are two new types:
 
 1- Embedded vectors: vec_eelement_type
 
These are fixed-size vectors useful to be embedded in
structures.  For instance, tree_binfo::base_binfos.  They use
the trailing array idiom.  Once allocated, they cannot be
re-sized.

 
 2- Space efficient vectors: vec_selement_type, allocation

These are the traditional VECs we have always used.  They are
implemented as a pointer to a vec_eelement_type.  The
difference with traditional VECs is that they no longer need
to be pointer themselves, so their address does not change if
the internal vector needs to be re-allocated.  They still use
just a single word of storage before allocation, so they can
be embedded in data structures without altering their size.

Why change the name?  I'd have used vec ...

Can't we implement vec_e as vecelement_type, embedded by
means of a partial specialization?

Sorry for the bike-shedding ;)

 I have not yet implemented the fast vectors from my proposal.
 Those would be useful for free variables or structures that can
 tolerate an extra word of storage.
 
 Needless to say the patch is gigantic: 2.4 Mb, 334 files
 changed, 10718 insertions(+), 11536 deletions(-).  But it is
 largely mechanic.
 
 We no longer access the vectors via VEC_* macros.  The pattern is
 VEC_operation (T, A, V, args) becomes V.operation (args).
 That is mostly why you see ~800 fewer lines in the patch.
 
 The only thing I could not do is create proper ctors and dtors
 for the vec_s/vec_e classes.  Since these vectors are stored in
 unions, we have to keep them as PODs (C++03 does not allow
 non-PODs in unions).
 
 This means that creation and destruction must be explicit.  There
 is a new method vec_stype, allocation::create() and another
 vec_stype, allocation::destroy() to allocate the internal
 vector.

::alloc() and ::free()?  I see you have those, too, but from

  /* Vector allocation.  */
  static vec_sT, A *alloc (unsigned CXX_MEM_STAT_INFO);
  static void free (vec_sT, A *);

  /* Internal vector creation and initialization.  */
  static vec_sT, A create (unsigned CXX_MEM_STAT_INFO);
  static vec_sT, A create (unsigned, vec_eT *);
  void destroy (void);

I can't see how they differ and what users should use?  I suppose
::create and ::destroy are just implementation details?  Thus
you'd make them private?  Why is create not a member function?
It should be IMHO

templatetypename T, enum vec_allocation A
inline vec_sT, A
vec_sT, A::create (unsigned nelems, vec_eT *space)
{
  gcc_assert (A == va_stack);
  this-stack_reserve (space, nelems);
  return *this;
}

Otherwise please use gcc_checking_assert in inline functions,
otherwise they won't be inlined due to size constraints in most
of the cases.

Likewise ::copy should mimic a copy constructor.  Not sure if
that will work out ... isn't it enough that vec_e is embeddable
into a union?

Otherwise thanks for working on this and sorry for the C++
bikeshedding - there are just so many more ways to do something
in C++ compared to C ;)

Richard.

 My next steps are:
 
 - Fix gengtype issues.  Since the GTY(()) vectors are not
   pointers, gengtype is ignoring them, not adding roots and
   marking functions.  I think I've almost fixed it, but it will
   take me another day or two.
 
 - Test on all affected architectures and compilation modes.
 
 - Make sure memory consumption and performance are still on par
   with the current implementation.
 
 Things I want to change (that I may do in subsequent patches):
 
 - The allocation strategy ought to be an allocator type not an
   enum.
 
 - vec_sT, A::iterate should disappear.  Instead, we want to use
   standard iterator idioms.
 
 
 Please take a look at vec.[ch].  I have also pushed my changes to
 the git branch git://gcc.gnu.org/git/gcc.git/dnovillo/vec-rewrite
 (it's based on today's trunk).
 
 Comments?
 
 
 Thanks.  Diego.
 

-- 
Richard Biener rguent...@suse.de
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend

[PATCH][LTO] Change DECL_ARGUMENTS streaming

[Richard Biener]

This changes how we stream DECL_ARGUMENTS because the way we do it
now (recursing over TREE_CHAIN of the PARM_DECLs) puts quite a burden
on stack use for limits-fndefn.c.  The following changes streaming
that chain to how we stream all other chains (apart from TREE_LISTs
which we arguably should change as well).

LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2012-10-17  Richard Biener  rguent...@suse.de

* tree-streamer-out.c (write_ts_decl_common_tree_pointers):
Do not write TREE_CHAIN of PARM_DECLs.
(write_ts_decl_non_common_tree_pointers): Instead stream
the DECL_ARGUMENTS chain.
* tree-streamer-in.c (lto_input_ts_decl_common_tree_pointers):
Do not read TREE_CHAIN of PARM_DECLs.
(lto_input_ts_decl_non_common_tree_pointes): Instead read
the DECL_ARGUMENTS as chain.

Index: gcc/tree-streamer-out.c
===
*** gcc/tree-streamer-out.c (revision 192499)
--- gcc/tree-streamer-out.c (working copy)
*** write_ts_decl_common_tree_pointers (stru
*** 562,570 
   for early inlining so drop it on the floor instead of ICEing in
   dwarf2out.c.  */
  
-   if (TREE_CODE (expr) == PARM_DECL)
- streamer_write_chain (ob, TREE_CHAIN (expr), ref_p);
- 
if ((TREE_CODE (expr) == VAR_DECL
 || TREE_CODE (expr) == PARM_DECL)
 DECL_HAS_VALUE_EXPR_P (expr))
--- 562,567 
*** write_ts_decl_non_common_tree_pointers (
*** 585,591 
  {
if (TREE_CODE (expr) == FUNCTION_DECL)
  {
!   stream_write_tree (ob, DECL_ARGUMENTS (expr), ref_p);
stream_write_tree (ob, DECL_RESULT (expr), ref_p);
  }
else if (TREE_CODE (expr) == TYPE_DECL)
--- 582,588 
  {
if (TREE_CODE (expr) == FUNCTION_DECL)
  {
!   streamer_write_chain (ob, DECL_ARGUMENTS (expr), ref_p);
stream_write_tree (ob, DECL_RESULT (expr), ref_p);
  }
else if (TREE_CODE (expr) == TYPE_DECL)
Index: gcc/tree-streamer-in.c
===
*** gcc/tree-streamer-in.c  (revision 192499)
--- gcc/tree-streamer-in.c  (working copy)
*** lto_input_ts_decl_common_tree_pointers (
*** 643,651 
   for early inlining so drop it on the floor instead of ICEing in
   dwarf2out.c.  */
  
-   if (TREE_CODE (expr) == PARM_DECL)
- TREE_CHAIN (expr) = streamer_read_chain (ib, data_in);
- 
if ((TREE_CODE (expr) == VAR_DECL
 || TREE_CODE (expr) == PARM_DECL)
 DECL_HAS_VALUE_EXPR_P (expr))
--- 643,648 
*** lto_input_ts_decl_non_common_tree_pointe
*** 670,676 
  {
if (TREE_CODE (expr) == FUNCTION_DECL)
  {
!   DECL_ARGUMENTS (expr) = stream_read_tree (ib, data_in);
DECL_RESULT (expr) = stream_read_tree (ib, data_in);
  }
else if (TREE_CODE (expr) == TYPE_DECL)
--- 667,673 
  {
if (TREE_CODE (expr) == FUNCTION_DECL)
  {
!   DECL_ARGUMENTS (expr) = streamer_read_chain (ib, data_in);
DECL_RESULT (expr) = stream_read_tree (ib, data_in);
  }
else if (TREE_CODE (expr) == TYPE_DECL)

Re: Make try_unroll_loop_completely to use loop bounds recorded

[Richard Biener]

On Tue, 16 Oct 2012, Jan Hubicka wrote:

 Hi,
 here is third revised version of the complette unroling changes.  While 
 working
 on the RTL variant I noticed PR54937 and the fact that I was overly aggressive
 on forcing single exit of the last iteration to be taken, because loop may 
 terminate
 otherwise (by EH or by exitting the program).  Same thinko is in loop-niter.
 
 This patch adds loop_edge_to_cancel that is more conservative: it looks for 
 the
 exit conditional where the non-exitting edges leads to latch and verifies that
 latch contains no statement with side effect that may terminate the loop.
 This still actually matches quite few non-single-exit loops and works well in
 practice.
 
 Unlike previous revision it also enables complette unrolling when code size
 does not grow even for non-innermost loops (with update in
 tree_unroll_loops_completely to walk them). This is something we did on RTL
 land but missed in trees.  This actually enables quite some optimizations when
 things can be propagated to the tiny inner loop body.
 
 I also fixed accounting in tree_estimate_loop_size for the cases where last
 iteration is not going to be updated.
 
 Finally I added code constructing __bulitin_unreachable as suggested by
 Ian.
 
 Bootstrapped/regtested x86_64-linux, also bootstrapped with -O3 and -Werror
 disabled and benchmarked. Among best benefits is about 7% improvement on 
 Applu,
 and it causes up to 15% improvements on vectorized loops with small iteration
 counts (by completelly peeling the precondition code).  There are no real
 performance regressions but there is some code size bloat.  
 
 I plan to followup with strenghtening the heuristic to disable unrolling when
 benefits are absymal.  Easy is to limit unrolling on loops with CFG and/or
 calls in them.  We already have quite informed analysis in place.  I also plan
 to move simple FDO guided loop peeling from RTL level to trees to enable more
 propagation into peeled sequences.
 
 The patch also triggers bug in niter and requires xfailing do_1.f90 testcase.
 I filled PR 54932 to track this.
 
 There are also confused array bound warnings I hope to track incrementally, 
 too,
 by recording statements that are known to become unreachable in the last
 iteration and adding __buitin_unreachable in front of them. This is also
 important to avoid duplication leading to dead code: no other optimizers
 force paths leading to out of bound accesses to not happen.

Quite a large patch ... it could have been split into bugfixes
and enhancements ;)

Still - ok!

Thanks,
Richard.

 Honza
 
 
   * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Add edge_to_cancel
   parameter and use it to estimate code optimized out in the final 
 iteration.
   (loop_edge_to_cancel): New function.
   (try_unroll_loop_completely): New IRRED_IVALIDATED parameter;
   handle unrolling loops with bounds given via max_loop_iteratins;
   handle unrolling non-inner loops when code size shrinks;
   tidy dump output; when the last iteration loop still stays
   as loop in the CFG forcongly redirect the latch to
   __builtin_unreachable.
   (canonicalize_loop_induction_variables): Add irred_invlaidated
   parameter; record niter bound derrived; dump
   max_loop_iterations bounds; call try_unroll_loop_completely
   even if no niter bound is given.
   (canonicalize_induction_variables): Handle irred_invalidated.
   (tree_unroll_loops_completely): Handle non-innermost loops;
   handle irred_invalidated.
   * cfgloop.h (unlop): Declare.
   * cfgloopmanip.c (unloop): Export.
   * tree.c (build_common_builtin_nodes): Build BULTIN_UNREACHABLE.
 
   * gcc.target/i386/l_fma_float_?.c: Update.
   * gcc.target/i386/l_fma_double_?.c: Update.
   * gfortran.dg/do_1.f90: XFAIL
   * gcc.dg/tree-ssa/cunroll-1.c: New testcase.
   * gcc.dg/tree-ssa/cunroll-2.c: New testcase.
   * gcc.dg/tree-ssa/cunroll-3.c: New testcase.
   * gcc.dg/tree-ssa/cunroll-4.c: New testcase.
   * gcc.dg/tree-ssa/cunroll-5.c: New testcase.
   * gcc.dg/tree-ssa/ldist-17.c: Block cunroll to make testcase still
   valid.
 Index: tree-ssa-loop-ivcanon.c
 ===
 --- tree-ssa-loop-ivcanon.c   (revision 192483)
 +++ tree-ssa-loop-ivcanon.c   (working copy)
 @@ -192,7 +192,7 @@ constant_after_peeling (tree op, gimple 
 Return results in SIZE, estimate benefits for complete unrolling exiting 
 by EXIT.  */
  
  static void
 -tree_estimate_loop_size (struct loop *loop, edge exit, struct loop_size 
 *size)
 +tree_estimate_loop_size (struct loop *loop, edge exit, edge edge_to_cancel, 
 struct loop_size *size)
  {
basic_block *body = get_loop_body (loop);
gimple_stmt_iterator gsi;
 @@ -208,8 +208,8 @@ tree_estimate_loop_size (struct loop *lo
  fprintf (dump_file, Estimating sizes for loop %i\n, loop-num);
for (i = 0; i  

[RFA ARM/4.7] Backport Split all insns before pool placement

[Matthew Gretton-Dann]

All,

Ulrich posted the following patch in July:
   http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01123.html

Richard E requested that it be left in testing on trunk for a couple of days 
before being backported to 4.7.  Three months seems to satisfy the 'couple of 
days' requirement :-).

Is this OK to be backported to 4.7?  Cross tested arm-none-linux-gnueabi.

Thanks,

Matt

2012-10-15  Matthew Gretton-Dann  matthew.gretton-d...@linaro.org

   Backported from mainline
   2012-07-23  Ulrich Weigand  ulrich.weig...@linaro.org

   * config/arm/arm.c (arm_reorg): Ensure all insns are split.

-- 
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.orgdiff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 35b73c5..3796a80 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13337,6 +13337,13 @@ arm_reorg (void)
   if (TARGET_THUMB2)
 thumb2_reorg ();
 
+  /* Ensure all insns that must be split have been split at this point.
+ Otherwise, the pool placement code below may compute incorrect
+ insn lengths.  Note that when optimizing, all insns have already
+ been split at this point.  */
+  if (!optimize)
+split_all_insns_noflow ();
+
   minipool_fix_head = minipool_fix_tail = NULL;
 
   /* The first insn must always be a note, or the code below won't

[asan] Protection of globals

[Jakub Jelinek]

On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
 On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek ja...@redhat.com wrote:
 Why the above two condition? If the linker picks the larger size one,
 it is ok to do the instrumentation.

Added more comments, creation of local aliases when needed, and construction
of global var description strings.
Again, only very lightly tested.

__has_dynamic_init is still always 0, setting it to non-zero would require
dynamic initialization order support, which I'll happily leave to others.

And the addresses are still absolute (i.e. the global vars descriptor is
still likely .data.relro.local section for -fpic), both the __beg and
__name fields, but changing it would require first libasan changes.

Ok for asan?

2012-10-17  Jakub Jelinek  ja...@redhat.com

* varasm.c: Include asan.h.
(assemble_noswitch_variable): Grow size by asan_red_zone_size
if decl is asan protected.
(place_block_symbol): Likewise.
(assemble_variable): If decl is asan protected, increase
DECL_ALIGN if needed, and for decls emitted using
assemble_variable_contents append padding zeros after it.
* Makefile.in (varasm.o): Depend on asan.h.
* asan.c: Include output.h.
(asan_pp, asan_pp_initialized): New variables.
(asan_pp_initialize, asan_pp_string): New functions.
(asan_emit_stack_protection): Use asan_pp{,_initialized}
instead of local pp{,_initialized} vars, use asan_pp_initialize
and asan_pp_string helpers.
(asan_needs_local_alias, asan_protect_global,
asan_global_struct, asan_add_global): New functions.
(asan_finish_file): Protect global vars that can be protected.
* asan.h (asan_protect_global): New prototype.
(asan_red_zone_size): New inline function.

--- gcc/varasm.c.jj 2012-10-11 19:10:39.0 +0200
+++ gcc/varasm.c2012-10-16 15:40:37.075662625 +0200
@@ -51,6 +51,7 @@ along with GCC; see the file COPYING3.
 #include tree-mudflap.h
 #include cgraph.h
 #include pointer-set.h
+#include asan.h
 
 #ifdef XCOFF_DEBUGGING_INFO
 #include xcoffout.h  /* Needed for external data
@@ -1831,6 +1832,9 @@ assemble_noswitch_variable (tree decl, c
   size = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
   rounded = size;
 
+  if (flag_asan  asan_protect_global (decl))
+size += asan_red_zone_size (size);
+
   /* Don't allocate zero bytes of common,
  since that means undefined external in the linker.  */
   if (size == 0)
@@ -1897,6 +1901,7 @@ assemble_variable (tree decl, int top_le
   const char *name;
   rtx decl_rtl, symbol;
   section *sect;
+  bool asan_protected = false;
 
   /* This function is supposed to handle VARIABLES.  Ensure we have one.  */
   gcc_assert (TREE_CODE (decl) == VAR_DECL);
@@ -1984,6 +1989,15 @@ assemble_variable (tree decl, int top_le
   /* Compute the alignment of this data.  */
 
   align_variable (decl, dont_output_data);
+
+  if (flag_asan
+   asan_protect_global (decl)
+   DECL_ALIGN (decl)  ASAN_RED_ZONE_SIZE * BITS_PER_UNIT)
+{
+  asan_protected = true;
+  DECL_ALIGN (decl) = ASAN_RED_ZONE_SIZE * BITS_PER_UNIT;
+}
+
   set_mem_align (decl_rtl, DECL_ALIGN (decl));
 
   if (TREE_PUBLIC (decl))
@@ -2022,6 +2036,12 @@ assemble_variable (tree decl, int top_le
   if (DECL_ALIGN (decl)  BITS_PER_UNIT)
ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (DECL_ALIGN_UNIT (decl)));
   assemble_variable_contents (decl, name, dont_output_data);
+  if (asan_protected)
+   {
+ unsigned HOST_WIDE_INT int size
+   = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
+ assemble_zeros (asan_red_zone_size (size));
+   }
 }
 }
 
@@ -6926,6 +6946,8 @@ place_block_symbol (rtx symbol)
   decl = SYMBOL_REF_DECL (symbol);
   alignment = DECL_ALIGN (decl);
   size = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
+  if (flag_asan  asan_protect_global (decl))
+   size += asan_red_zone_size (size);
 }
 
   /* Calculate the object's offset from the start of the block.  */
--- gcc/Makefile.in.jj  2012-10-15 09:40:40.0 +0200
+++ gcc/Makefile.in 2012-10-17 13:00:02.995133686 +0200
@@ -2712,7 +2712,7 @@ varasm.o : varasm.c $(CONFIG_H) $(SYSTEM
output.h $(DIAGNOSTIC_CORE_H) xcoffout.h debug.h $(GGC_H) $(TM_P_H) \
$(HASHTAB_H) $(TARGET_H) langhooks.h gt-varasm.h $(BASIC_BLOCK_H) \
$(CGRAPH_H) $(TARGET_DEF_H) tree-mudflap.h \
-   pointer-set.h $(COMMON_TARGET_H)
+   pointer-set.h $(COMMON_TARGET_H) asan.h
 function.o : function.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
$(RTL_ERROR_H) \
$(TREE_H) $(GIMPLE_H) $(FLAGS_H) $(FUNCTION_H) $(EXPR_H) \
$(OPTABS_H) $(LIBFUNCS_H) $(REGS_H) hard-reg-set.h insn-config.h $(RECOG_H) 
\
--- gcc/asan.c.jj   2012-10-16 12:18:41.0 +0200
+++ gcc/asan.c  2012-10-17 12:59:45.663228828 +0200
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.
 #include target.h
 

Re: RFC: LRA for x86/x86-64 [7/9] -- continuation

[Richard Sandiford]

Thanks for all the updates.

Vladimir Makarov vmaka...@redhat.com writes:
 + /* index * scale + disp = new base + index * scale  */
 + enum reg_class cl = base_reg_class (mode, as, SCRATCH, SCRATCH);
 +
 + lra_assert (INDEX_REG_CLASS != NO_REGS);
 + new_reg = lra_create_new_reg (Pmode, NULL_RTX, cl, disp);
 + lra_assert (GET_CODE (*addr_loc) == PLUS);
 + lra_emit_move (new_reg, *ad.disp_loc);
 + if (CONSTANT_P (XEXP (*addr_loc, 1)))
 +   XEXP (*addr_loc, 1) = XEXP (*addr_loc, 0);
 + XEXP (*addr_loc, 0) = new_reg;
 The canonical form is (plus (mult ...) (reg)) rather than
 (plus (reg) (mult ...)), but it looks like we create the latter.
 I realise you try both forms here:
 It might happen because equiv substitution in LRA.
 + /* Some targets like ARM, accept address operands in
 +specific order -- try exchange them if necessary.  */
 + if (! valid_address_p (mode, *addr_loc, as))
 +   {
 + exchange_plus_ops (*addr_loc);
 + if (! valid_address_p (mode, *addr_loc, as))
 +   exchange_plus_ops (*addr_loc);
 +   }
 but I think we should try the canonical form first.  And I'd prefer it
 if we didn't try the other form at all, especially in 4.8.  It isn't
 really the backend's job to reject non-canonical rtl.  This might well
 be another case where some targets need a (hopefully small) tweak in
 order to play by the rules.

 Also, I suppose this section of code feeds back to my question on
 Wednesday about the distinction that LRA seems to make between the
 compile-time constant in:

(plus (reg X1) (const_int Y1))

 and the link-time constant in:

(plus (reg X2) (symbol_ref Y2))

 It looked like extract_address_regs classified X1 as a base register and
 X2 as an index register.  The difference between the two constants has
 no run-time significance though, and I think we should handle both X1
 and X2 as base registers (as I think reload does).

 I think the path above would then be specific to scaled indices.
 In the original address the complex index must come first and the
 displacement second.  In the modified address, the index would stay
 first and the new base register would be second.  More below.
 As I wrote above the problem is also in that equiv substitution can 
 create non-canonical forms.

Right.  Just in case there's a misunderstanding: I'm not complaining
about these routines internally using forms that are noncanonical
(which could happen because of equiv substitution, like you say).
I just think that what we eventually try to validate should be canonical.
In a way it's similar to how the simplify-rtx.c routines work.

If there are targets that only accept noncanonical rtl (which is after
all just a specific type of invalid rtl), they need to be fixed.

 +  /* base + scale * index + disp = new base + scale * index  */
 +  new_reg = base_plus_disp_to_reg (mode, as, ad);
 +  *addr_loc = gen_rtx_PLUS (Pmode, new_reg, *ad.index_loc);
 +  if (! valid_address_p (mode, *addr_loc, as))
 +   {
 + /* Some targets like ARM, accept address operands in
 +specific order -- try exchange them if necessary.  */
 + exchange_plus_ops (*addr_loc);
 + if (! valid_address_p (mode, *addr_loc, as))
 +   exchange_plus_ops (*addr_loc);
 +   }
 Same comment as above about canonical rtl.  Here we can have two
 registers -- in which case the base should come first -- or a more
 complex index -- in which case the index should come first.

 We should be able to pass both rtxes to simplify_gen_binary (PLUS, ...),
 with the operands in either order, and let it take care of the details.
 Using simplify_gen_binary would help with the earlier index+disp case too.
 Equiv substitution can create non-canonical forms.  There are 2 approaches:
 o have a code for dealing with non-canonical forms (equiv substitution, 
 target stupidity)
 o always support canonical forms and require them from targets.

 I decided to use the 1st variant but I am reconsidering it.  I'll try to 
 fix before inclusion.  But I am not sure I have time for this.  All 
 these changes makes LRA unstable. In fact, I've just found that changes 
 I already made so far resulted in 2 SPEC2000 tests broken although GCC 
 testsuite and bootstrap looks good.

OK.  I'm happy to try fixing the noncanonical thing.

 +  /* If this is post-increment, first copy the location to the reload reg. 
  */
 +  if (post  real_in != result)
 +emit_insn (gen_move_insn (result, real_in));
 Nit, but real_in != result can never be true AIUI, and I was confused how
 the code could be correct in that case.  Maybe just remove it, or make
 it an assert?
 No, it might be true:

 real_in = in == value ? incloc : in;
 ...
 if (cond)
result = incloc;
 else
result = ...

 if (post  real_in != result)

 So it is true if in==value  cond

Sorry, what I meant was that cond is ! post  REG_P (incloc):

  if (! post  REG_P (incloc))
result = incloc;
  else

Re: PR c++/54928 infinite ICE when reporting ICE on macro expansion

[Manuel López-Ibáñez]

On 17 October 2012 11:55, Dodji Seketeli do...@redhat.com wrote:
 Hello Manuel,

 Let's CC Gaby on this one as well.

 Manuel López-Ibáñez lopeziba...@gmail.com writes:

 The problem is that the macro unwinder code is changing the original
 diagnostic type and not restoring it, so the code detecting that we
 ICE fails to abort, which triggers another ICE, and so on. But there
 is no point in modifying the original diagnostic, we can simply create
 a temporary copy and use that for macro unwinding.

 We modify the context as well, and we set it back to its original value
 before getting out.  Why not just doing the same for the diagnostic_info
 type? I mean, just save diagnostics-kind before changing it, and set it
 back to the saved value before getting out?  That is less expensive than
 copying all of the diagnostic_info.

Well, the difference is that for context, we are not sure that what we
get at the end of the function is actually the same that we received.
I am not sure if there is some buffer/obstack growth there. For
diagnostic_info it is very different: we want to return exactly the
original. (And in fact, both maybe_unwind_expanded_macro_loc and
diagnostic_build_prefix should take a const * diagnostic_info).

Also, I am not sure why we need to restore the prefix. Once the
warning/error has been printed and we are just attaching notes from
the unwinder, we don't care about the original prefix so we may simply
destroy it. In fact, I think we are *leaking memory* by not destroying
the prefix. Perhaps the prefix should be destroyed always after the
finalizer and the default finalizer should be empty?

Actually, I would propose going even a step further and use a more
high-level api instead of calling into the pretty-printer directly.
Something like: diagnostic_attach_note(context, const *
diagnostic_info, location_t, const char * message, ...) that for
example will check for context-inhibit_notes_p, will make sure the
message is translated, will make sure that diagnostic_info is not
overriden, will print the caret (or not), etc. This will live in
diagnostic.c and could be used by customized diagnostic hooks to
attach notes to an existing diagnostic. It would be a bit less
optimized than the current code, but more re-usable.

What do you think?

It would be good to have Gaby's opinion as well, since what I am
proposing is more far-reaching.

Cheers,

Manuel.

Re: [RFC] Fix spill failure at -O on 64-bit Windows

[Steven Bosscher]

On Wed, Oct 17, 2012 at 11:55 AM, Eric Botcazou wrote:
 Maybe add a cost-free dependency on the clobber, so that it's moved
 with the insn?

 Maybe.  But I'm a little worried about (1) extending the lifetime of the hard
 register and (2) simply moving around a clobber of a hard register.

AFAIU the clobber is there because it was emitted specially for this
particular use of the hard register. So moving it around with the
reason why it's there in the first place would make sense to me.

I don't understand what you mean with extending the life of the hard
register in this case. If you move the clobber with the instruction,
the hard reg is dead before the clobber and after the insn that uses
it, just like when the insn is not hoisted from the loop. So you don't
extend the reg's live range if you move the clobber with it. And if
the register is not dead after the insn, it must be live through the
loop (otherwise it would be only partially available on the loop
entry, coming in from the loop latch) so you don't extend the live
range in that case either.


(One thing I don't fully understand here, though, is why the clobber
doesn't prevent the code motion to begin with. If you don't move the
clobber, that could change the semantics of the program, right? E.g if
you have before LIM something like this:

  while (some_condition) { clobber(ecx); invariant_use (ecx);  ... };
  use (ecx);

and after LIM you have:

  invariant_use (ecx);
  while (some_condition) { clobber(ecx);  ... };
  use (ecx);

that's not the same program anymore if some_condition isn't true...
Not sure if that matters for this kind of uninitialized use.)


 I'd like to keep the change minimal, in particular restricted to uninitialized
 hard registers.  The failure mode is very specific (and might be unique to the
 64-bit ABI on Windows) so I'm not sure it's worth generalizing.

I've got a great dislike for special cases in the GCC code base, they
tend to grow into common practice at alarmingly fast rates :-)
But I suppose your point of view is more pragmatic in this peculiar case.

Ciao!
Steven

Re: [lra] patch to revert a code from previous patch.

[Richard Sandiford]

Vladimir Makarov vmaka...@redhat.com writes:
 On 12-10-16 5:21 PM, Richard Sandiford wrote:
 I realise you probably have patches pending as well, so I'm happy to
 wait until those have gone in and update.

 You can commit it into the branch.  You have to do some work for 
 conflict resolution (I added new helper function in 
 curr_insn_transformation for swapping operands) as the code was changed 
 a lot today.

Thanks.  For the record, here's what I committed after retesting.

Richard


gcc/
* lra-int.h (lra_operand_data): Add is_address field.
* lra.c (debug_operand_data): Initialize is_address field.
(get_static_insn_data): Likewise.
(setup_operand_alternative): Record is_address in operand data.
(lra_set_insn_recog_data): Initialize is_address field.
* lra-constraints.c (curr_operand_mode): New array.
(init_curr_operand_mode): New function.
(find_mode, get_op_mode): Delete.
(match_reload): Use curr_operand_mode rather than get_op_mode.
(process_alt_operands): Likewise.  Remove VOIDmode check from
CONST_OK_POOL_P check.
(swap_operands): Swap the operand modes too.
(curr_insn_transform): Use curr_operand_mode rather than get_op_mode.
Remove VOIDmode check from CONST_OK_POOL_P check.  Use swap_operands
for the final swap too.
(lra_constraints): Call init_curr_operand_mode.

Index: gcc/lra-int.h
===
--- gcc/lra-int.h   2012-10-17 09:04:35.0 +0100
+++ gcc/lra-int.h   2012-10-17 09:05:12.284782971 +0100
@@ -157,6 +157,8 @@ struct lra_operand_data
  This field is set up every time when corresponding
  operand_alternative in lra_static_insn_data is set up.  */
   unsigned int early_clobber : 1;
+  /* True if the operand is an address.  */
+  unsigned int is_address : 1;
 };
 
 /* Info about register in an insn.  */
Index: gcc/lra.c
===
--- gcc/lra.c   2012-10-17 09:04:35.0 +0100
+++ gcc/lra.c   2012-10-17 09:05:12.286782972 +0100
@@ -517,7 +517,7 @@ static struct lra_operand_data debug_ope
 NULL, /* alternative  */
 VOIDmode, /* We are not interesting in the operand mode.  */
 OP_IN,
-0, 0, 0 
+0, 0, 0, 0
   };
 
 /* The following data are used as static insn data for all debug
@@ -618,6 +618,7 @@ get_static_insn_data (int icode, int nop
= (data-operand[i].constraint[0] == '=' ? OP_OUT
   : data-operand[i].constraint[0] == '+' ? OP_INOUT
   : OP_IN);
+ data-operand[i].is_address = false;
}
   for (i = 0; i  ndup; i++)
data-dup_num[i] = recog_data.dup_num[i];
@@ -823,6 +824,7 @@ setup_operand_alternative (lra_insn_reco
  break;
 
case 'p':
+ static_data-operand[i].is_address = true;
  op_alt-is_address = 1;
  op_alt-cl = (reg_class_subunion[(int) op_alt-cl]
[(int) base_reg_class (VOIDmode,
@@ -844,6 +846,7 @@ setup_operand_alternative (lra_insn_reco
}
  if (EXTRA_ADDRESS_CONSTRAINT (c, p))
{
+ static_data-operand[i].is_address = true;
  op_alt-is_address = 1;
  op_alt-cl
= (reg_class_subunion
@@ -1062,6 +1065,7 @@ lra_set_insn_recog_data (rtx insn)
  insn_static_data-operand[i].constraint = constraints[i];
  insn_static_data-operand[i].strict_low = false;
  insn_static_data-operand[i].is_operator = false;
+ insn_static_data-operand[i].is_address = false;
}
}
   for (i = 0; i  insn_static_data-n_operands; i++)
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c   2012-10-17 09:04:35.0 +0100
+++ gcc/lra-constraints.c   2012-10-17 09:14:03.164753401 +0100
@@ -138,11 +138,13 @@
 static int bb_reload_num;
 
 /* The current insn being processed and corresponding its data (basic
-   block, the insn data, and the insn static data.  */
+   block, the insn data, the insn static data, and the mode of each
+   operand).  */
 static rtx curr_insn;
 static basic_block curr_bb;
 static lra_insn_recog_data_t curr_id;
 static struct lra_static_insn_data *curr_static_id;
+static enum machine_mode curr_operand_mode[MAX_RECOG_OPERANDS];
 
 
 
@@ -298,6 +300,27 @@ get_equiv_substitution (rtx x)
   gcc_unreachable ();
 }
 
+/* Set up curr_operand_mode.  */
+static void
+init_curr_operand_mode (void)
+{
+  int nop = curr_static_id-n_operands;
+  for (int i = 0; i  nop; i++)
+{
+  enum machine_mode mode = GET_MODE (*curr_id-operand_loc[i]);
+  if (mode == VOIDmode)
+   {
+ /* The .md mode for address operands is the mode of the
+

Re: [RFA ARM/4.7] Backport Split all insns before pool placement

[Richard Earnshaw]

On 17/10/12 11:55, Matthew Gretton-Dann wrote:

All,

Ulrich posted the following patch in July:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01123.html

Richard E requested that it be left in testing on trunk for a couple of days
before being backported to 4.7.  Three months seems to satisfy the 'couple of
days' requirement :-).

Is this OK to be backported to 4.7?  Cross tested arm-none-linux-gnueabi.

Thanks,

Matt

2012-10-15  Matthew Gretton-Dann  matthew.gretton-d...@linaro.org

Backported from mainline
2012-07-23  Ulrich Weigand  ulrich.weig...@linaro.org

* config/arm/arm.c (arm_reorg): Ensure all insns are split.



OK.

R.



20121017-split-insns-noflow.txt


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 35b73c5..3796a80 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13337,6 +13337,13 @@ arm_reorg (void)
if (TARGET_THUMB2)
  thumb2_reorg ();

+  /* Ensure all insns that must be split have been split at this point.
+ Otherwise, the pool placement code below may compute incorrect
+ insn lengths.  Note that when optimizing, all insns have already
+ been split at this point.  */
+  if (!optimize)
+split_all_insns_noflow ();
+
minipool_fix_head = minipool_fix_tail = NULL;

/* The first insn must always be a note, or the code below won't

[Patch,avr] Tidy up avr_extra_arch_macro

[Georg-Johann Lay]

avr_extra_arch_macro is not really needed, it just holds 
avr_current_device-macro.

Thus, this tiny tidy up.

Ok for trunk?

Johann


* config/avr/avr-arch.h (avr_extra_arch_macro): Remove prototype.
* config/avr/avr.c (avr_extra_arch_macro): Remove variable.
(avr_option_override): Remove setting of avr_extra_arch_macro.
* config/avr/avr-c.c (avr_extra_arch_macro): Replace with
avr_current_device-macro.
Index: config/avr/avr-c.c
===
--- config/avr/avr-c.c	(revision 192459)
+++ config/avr/avr-c.c	(working copy)
@@ -88,8 +88,8 @@ avr_cpu_cpp_builtins (struct cpp_reader
 
   if (avr_current_arch-macro)
 cpp_define_formatted (pfile, __AVR_ARCH__=%s, avr_current_arch-macro);
-  if (avr_extra_arch_macro)
-cpp_define (pfile, avr_extra_arch_macro);
+  if (avr_current_device-macro)
+cpp_define (pfile, avr_current_device-macro);
   if (AVR_HAVE_RAMPD)cpp_define (pfile, __AVR_HAVE_RAMPD__);
   if (AVR_HAVE_RAMPX)cpp_define (pfile, __AVR_HAVE_RAMPX__);
   if (AVR_HAVE_RAMPY)cpp_define (pfile, __AVR_HAVE_RAMPY__);
Index: config/avr/avr-arch.h
===
--- config/avr/avr-arch.h	(revision 192459)
+++ config/avr/avr-arch.h	(working copy)
@@ -149,7 +149,6 @@ struct arch_info_s
 
 /* Preprocessor macros to define depending on MCU type.  */
 
-extern const char *avr_extra_arch_macro;
 extern const struct base_arch_s *avr_current_arch;
 extern const struct mcu_type_s *avr_current_device;
 extern const struct mcu_type_s avr_mcu_types[];
Index: config/avr/avr.c
===
--- config/avr/avr.c	(revision 192459)
+++ config/avr/avr.c	(working copy)
@@ -195,9 +195,6 @@ rtx rampz_rtx;
 static GTY(()) rtx xstring_empty;
 static GTY(()) rtx xstring_e;
 
-/* Preprocessor macros to define depending on MCU type.  */
-const char *avr_extra_arch_macro;
-
 /* Current architecture.  */
 const struct base_arch_s *avr_current_arch;
 
@@ -310,7 +307,6 @@ avr_option_override (void)
 
   avr_current_device = avr_mcu_types[avr_mcu_index];
   avr_current_arch = avr_arch_types[avr_current_device-arch];
-  avr_extra_arch_macro = avr_current_device-macro;
   
   /* RAM addresses of some SFRs common to all Devices in respective Arch. */
 

RE: [PING][Patch, ARM] cleanup prologue_use pattern

[Greta Yorsh]

I am attaching a new version of the patch, addressing Richard's comments.

This patch renames the exiting pattern prologue_use to force_register_use,
because the pattern is used in both prologue and epilogue.

No regression on qemu for arm-none-eabi.

Ok for trunk?

Thanks,
Greta

ChangeLog

gcc/

2012-10-17  Greta Yorsh  greta.yo...@arm.com

* config/arm/arm.md (UNSPEC_PROLOGUE_USE): Rename this...
(UNSPEC_REGISTER_USE): ... to this.
(prologue_use): Rename this...
  (force_register_use): ... to this and update output assembly.
(epilogue) Rename gen_prologue_use to gen_force_register_use.
* config/arm/arm.c (arm_expand_prologue): Likewise.
(thumb1_expand_epilogue): Likewise.
(arm_expand_epilogue): Likewise.
(arm_expand_epilogue): Likewise.




-Original Message-
From: Richard Earnshaw 
Sent: 17 October 2012 11:14
To: Greta Yorsh
Cc: GCC Patches; Ramana Radhakrishnan; ni...@redhat.com;
p...@codesourcery.com
Subject: Re: [PING][Patch, ARM] cleanup prologue_use pattern

On 17/10/12 11:08, Greta Yorsh wrote:
 Ping!


I've been pondering why this was being asked for.  As far as I can tell 
it's just a naming issue (mention of the epilogue in the prologue).

The right thing to do is to rename the pattern to reflect the dual use 
rather than add additional patterns with identical NOP behaviour.  Can't 
you just rename the existing pattern?  Something like force_register_use?

R.

 Thanks,
 Greta

 -Original Message-
 From: Greta Yorsh [mailto:greta.yo...@arm.com]
 Sent: 10 October 2012 16:14
 To: GCC Patches
 Cc: Ramana Radhakrishnan; Richard Earnshaw; ni...@redhat.com;
 p...@codesourcery.com
 Subject: [Patch, ARM] cleanup prologue_use pattern

 The pattern prologue_use is emitted for both prologue and epilogue.
 In particular, the assembly comment
 @sp needed for prologue
 is printed out for both prologue and epilogue.

 This patch adds a separate pattern for epilogue_use and replaces
 prologue_use with epilogue_use where appropriate.

 No regression on qemu for arm-none-eabi.

 Ok for trunk?

 Thanks,
 Greta

 2012-09-17  Greta Yorsh  greta.yo...@arm.com

  * config/arm/arm.md (UNSPEC_EPILOGUE_USE): New unspec value.
  (sibcall_epilogue): Use UNSPEC_EPILOGUE_USE instead of
  UNSPEC_PROLOGUE_USE.
  (epilogue_use): New define_insn.
  (epilogue): Use gen_epilogue_use instead of gen_prologue_use.
  * config/arm/arm.c (arm_expand_epilogue): Likewise.
  (thumb1_expand_epilogue) Likewise.


 rename-prolog-use.v2.patch.txt


 diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
 index dd073da..f23c2d0 100644
 --- a/gcc/config/arm/arm.c
 +++ b/gcc/config/arm/arm.c
 @@ -22581,7 +22581,7 @@ thumb1_expand_epilogue (void)

 /* Emit a USE (stack_pointer_rtx), so that
the stack adjustment will not be deleted.  */
 -  emit_insn (gen_prologue_use (stack_pointer_rtx));
 +  emit_insn (gen_epilogue_use (stack_pointer_rtx));

 if (crtl-profile || !TARGET_SCHED_PROLOG)
   emit_insn (gen_blockage ());
 @@ -22805,7 +22805,7 @@ arm_expand_epilogue (bool really_return)

 /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment
is not
deleted.  */
 -  emit_insn (gen_prologue_use (stack_pointer_rtx));
 +  emit_insn (gen_epilogue_use (stack_pointer_rtx));
   }
 else
   {
 @@ -22823,7 +22823,7 @@ arm_expand_epilogue (bool really_return)
 emit_insn (gen_movsi (stack_pointer_rtx,
hard_frame_pointer_rtx));
 /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment
is not
deleted.  */
 -  emit_insn (gen_prologue_use (stack_pointer_rtx));
 +  emit_insn (gen_epilogue_use (stack_pointer_rtx));
   }
   }
 else
 @@ -22841,7 +22841,7 @@ arm_expand_epilogue (bool really_return)
GEN_INT (amount)));
 /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment
is
not deleted.  */
 -  emit_insn (gen_prologue_use (stack_pointer_rtx));
 +  emit_insn (gen_epilogue_use (stack_pointer_rtx));
   }
   }

 diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
 index a60e659..6a910a3 100644
 --- a/gcc/config/arm/arm.md
 +++ b/gcc/config/arm/arm.md
 @@ -81,6 +81,7 @@
   ; instructions setting registers for EH handling
   ; and stack frame generation.  Operand 0 is the
   ; register to use.
 +  UNSPEC_EPILOGUE_USE   ; Same for epilogue.
 UNSPEC_CHECK_ARCH ; Set CCs to indicate 26-bit or 32-bit mode.
 UNSPEC_WSHUFH ; Used by the intrinsic form of the iWMMXt
WSHUFH instruction.
 UNSPEC_WACC   ; Used by the intrinsic form of the iWMMXt WACC
instruction.
 @@ -10610,7 +10611,7 @@
 TARGET_EITHER
 
 if (crtl-calls_eh_return)
 -emit_insn 

Re: [Patch,avr] Tidy up avr_extra_arch_macro

[Denis Chertykov]

2012/10/17 Georg-Johann Lay a...@gjlay.de:
 avr_extra_arch_macro is not really needed, it just holds 
 avr_current_device-macro.

 Thus, this tiny tidy up.

 Ok for trunk?

 Johann


 * config/avr/avr-arch.h (avr_extra_arch_macro): Remove prototype.
 * config/avr/avr.c (avr_extra_arch_macro): Remove variable.
 (avr_option_override): Remove setting of avr_extra_arch_macro.
 * config/avr/avr-c.c (avr_extra_arch_macro): Replace with
 avr_current_device-macro.

Approved. Please apply.

Denis.

Re: [PING][Patch, ARM] cleanup prologue_use pattern

[Richard Earnshaw]

On 17/10/12 13:37, Greta Yorsh wrote:

I am attaching a new version of the patch, addressing Richard's comments.

This patch renames the exiting pattern prologue_use to force_register_use,
because the pattern is used in both prologue and epilogue.

No regression on qemu for arm-none-eabi.

Ok for trunk?

Thanks,
Greta

ChangeLog

gcc/

2012-10-17  Greta Yorsh  greta.yo...@arm.com

 * config/arm/arm.md (UNSPEC_PROLOGUE_USE): Rename this...
 (UNSPEC_REGISTER_USE): ... to this.
 (prologue_use): Rename this...
  (force_register_use): ... to this and update output assembly.
 (epilogue) Rename gen_prologue_use to gen_force_register_use.
 * config/arm/arm.c (arm_expand_prologue): Likewise.
 (thumb1_expand_epilogue): Likewise.
 (arm_expand_epilogue): Likewise.
 (arm_expand_epilogue): Likewise.





OK.

R.



-Original Message-
From: Richard Earnshaw
Sent: 17 October 2012 11:14
To: Greta Yorsh
Cc: GCC Patches; Ramana Radhakrishnan; ni...@redhat.com;
p...@codesourcery.com
Subject: Re: [PING][Patch, ARM] cleanup prologue_use pattern

On 17/10/12 11:08, Greta Yorsh wrote:

Ping!



I've been pondering why this was being asked for.  As far as I can tell
it's just a naming issue (mention of the epilogue in the prologue).

The right thing to do is to rename the pattern to reflect the dual use
rather than add additional patterns with identical NOP behaviour.  Can't
you just rename the existing pattern?  Something like force_register_use?

R.


Thanks,
Greta

-Original Message-
From: Greta Yorsh [mailto:greta.yo...@arm.com]
Sent: 10 October 2012 16:14
To: GCC Patches
Cc: Ramana Radhakrishnan; Richard Earnshaw; ni...@redhat.com;
p...@codesourcery.com
Subject: [Patch, ARM] cleanup prologue_use pattern

The pattern prologue_use is emitted for both prologue and epilogue.
In particular, the assembly comment
@sp needed for prologue
is printed out for both prologue and epilogue.

This patch adds a separate pattern for epilogue_use and replaces
prologue_use with epilogue_use where appropriate.

No regression on qemu for arm-none-eabi.

Ok for trunk?

Thanks,
Greta

2012-09-17  Greta Yorsh  greta.yo...@arm.com

  * config/arm/arm.md (UNSPEC_EPILOGUE_USE): New unspec value.
  (sibcall_epilogue): Use UNSPEC_EPILOGUE_USE instead of
  UNSPEC_PROLOGUE_USE.
  (epilogue_use): New define_insn.
  (epilogue): Use gen_epilogue_use instead of gen_prologue_use.
  * config/arm/arm.c (arm_expand_epilogue): Likewise.
  (thumb1_expand_epilogue) Likewise.


rename-prolog-use.v2.patch.txt


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index dd073da..f23c2d0 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -22581,7 +22581,7 @@ thumb1_expand_epilogue (void)

 /* Emit a USE (stack_pointer_rtx), so that
the stack adjustment will not be deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));

 if (crtl-profile || !TARGET_SCHED_PROLOG)
   emit_insn (gen_blockage ());
@@ -22805,7 +22805,7 @@ arm_expand_epilogue (bool really_return)

 /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment

is not

deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
   }
 else
   {
@@ -22823,7 +22823,7 @@ arm_expand_epilogue (bool really_return)
 emit_insn (gen_movsi (stack_pointer_rtx,

hard_frame_pointer_rtx));

 /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment

is not

deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
   }
   }
 else
@@ -22841,7 +22841,7 @@ arm_expand_epilogue (bool really_return)
GEN_INT (amount)));
 /* Emit USE(stack_pointer_rtx) to ensure that stack adjustment

is

not deleted.  */
-  emit_insn (gen_prologue_use (stack_pointer_rtx));
+  emit_insn (gen_epilogue_use (stack_pointer_rtx));
   }
   }

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index a60e659..6a910a3 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -81,6 +81,7 @@
   ; instructions setting registers for EH handling
   ; and stack frame generation.  Operand 0 is the
   ; register to use.
+  UNSPEC_EPILOGUE_USE   ; Same for epilogue.
 UNSPEC_CHECK_ARCH ; Set CCs to indicate 26-bit or 32-bit mode.
 UNSPEC_WSHUFH ; Used by the intrinsic form of the iWMMXt

WSHUFH instruction.

 UNSPEC_WACC   ; Used by the intrinsic form of the iWMMXt WACC

instruction.

@@ -10610,7 +10611,7 @@
 TARGET_EITHER
 
 if 

Re: [fortran] add __builtin_unreachable

[Tobias Burnus]

Jan Hubicka wrote:

this patch add __buliltin_unreachable to Fortran FE and also cleans up the code 
a bit

Bootstrapped/regtested x86_64-linux, OK?


The Fortran part looks okay.


* f95-lang.c (gfc_define_builtin): Use set_call_expr_flags.
(ATTR_NOTHROW_LEAF_MALLOC_LIST,
ATTR_CONST_NORETURN_NOTHROW_LEAF_LIST): New lists.
(gfc_init_builtin_functions): Add __builtin_unreachable;
tidy malloc/calloc.

* calls.c (set_call_expr_flags): New.
* tree.h (set_call_expr_flags): Declare.


Tobias

Re: [lra] patch to revert a code from previous patch.

[Bernd Schmidt]

On 10/16/2012 04:30 AM, Vladimir Makarov wrote:
 In insn:
 
 (define_insn_and_split *lea_general_1
   [(set (match_operand 0 register_operand =r)
 (plus (plus (match_operand 1 index_register_operand l)
 (match_operand 2 register_operand r))
   (match_operand 3 immediate_operand i)))]
 
 one operand is (const_int 1).  Its mode is VOIDmode.  recog_data mode is
 VOIDmode.  The patch takes right mode from PLUS containing it.

Shouldn't this use a mode_iterator to put the right mode on the operand?


Bernd

[AARCH64] Fix constraint and attribute for logical immediate instructions

[Sofiane Naci]

Hi,

I've just committed the attached patch on ARM/AArch64 branch.
It fixes a constraint and a scheduling attribute for theoptabmode3
pattern.

Thanks
Sofiane


aarch64-update-logical-imm.patch
Description: Binary data

Re: [RFC] VEC interface overhaul

[Diego Novillo]

On 2012-10-17 06:14 , Richard Biener wrote:


Can't we implement vec_e as vecelement_type, embedded by
means of a partial specialization?


Ah, yes, that's certainly possible and prevents renaming the types in 
the future.



I have not yet implemented the fast vectors from my proposal.
Those would be useful for free variables or structures that can
tolerate an extra word of storage.

Needless to say the patch is gigantic: 2.4 Mb, 334 files
changed, 10718 insertions(+), 11536 deletions(-).  But it is
largely mechanic.

We no longer access the vectors via VEC_* macros.  The pattern is
VEC_operation (T, A, V, args) becomes V.operation (args).
That is mostly why you see ~800 fewer lines in the patch.

The only thing I could not do is create proper ctors and dtors
for the vec_s/vec_e classes.  Since these vectors are stored in
unions, we have to keep them as PODs (C++03 does not allow
non-PODs in unions).

This means that creation and destruction must be explicit.  There
is a new method vec_stype, allocation::create() and another
vec_stype, allocation::destroy() to allocate the internal
vector.


::alloc() and ::free()?  I see you have those, too, but from

   /* Vector allocation.  */
   static vec_sT, A *alloc (unsigned CXX_MEM_STAT_INFO);
   static void free (vec_sT, A *);

   /* Internal vector creation and initialization.  */
   static vec_sT, A create (unsigned CXX_MEM_STAT_INFO);
   static vec_sT, A create (unsigned, vec_eT *);
   void destroy (void);

I can't see how they differ and what users should use?  I suppose
::create and ::destroy are just implementation details?  Thus
you'd make them private?  Why is create not a member function?
It should be IMHO


This is the part I don't like too much.  The problem is that we can't 
use ctors/dtors here.  Both ::alloc() and ::free() allocate a pointer to 
a vec.  So they can't really be member functions.  We don't really have 
any calls to ::alloc/::free now (I added them for completeness), so 
leaving them out for now is certainly possible.


::create is special too not because it needs to allocate a pointer, but 
because it looked odd when used as a regular member function.  Consider:


foo(unsigned n)
{
  vec_stree v = v.create(n);
  ...
}

We are calling ::create on an uninitialized object.  This will work, 
because ::create() allocates the internal vector and reads no state from 
'v'.  It just looked odd.  Ideally, this code would look like:


foo(unsigned n)
{
  vectree v(n);
  ...
}

But we can't have constructors on vec (I'm tempted to add a vector class 
that cannot be put in unions but does provide ctors/dtors).


With the current syntax, we do:

foo(unsigned n)
{
  vectree v = vectree::create(n);
}

This has the problem of being overly verbose (particularly when the 
template arguments are long).  So, if we don't mind the slightly odd 
syntax in the first version, I could just change ::create to be a 
regular member function.




templatetypename T, enum vec_allocation A
inline vec_sT, A
vec_sT, A::create (unsigned nelems, vec_eT *space)
{
   gcc_assert (A == va_stack);
   this-stack_reserve (space, nelems);
   return *this;
}

Otherwise please use gcc_checking_assert in inline functions,
otherwise they won't be inlined due to size constraints in most
of the cases.


Good point.  Thanks.


Likewise ::copy should mimic a copy constructor.  Not sure if
that will work out ... isn't it enough that vec_e is embeddable
into a union?


You want to make ::copy a static function?  Not sure I'm following you here.


Otherwise thanks for working on this and sorry for the C++
bikeshedding - there are just so many more ways to do something
in C++ compared to C ;)


Heh, indeed.  Thanks for the review.


Diego.

[AARCH64-4.7] Fix constraint and attribute for logical immediate instructions

[Sofiane Naci]

Hi,

I've just committed the attached patch on ARM/AArch64-4.7 branch.
It fixes a constraint and a scheduling attribute for theoptabmode3
pattern.

Thanks
Sofiane


aarch64-update-logical-imm.patch
Description: Binary data

Re: [RFC] Fix spill failure at -O on 64-bit Windows

[Eric Botcazou]

 I don't understand what you mean with extending the life of the hard
 register in this case. If you move the clobber with the instruction,
 the hard reg is dead before the clobber and after the insn that uses
 it, just like when the insn is not hoisted from the loop. So you don't
 extend the reg's live range if you move the clobber with it. And if
 the register is not dead after the insn, it must be live through the
 loop (otherwise it would be only partially available on the loop
 entry, coming in from the loop latch) so you don't extend the live
 range in that case either.

In the former case, I agree that you don't really extend the live range.
But you nevertheless extend its span, i.e. you create a live range for the 
hard register out of the loop, while it's supposed to be used only just before 
the call in the argument preparation.  In the latter case, I'm not sure that 
your conclusion holds: why can't it be used in a second insn and die there?

 (One thing I don't fully understand here, though, is why the clobber
 doesn't prevent the code motion to begin with. If you don't move the
 clobber, that could change the semantics of the program, right? E.g if
 you have before LIM something like this:
 
   while (some_condition) { clobber(ecx); invariant_use (ecx);  ... };
   use (ecx);
 
 and after LIM you have:
 
   invariant_use (ecx);
   while (some_condition) { clobber(ecx);  ... };
   use (ecx);
 
 that's not the same program anymore if some_condition isn't true...
 Not sure if that matters for this kind of uninitialized use.)

I agree that moving an uninitialized use (of a hard register) without moving 
the associated clobber is weird.  But I think most RTL passes don't care and 
this probably doesn't affect the correctness of the generated code.

 I've got a great dislike for special cases in the GCC code base, they
 tend to grow into common practice at alarmingly fast rates :-)
 But I suppose your point of view is more pragmatic in this peculiar case.

I'm just realistic: you don't want to make substantial changes in a powerful 
optimization pass just because of a corner case in an exotic language on a 
semi-exotic platform. :-)

-- 
Eric Botcazou

Re: [lra] patch to revert a code from previous patch.

[Richard Sandiford]

Bernd Schmidt ber...@codesourcery.com writes:
 On 10/16/2012 04:30 AM, Vladimir Makarov wrote:
 In insn:
 
 (define_insn_and_split *lea_general_1
   [(set (match_operand 0 register_operand =r)
 (plus (plus (match_operand 1 index_register_operand l)
 (match_operand 2 register_operand r))
   (match_operand 3 immediate_operand i)))]
 
 one operand is (const_int 1).  Its mode is VOIDmode.  recog_data mode is
 VOIDmode.  The patch takes right mode from PLUS containing it.

 Shouldn't this use a mode_iterator to put the right mode on the operand?

That does sound better, and it would be nice to turn the genrecog warning:

/* A modeless MATCH_OPERAND can be handy when we can check for
   multiple modes in the c_test.  In most other cases, it is a
   mistake.  Only DEFINE_INSN is eligible, since SPLIT and
   PEEP2 can FAIL within the output pattern.  Exclude special
   predicates, which check the mode themselves.  Also exclude
   predicates that allow only constants.  Exclude the SET_DEST
   of a call instruction, as that is a common idiom.  */

if (GET_MODE (pattern) == VOIDmode
 code == MATCH_OPERAND
 GET_CODE (insn) == DEFINE_INSN
 pred
 !pred-special
 pred-allows_non_const
 strstr (c_test, operands) == NULL
 ! (set
   GET_CODE (set) == SET
   GET_CODE (SET_SRC (set)) == CALL))
  message_with_line (pattern_lineno,
 warning: operand %d missing mode?,
 XINT (pattern, 0));

into an error to flush all these things out.

I'm not sure it would help LRA or reload much though.  (You might not
have been implying otherwise, sorry.)  We would still want to believe
the mode of the matched operand over the mode of the match_operator for
address operands, and still need to fall back on Pmode for const_int
addresses, so I think the code would basically be the same.

Richard

Re: Propagate profile counts during switch expansion

[Gary Funck]

On 10/08/12 17:46:03, Easwaran Raman wrote:
 I have attached a revised patch. The updated ChangeLog is given below
 and I have responded to your comments inline:
 
 2012-10-08   Easwaran Raman  era...@google.com
 * optabs.c (emit_cmp_and_jump_insn_1): Add a new parameter to
 specificy the probability of taking the jump.

Typo above: specificy
 
 * except.c (sjlj_emit_function_enter): Pass probability to
 emit_cmp_and_jump_insns.

On some targets (e. g., IA64), the following patch leads to an unused
variable warning-as-error:

 Index: except.c
 ===
 --- except.c  (revision 191879)
 +++ except.c  (working copy)
 @@ -1161,13 +1161,7 @@ sjlj_emit_function_enter (rtx dispatch_label)
  
emit_cmp_and_jump_insns (x, const0_rtx, NE, 0,
  TYPE_MODE (integer_type_node), 0,
 -dispatch_label);
 -  last = get_last_insn ();
 -  if (JUMP_P (last)  any_condjump_p (last))
 - {
 -   gcc_assert (!find_reg_note (last, REG_BR_PROB, 0));
 -   add_reg_note (last, REG_BR_PROB, GEN_INT (REG_BR_PROB_BASE / 100));
 - }
 +dispatch_label, REG_BR_PROB_BASE / 100);
  #else
expand_builtin_setjmp_setup (plus_constant (Pmode, XEXP (fc, 0),
 sjlj_fc_jbuf_ofs),


[...] gcc-trunk/src/gcc/except.c:1156:14: error: unused variable ‘last’
[-Werror=unused-variable]
   rtx x, last;
  ^
cc1plus: all warnings being treated as errors

[C++ Patch] PR 54501

[Paolo Carlini]

Hi,

for this kind of code, using the GNU zero-size array extension:

  int a[][0] = {0};

we end up looping forever in the reshape_init_array_1 loop because it 
calls reshape_init_r - reshape_init_array - reshape_init_array_1 which 
returns early a CONSTRUCTOR with no error. Having considered various 
solutions, I'm proposing to break the endless loop in 
reshape_init_array, where we have information about the type of the 
zero-size array and we can easily provide an accurate error message.


Tested x86_64-linux.

Thanks,
Paolo.

//


/cp
2012-10-17  Paolo Carlini  paolo.carl...@oracle.com

PR c++/54501
* decl.c (reshape_init_array): Check for zero-size arrays.

/testsuite
2012-10-17  Paolo Carlini  paolo.carl...@oracle.com

PR c++/54501
* g++.dg/init/array30.C: New.
* g++.dg/init/array0.C: Adjust.
* g++.dg/parse/pr43765.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 192527)
+++ cp/decl.c   (working copy)
@@ -5068,6 +5068,13 @@ reshape_init_array (tree type, reshape_iter *d, ts
   if (TYPE_DOMAIN (type))
 max_index = array_type_nelts (type);
 
+  if (max_index  integer_all_onesp (max_index))
+{
+  if (complain  tf_error)
+   error (initializers provided for zero-size array of type %qT, type);
+  return error_mark_node;
+}
+
   return reshape_init_array_1 (TREE_TYPE (type), max_index, d, complain);
 }
 
Index: testsuite/g++.dg/init/array0.C
===
--- testsuite/g++.dg/init/array0.C  (revision 192527)
+++ testsuite/g++.dg/init/array0.C  (working copy)
@@ -8,5 +8,5 @@ void foo()
 unsigned char dir;
 int data[0];
   } yanito;
-  static const yanito horse = { 1,  { 2,  3 }  }; // { dg-error too many }
+  static const yanito horse = { 1,  { 2,  3 }  }; // { dg-error zero-size }
 }
Index: testsuite/g++.dg/init/array30.C
===
--- testsuite/g++.dg/init/array30.C (revision 0)
+++ testsuite/g++.dg/init/array30.C (working copy)
@@ -0,0 +1,7 @@
+// PR c++/54501
+// { dg-options  }
+
+int main()
+{
+  int a[][0] = {0};  // { dg-error zero-size }
+}
Index: testsuite/g++.dg/parse/pr43765.C
===
--- testsuite/g++.dg/parse/pr43765.C(revision 192527)
+++ testsuite/g++.dg/parse/pr43765.C(working copy)
@@ -11,4 +11,4 @@ SomeType vals[] =
 {
 { values : temp, },
 0
-};  // { dg-error invalid }
+};  // { dg-error zero-size }

Re: [C++ Patch] PR 54501

[Paolo Carlini]

... oh well, I just realized that zero-size VECTORs don't make much 
sense and are early rejected, thus I can improve my earlier patch.


Now I'm happier: essentially I'm only *moving* code around ;)

Thanks,
Paolo.

//
/cp
2012-10-17  Paolo Carlini  paolo.carl...@oracle.com

PR c++/54501
* decl.c (reshape_init_array): Check for zero-size arrays.
(reshape_init_array_1): Don't handle zero-size arrays here.

/testsuite
2012-10-17  Paolo Carlini  paolo.carl...@oracle.com

PR c++/54501
* g++.dg/init/array30.C: New.
* g++.dg/init/array0.C: Adjust.
* g++.dg/parse/pr43765.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 192527)
+++ cp/decl.c   (working copy)
@@ -5022,10 +5022,6 @@ reshape_init_array_1 (tree elt_type, tree max_inde
 
   if (sized_array_p)
 {
-  /* Minus 1 is used for zero sized arrays.  */
-  if (integer_all_onesp (max_index))
-   return new_init;
-
   if (host_integerp (max_index, 1))
max_index_cst = tree_low_cst (max_index, 1);
   /* sizetype is sign extended, not zero extended.  */
@@ -5068,6 +5064,14 @@ reshape_init_array (tree type, reshape_iter *d, ts
   if (TYPE_DOMAIN (type))
 max_index = array_type_nelts (type);
 
+  /* Minus 1 is used for zero sized arrays.  */
+  if (max_index  integer_all_onesp (max_index))
+{
+  if (complain  tf_error)
+   error (initializers provided for zero-size array of type %qT, type);
+  return error_mark_node;
+}
+
   return reshape_init_array_1 (TREE_TYPE (type), max_index, d, complain);
 }
 
Index: testsuite/g++.dg/parse/pr43765.C
===
--- testsuite/g++.dg/parse/pr43765.C(revision 192527)
+++ testsuite/g++.dg/parse/pr43765.C(working copy)
@@ -11,4 +11,4 @@ SomeType vals[] =
 {
 { values : temp, },
 0
-};  // { dg-error invalid }
+};  // { dg-error zero-size }
Index: testsuite/g++.dg/init/array30.C
===
--- testsuite/g++.dg/init/array30.C (revision 0)
+++ testsuite/g++.dg/init/array30.C (working copy)
@@ -0,0 +1,7 @@
+// PR c++/54501
+// { dg-options  }
+
+int main()
+{
+  int a[][0] = {0};  // { dg-error zero-size }
+}
Index: testsuite/g++.dg/init/array0.C
===
--- testsuite/g++.dg/init/array0.C  (revision 192527)
+++ testsuite/g++.dg/init/array0.C  (working copy)
@@ -8,5 +8,5 @@ void foo()
 unsigned char dir;
 int data[0];
   } yanito;
-  static const yanito horse = { 1,  { 2,  3 }  }; // { dg-error too many }
+  static const yanito horse = { 1,  { 2,  3 }  }; // { dg-error zero-size }
 }

PR c/53063 Use (Lang)EnabledBy for a bunch of options

[Manuel López-Ibáñez]

Hi,

This patch changes most trivial cases to use the new  (Lang)EnabledBy.

Bootstrapped and regression tested on x86_64-linux-gnu. OK?

2012-10-17  Manuel López-Ibáñez  m...@gcc.gnu.org

PR c/53063
PR c/40989
c-family/
* c.opt (Waddress,Wchar-subscripts,Wsign-conversion,Wimplicit,
Wimplicit-function-declaration,Wimplicit-int,Wsizeof-pointer-memaccess,
Wnarrowing,Wparentheses,Wpointer-sign,Wreturn-type,Wsequence-point,
Wsign-compare,Wuninitialized,Wmaybe-uninitialized,Wunused,
Wvolatile-register-var): Add LangEnabledBy or EnabledBy.
* c-opts.c (c_common_handle_option): Remove explicit handling from
here.
(c_common_post_options): Likewise.
gcc/
* opts.c (finish_options): Remove explicit handling from here.


Unfortunately, I cannot remove all Init(-1) because the real Init
value is conditional on the language or a more complex condition:

[...]
  if (!c_dialect_cxx ())
{
  /* We set this to 2 here, but 1 in -Wmain, so -ffreestanding
 can turn it off only if it's not explicit.  */
  if (warn_main == -1)
warn_main = (value ? 2 : 0);

  /* In C, -Wall and -Wc++-compat turns on -Wenum-compare,
 which we do here.  In C++ it is on by default, which is
 done in c_common_post_options.  */
  if (warn_enum_compare == -1)
warn_enum_compare = value;
}
[...]
case OPT_Wc___compat:
  /* Because -Wenum-compare is the default in C++, -Wc++-compat
 implies -Wenum-compare.  */
  if (warn_enum_compare == -1  value)
warn_enum_compare = value;
  break;

[...]
   /* -Woverlength-strings is off by default, but is enabled by -Wpedantic.
  It is never enabled in C++, as the minimum limit is not normative
  in that standard.  */
   if (warn_overlength_strings == -1 || c_dialect_cxx ())
 warn_overlength_strings = 0;
  /* Wmain is enabled by default in C++ but not in C.  */
  /* Wmain is disabled by default for -ffreestanding (!flag_hosted),
 even if -Wall was given (warn_main will be 2 if set by -Wall, 1
 if set by -Wmain).  */
  if (warn_main == -1)
warn_main = (c_dialect_cxx ()  flag_hosted) ? 1 : 0;
  else if (warn_main == 2)
warn_main = flag_hosted ? 1 : 0;

  /* -Wimplicit-function-declaration is enabled by default for C99.  */
  if (warn_implicit_function_declaration == -1)
warn_implicit_function_declaration = flag_isoc99;

  if (cxx_dialect = cxx0x)
{
  /* If we're allowing C++0x constructs, don't warn about C++98
 identifiers which are keywords in C++0x.  */
  warn_cxx0x_compat = 0;

  if (warn_narrowing == -1)
warn_narrowing = 1;
}
  else if (warn_narrowing == -1)
warn_narrowing = 0;

Not sure how to encode these dependencies. Ideas?


manyenabledby.diff
Description: Binary data

Re: [asan] Protection of stack vars (take 3)

[Xinliang David Li]

Looks ok to me for the branch.

thanks,

David

On Wed, Oct 17, 2012 at 2:35 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Tue, Oct 16, 2012 at 03:56:31PM -0700, Xinliang David Li wrote:
  1) I am not sure if the stack slot sharing is handled correctly. If I
  read the code correctly, the redzone var will be only created for the
  representative variable in a partition -- will this lead to false
  negatives? As I asked before, should stack slot sharing even turned
  on?
 
  I thought we don't merge stack slots if the vars have different size,
  apparently I've been wrong about that.  So I'll make sure those aren't
  shared with flag_asan.  When the size is the same, there should be no false
  negatives.
 
  2) Performance tuning -- it is probably better to skip those variables
  that are compiler generated -- is there any point guarding them?
 
  In my (admittedly very limited) testing only at -O0 some compiler generated
  vars (SSA_NAMEs) got guards.  The trouble here is -fasan -fstack-protector
  combination.  I wonder if there can be any DECL_ARTIFICIAL (or 
  non-VAR_DECL/
  RESULT_DECL) decls for which stack_protect_decl_phase returns 1 or 2.
  If it is unlikely, the best might be to protect all phase 1 and 2 vars and
  if flag_asan call expand_stack_vars once more for partitions where any of
  the protected vars are user vars, and finally the current expand_stack_vars
  (NULL) which would not do any asan protection.
 

 Do we expect people to use -fasan together with -fstack-protector?  Is
 it enough to just skip those DECL_ARTIFICIAL ones? most of the
 ssa_name var decls are already skipped already.

 Why can't they?  -fstack-protector is for some distros even on by default,
 or others turn it on e.g. in the standard CFLAGS/CXXFLAGS for building
 packages.  And -fstack-protector has a value even with -fasan, e.g. if you
 call some function not instrumented with -fasan (some other library, etc.)
 and pass an address of an automatic array etc. to it.

 Anyway, here is (again, very lightly tested just by skimming assembly on a
 few testcases) an updated patch that won't do stack slot sharing for
 variables with different sizes, and will not put artificial vars/SSA_NAMEs
 into protected stack block, but below it, unless -fstack-protector wants to
 push those high in the frame.  Also, it attempts to find best var name
 for each partition, say if some partition contains both some artificial
 variable, some variable without name and some with name, it will pick the
 non-artificial one with name.

 Ok for asan?

 2012-10-17  Jakub Jelinek  ja...@redhat.com

 * Makefile.in (asan.o): Depend on $(EXPR_H) $(OPTABS_H).
 (cfgexpand.o): Depend on asan.h.
 * asan.c: Include expr.h and optabs.h.
 (asan_shadow_set): New variable.
 (asan_shadow_cst, asan_emit_stack_protection): New functions.
 (asan_init_shadow_ptr_types): Initialize also asan_shadow_set.
 * cfgexpand.c: Include asan.h.  Define HOST_WIDE_INT heap vector.
 (partition_stack_vars): If i is large alignment and j small
 alignment or vice versa, break out of the loop instead of continue,
 and put the test earlier.  If flag_asan, break out of the loop
 if for small alignment size is different.
 (struct stack_vars_data): New type.
 (expand_stack_vars): Add DATA argument.  Change PRED type to
 function taking size_t argument instead of tree.  Adjust pred calls.
 Fill DATA in and add needed padding in between variables if -fasan.
 (defer_stack_allocation): Defer everything for flag_asan.
 (stack_protect_decl_phase_1, stack_protect_decl_phase_2): Take
 size_t index into stack_vars array instead of the decl directly.
 (asan_decl_phase_3): New function.
 (expand_used_vars): Return var destruction sequence.  Adjust
 expand_stack_vars calls, add another one for flag_asan.  Call
 asan_emit_stack_protection if expand_stack_vars added anything
 to the vectors.
 (expand_gimple_basic_block): Add disable_tail_calls argument.
 (gimple_expand_cfg): Pass true to it if expand_used_vars returned
 non-NULL.  Emit the sequence returned by expand_used_vars after
 return_label.
 * asan.h (asan_emit_stack_protection): New prototype.
 (asan_shadow_set): New decl.
 (ASAN_RED_ZONE_SIZE, ASAN_STACK_MAGIC_LEFT, ASAN_STACK_MAGIC_MIDDLE,
 ASAN_STACK_MAGIC_RIGHT, ASAN_STACK_FRAME_MAGIC): Define.
 (asan_protect_stack_decl): New inline.
 * toplev.c (process_options): Also disable -fasan on
 !FRAME_GROWS_DOWNWARDS targets.

 --- gcc/Makefile.in.jj  2012-10-12 23:30:31.635325772 +0200
 +++ gcc/Makefile.in 2012-10-15 09:40:40.287706610 +0200
 @@ -2204,7 +2204,7 @@ stor-layout.o : stor-layout.c $(CONFIG_H
  asan.o : asan.c asan.h $(CONFIG_H) pointer-set.h \
 $(SYSTEM_H) $(TREE_H) $(GIMPLE_H) \
 output.h 

Re: [asan] Protection of globals

[Xinliang David Li]

Yes, I think it is good for the branch.

thanks,

David

On Wed, Oct 17, 2012 at 4:11 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
 On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek ja...@redhat.com wrote:
 Why the above two condition? If the linker picks the larger size one,
 it is ok to do the instrumentation.

 Added more comments, creation of local aliases when needed, and construction
 of global var description strings.
 Again, only very lightly tested.

 __has_dynamic_init is still always 0, setting it to non-zero would require
 dynamic initialization order support, which I'll happily leave to others.

 And the addresses are still absolute (i.e. the global vars descriptor is
 still likely .data.relro.local section for -fpic), both the __beg and
 __name fields, but changing it would require first libasan changes.

 Ok for asan?

 2012-10-17  Jakub Jelinek  ja...@redhat.com

 * varasm.c: Include asan.h.
 (assemble_noswitch_variable): Grow size by asan_red_zone_size
 if decl is asan protected.
 (place_block_symbol): Likewise.
 (assemble_variable): If decl is asan protected, increase
 DECL_ALIGN if needed, and for decls emitted using
 assemble_variable_contents append padding zeros after it.
 * Makefile.in (varasm.o): Depend on asan.h.
 * asan.c: Include output.h.
 (asan_pp, asan_pp_initialized): New variables.
 (asan_pp_initialize, asan_pp_string): New functions.
 (asan_emit_stack_protection): Use asan_pp{,_initialized}
 instead of local pp{,_initialized} vars, use asan_pp_initialize
 and asan_pp_string helpers.
 (asan_needs_local_alias, asan_protect_global,
 asan_global_struct, asan_add_global): New functions.
 (asan_finish_file): Protect global vars that can be protected.
 * asan.h (asan_protect_global): New prototype.
 (asan_red_zone_size): New inline function.

 --- gcc/varasm.c.jj 2012-10-11 19:10:39.0 +0200
 +++ gcc/varasm.c2012-10-16 15:40:37.075662625 +0200
 @@ -51,6 +51,7 @@ along with GCC; see the file COPYING3.
  #include tree-mudflap.h
  #include cgraph.h
  #include pointer-set.h
 +#include asan.h

  #ifdef XCOFF_DEBUGGING_INFO
  #include xcoffout.h  /* Needed for external data
 @@ -1831,6 +1832,9 @@ assemble_noswitch_variable (tree decl, c
size = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
rounded = size;

 +  if (flag_asan  asan_protect_global (decl))
 +size += asan_red_zone_size (size);
 +
/* Don't allocate zero bytes of common,
   since that means undefined external in the linker.  */
if (size == 0)
 @@ -1897,6 +1901,7 @@ assemble_variable (tree decl, int top_le
const char *name;
rtx decl_rtl, symbol;
section *sect;
 +  bool asan_protected = false;

/* This function is supposed to handle VARIABLES.  Ensure we have one.  */
gcc_assert (TREE_CODE (decl) == VAR_DECL);
 @@ -1984,6 +1989,15 @@ assemble_variable (tree decl, int top_le
/* Compute the alignment of this data.  */

align_variable (decl, dont_output_data);
 +
 +  if (flag_asan
 +   asan_protect_global (decl)
 +   DECL_ALIGN (decl)  ASAN_RED_ZONE_SIZE * BITS_PER_UNIT)
 +{
 +  asan_protected = true;
 +  DECL_ALIGN (decl) = ASAN_RED_ZONE_SIZE * BITS_PER_UNIT;
 +}
 +
set_mem_align (decl_rtl, DECL_ALIGN (decl));

if (TREE_PUBLIC (decl))
 @@ -2022,6 +2036,12 @@ assemble_variable (tree decl, int top_le
if (DECL_ALIGN (decl)  BITS_PER_UNIT)
 ASM_OUTPUT_ALIGN (asm_out_file, floor_log2 (DECL_ALIGN_UNIT (decl)));
assemble_variable_contents (decl, name, dont_output_data);
 +  if (asan_protected)
 +   {
 + unsigned HOST_WIDE_INT int size
 +   = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
 + assemble_zeros (asan_red_zone_size (size));
 +   }
  }
  }

 @@ -6926,6 +6946,8 @@ place_block_symbol (rtx symbol)
decl = SYMBOL_REF_DECL (symbol);
alignment = DECL_ALIGN (decl);
size = tree_low_cst (DECL_SIZE_UNIT (decl), 1);
 +  if (flag_asan  asan_protect_global (decl))
 +   size += asan_red_zone_size (size);
  }

/* Calculate the object's offset from the start of the block.  */
 --- gcc/Makefile.in.jj  2012-10-15 09:40:40.0 +0200
 +++ gcc/Makefile.in 2012-10-17 13:00:02.995133686 +0200
 @@ -2712,7 +2712,7 @@ varasm.o : varasm.c $(CONFIG_H) $(SYSTEM
 output.h $(DIAGNOSTIC_CORE_H) xcoffout.h debug.h $(GGC_H) $(TM_P_H) \
 $(HASHTAB_H) $(TARGET_H) langhooks.h gt-varasm.h $(BASIC_BLOCK_H) \
 $(CGRAPH_H) $(TARGET_DEF_H) tree-mudflap.h \
 -   pointer-set.h $(COMMON_TARGET_H)
 +   pointer-set.h $(COMMON_TARGET_H) asan.h
  function.o : function.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
 $(RTL_ERROR_H) \
 $(TREE_H) $(GIMPLE_H) $(FLAGS_H) $(FUNCTION_H) $(EXPR_H) \
 $(OPTABS_H) $(LIBFUNCS_H) $(REGS_H) 

Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2f

[David Edelsohn]

Mike,

This patch is okay with the appropriate changes to adapt to the common
infrastructure improvements.

We will continue to iterate on this.

Are there any testcases that would be useful? A lot of other testcases
use target flags, so those probably will point out problems.

Thanks, David

On Tue, Oct 16, 2012 at 11:56 AM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
 While Joseph and I are iterating on global changes to the options machinery,
 David had said patch #2b was ok for just powerpc specific changes.  I took
 patch #2b, and adjusted it for the 3 patches I already checked in.  I rewrote
 the ChangeLog entries to try and be more explicit in what was going on.  This
 bootstraped and had no regressions.  Is this ok to check in?

 2012-10-16  Michael Meissner  meiss...@linux.vnet.ibm.com

 * config/rs6000/rs6000.opt (rs6000_isa_flags): New flag word to
 replace target_flags that gives us 63 possible switches.
 (x_rs6000_isa_flags): Save area for rs6000_isa_flags.
 (x_rs6000_isa_flags_explicit): Save area for
 rs6000_isa_flags_explicit.
 (rs6000_target_flags_explicit): Delete in favor of
 x_rs6000_isa_flags_explicit.
 (-mpowerpc64): Change all switches that used to be in target_flags
 to now be in rs6000_isa_flags.  In using rs6000_isa_flags, the
 options machinary will generate names of the form OPITON_xxx
 instead of TARGET_xxx and OPTION_MASK_xxx instead of
 MASK_xxx.
 (-mpowerpc-gpopt): Likewise.
 (-mpowerpc-gfxopt): Likewise.
 (-mmfcrf): Likewise.
 (-mpopcntb): Likewise.
 (-mfprnd): Likewise.
 (-mcmpb): Likewise.
 (-mmfpgpr): Likewise.
 (-maltivec): Likewise.
 (-mhard-dfp): Likewise.
 (-mmulhw): Likewise.
 (-mdlmzb): Likewise.
 (-mmultiple): Likewise.
 (-mstring): Likewise.
 (-msoft-float): Likewise.
 (-mhard-float): Likewise.
 (-mpopcntd): Likewise.
 (-mvsx): Likewise.
 (-mno-update): Likewise.
 (-mupdate): Likewise.
 (-mrecip-precision): Likewise.
 (-mminimal-toc): Likewise.
 (-misel): Likewise.
 * config/rs6000/aix64.opt (-maix64): Likewise.
 (-maix32): Likewise.
 * config/rs6000/sysv4.opt (-mstrict-align): Likewise.
 (-mrelocatable): Likewise.
 (-mlittle-endian): Likewise.
 (-mlittle): Likewise.
 (-mbig-endian): LIkewise.
 (-mbig): Likewise.
 (-meabi): Likewise.
 (-m64): Likewise.
 (-m32): Likewise.
 * config/rs6000/darwin.opt (-m64): Likewise.
 (-m32): Likewise.

 * config/rs6000/rs6000-cpus.def (ISA_2_1_MASKS): Move the various
 masks used in rs6000.c here, since they are more logically in this
 file.  Convert from being enums to just #defines, since the types
 of these masks is now HOST_WIDE_INT instead of int.  For
 POWERPC_MASKS, add MASK_SOFT_FLOAT, since the only use case or'ed
 in the mask.  Change the use in rs6000.c not to do the OR of
 MASK_SOFT_FLOAT.
 (ISA_2_1_MASKS): Likewise.
 (ISA_2_2_MASKS): Likewise.
 (ISA_2_4_MASKS): Likewise.
 (ISA_2_5_MASKS_EMBEDDED): Likewise.
 (ISA_2_5_MASKS_SERVER): Likewise.
 (POWERPC_7400_MASK): Likewise.
 (POWERPC_MASKS): Likewise.
 * config/rs6000/rs6000.c (ISA_2_1_MASKS): Likewise.
 (ISA_2_1_MASKS): Likewise.
 (ISA_2_2_MASKS): Likewise.
 (ISA_2_4_MASKS): Likewise.
 (ISA_2_5_MASKS_EMBEDDED): Likewise.
 (ISA_2_5_MASKS_SERVER): Likewise.
 (POWERPC_7400_MASK): Likewise.
 (POWERPC_MASKS): Likewise.
 (rs6000_option_override_internal): Likewise.

 * config/rs6000/rs6000.c (darwin_rs6000_override_options): Change
 all uses of target_flags to rs6000_isa_flags.  Change all uses of
 target_flags_explicit to rs6000_isa_flags_explicit.  Change the
 use of MASK_xxx to OPTION_MASK_xxx that options.h defines when
 we use a secondary flags word.  Save/restore/print the new flags
 word when switching contexts with different target attributes.
 (rs6000_option_override_internal): Likewise.
 (rs6000_darwin_file_start): Likewise.
 (rs6000_opt_masks): Likewise.
 (rs6000_inner_target_options): Likewise.
 (rs6000_pragma_target_parse): Likewise.
 (rs6000_set_current_function): Likewise.
 (rs6000_function_specific_save): Likewise.
 (rs6000_function_specific_restore): Likewise.
 (rs6000_function_specific_print): Likewise.
 (rs6000_can_inline_p): Likewise.
 * config/rs6000/rs6000-c.c (rs6000_target_modify_macros):
 Likewise.
 (rs6000_cpu_cpp_builtins): Likewise.
 * common/config/rs6000/rs6000-driver.c (rs6000_handle_option):
 Likewise.

 * 

Re: [PATCH][google] Add warning flags for clang compatibility

[Delesley Hutchins]

google/integration: r192542.

On Tue, Oct 16, 2012 at 1:00 PM, Delesley Hutchins deles...@google.com wrote:
 Committed.
 google/gcc-4_6: r192510.
 google/gcc-4_7: r192511.
 google/main: r192513.

 On Tue, Oct 16, 2012 at 12:44 PM, Delesley Hutchins deles...@google.com 
 wrote:
 Yes, but that won't happen for a while yet.

 On Tue, Oct 16, 2012 at 12:43 PM, Diego Novillo dnovi...@google.com wrote:
 On Tue, Oct 16, 2012 at 3:19 PM, Delesley Hutchins deles...@google.com 
 wrote:
 This patch adds the clang thread safety warning flags as recognized
 warning flags that do nothing, for command-line compatibility with
 clang.  Enclosed patch is for branches/google/gcc-4_6, I have
 identical patches for google/gcc-4_7 and google/main.

 OK for all google/ branches.  You still need to remove the old thread
 safety code, right?


 Diego.



 --
 DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315



 --
 DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315



-- 
DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315

Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #4

[Michael Meissner]

On Wed, Oct 17, 2012 at 12:26:42AM +, Joseph S. Myers wrote:
 On Tue, 16 Oct 2012, Michael Meissner wrote:
 
  It occurs to me that now that we've committed to GCC being done in C++, we
  could just make global_options{,_set} be a class instead of a structure.  So
  you could say:
  
  global_options.set_FOO (value)
  
  Or:
  
  global_options.set_FOO ();
  global_options.clear_FOO ();
  
  I could generate the macros (or inline functions) if you would prefer to 
  stick
  the C style of doing things.  However, as an old C dinosaur, I'm not sure of
  all of the ramifications of doing this.  It just seems it would be cleaner 
  to
  use the class structure, instead of passing pointers.
 
 In general, as much as possible should use an instance of struct 
 gcc_options that is passed explicitly to the relevant code (or associated 
 with the function being compiled, etc.), rather than using global_options 
 directly (explicitly or implicitly).
 
 The existing way of doing that is using a pointer to a gcc_options 
 structure.  With a class I'd think you'd still need to pass it around as 
 either a pointer or a reference (even if you then use member functions for 
 some operations on these structures), and I'm not aware of any particular 
 advantage of using a reference.  I do not think most functions that happen 
 to take a gcc_options pointer (often along with lots of other pointers to 
 other pieces of state) are particularly suited to being member functions 
 of gcc_options.
 
 Given that existing practice is passing pointers around, I'd think that's 
 appropriate for any new such functions / macros, unless and until we have 
 some clear notion of when functionality should or should not be a member 
 function of gcc_options.

In thinking about it this morning, I don't think we need the options machinery
to generate new functions.  We can just use the set_option function in
opts-common.c to set those options.  I likely will add a convenience function
in rs6000.c to default most of the arguments for this.

-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899

Re: RFC: LRA for x86/x86-64 [7/9] -- continuation

[Vladimir Makarov]

On 12-10-15 12:49 PM, Richard Sandiford wrote:

Hi Vlad,

Some comments about the rest of LRA.  Nothing major here...

Vladimir Makarov vmaka...@redhat.com writes:

+/* Info about register in an insn.  */
+struct lra_insn_reg
+{
+  /* The biggest mode through which the insn refers to the register
+ (remember the register can be accessed through a subreg in the
+ insn).  */
+  ENUM_BITFIELD(machine_mode) biggest_mode : 16;

AFAICT, this is actually always the mode of a specific reference,
and if there are references to the same register in different modes,
those references get their own lra_insn_regs.  mode might be better
than biggest_mode if so.

I seems mode is also not good.  I've just modified the comment to 
reflect the fact that is just a reference.

+/* Static part (common info for insns with the same ICODE) of LRA
+   internal insn info. It exists in at most one exemplar for each
+   non-negative ICODE. Warning: if the structure definition is
+   changed, the initializer for debug_insn_static_data in lra.c should
+   be changed too.  */

Probably worth saying (before the warning) that there is also
one structure for each asm.

Good point.  I added a comment.

+/* LRA internal info about an insn (LRA internal insn
+   representation).  */
+struct lra_insn_recog_data
+{
+  int icode; /* The insn code. */
+  rtx insn; /* The insn itself. */
+  /* Common data for insns with the same ICODE. */
+  struct lra_static_insn_data *insn_static_data;

Maybe worth mentioning asms here too.

Fixed.

+  /* Two arrays of size correspondingly equal to the operand and the
+ duplication numbers: */
+  rtx **operand_loc; /* The operand locations, NULL if no operands.  */
+  rtx **dup_loc; /* The dup locations, NULL if no dups. */
+  /* Number of hard registers implicitly used in given call insn.  The
+ value can be NULL or points to array of the hard register numbers
+ ending with a negative value.  */
+  int *arg_hard_regs;
+#ifdef HAVE_ATTR_enabled
+  /* Alternative enabled for the insn. NULL for debug insns.  */
+  bool *alternative_enabled_p;
+#endif
+  /* The alternative should be used for the insn, -1 if invalid, or we
+ should try to use any alternative, or the insn is a debug
+ insn.  */
+  int used_insn_alternative;
+  struct lra_insn_reg *regs;  /* Always NULL for a debug insn. */

Comments consistently above the field.

Fixed.

+extern void lra_expand_reg_info (void);

This doesn't exist any more.

Fixed.

+extern int lra_constraint_new_insn_uid_start;

Just saying in case: this seems to be write-only, with lra-constraints.c
instead using a static variable to track the uid start.

I realise you might want to keep it anyway for consistency with
lra_constraint_new_regno_start, or for debugging.


+extern rtx lra_secondary_memory[NUM_MACHINE_MODES];

This doesn't exist any more.

Removed.  Thanks.

+/* lra-saves.c: */
+
+extern bool lra_save_restore (void);

Same for this file  function.

Removed.

+/* The function returns TRUE if at least one hard register from ones
+   starting with HARD_REGNO and containing value of MODE are in set
+   HARD_REGSET. */
+static inline bool
+lra_hard_reg_set_intersection_p (int hard_regno, enum machine_mode mode,
+HARD_REG_SET hard_regset)
+{
+  int i;
+
+  lra_assert (hard_regno = 0);
+  for (i = hard_regno_nregs[hard_regno][mode] - 1; i = 0; i--)
+if (TEST_HARD_REG_BIT (hard_regset, hard_regno + i))
+  return true;
+  return false;
+}

This is the same as overlaps_hard_reg_set_p.


I removed it and started to use the function overlaps_hard_reg_set_p.

+/* Return hard regno and offset of (sub-)register X through arguments
+   HARD_REGNO and OFFSET.  If it is not (sub-)register or the hard
+   register is unknown, then return -1 and 0 correspondingly.  */

The function seems to return -1 for both.
Fixed.  It does not matter for the rest of code as offset is used only 
when hard_regno = 0.

+/* Add hard registers starting with HARD_REGNO and holding value of
+   MODE to the set S.  */
+static inline void
+lra_add_hard_reg_set (int hard_regno, enum machine_mode mode, HARD_REG_SET *s)
+{
+  int i;
+
+  for (i = hard_regno_nregs[hard_regno][mode] - 1; i = 0; i--)
+SET_HARD_REG_BIT (*s, hard_regno + i);
+}

This is add_to_hard_reg_set.

Removed.

+   Here is block diagram of LRA passes:
+
+ - 
+| Undo inheritance|  ------
+| for spilled pseudos)| | Memory-memory |  | New (and old) |
+| and splits (for || move coalesce |-|  pseudos|
+| pseudos got the |  ---   |   assignment  |
+  Start |  same  hard regs)   | 
---
+|- ^
+V|     |
+ 

[C++] Handle ?: for vectors

[Marc Glisse]

Hello,

this patch adds support for vector conditions to the C++ front-end. Note 
that the testcase currently only applies to x86. This is because there is 
work remaining in the middle-end for the case where vector selection for 
this vector mode is not provided by the target. There are also many 
middle-end bugs, so the testcase will crash with -O. I believe it makes 
sense to introduce front-end support early, because this way I'll be able 
to add testcases when I fix middle-end issues. Not documenting until this 
is actually usable.


gcc/
* tree.c (signed_or_unsigned_type_for): Handle vectors.

gcc/cp/
* typeck.c (build_x_conditional_expr): Handle VEC_COND_EXPR.
* call.c (build_conditional_expr_1): Likewise.

gcc/c-family/
* c-common.c (scalar_to_vector): Handle VEC_COND_EXPR.

gcc/testsuite/
* g++.dg/ext/vector19.C: New testcase.


--
Marc GlisseIndex: tree.c
===
--- tree.c  (revision 192542)
+++ tree.c  (working copy)
@@ -10229,20 +10229,31 @@ widest_int_cst_value (const_tree x)
 /* If TYPE is an integral or pointer type, return an integer type with
the same precision which is unsigned iff UNSIGNEDP is true, or itself
if TYPE is already an integer type of signedness UNSIGNEDP.  */
 
 tree
 signed_or_unsigned_type_for (int unsignedp, tree type)
 {
   if (TREE_CODE (type) == INTEGER_TYPE  TYPE_UNSIGNED (type) == unsignedp)
 return type;
 
+  if (TREE_CODE (type) == VECTOR_TYPE)
+{
+  tree inner = TREE_TYPE (type);
+  tree inner2 = signed_or_unsigned_type_for (unsignedp, inner);
+  if (!inner2)
+   return NULL_TREE;
+  if (inner == inner2)
+   return type;
+  return build_vector_type (inner2, TYPE_VECTOR_SUBPARTS (type));
+}
+
   if (!INTEGRAL_TYPE_P (type)
!POINTER_TYPE_P (type))
 return NULL_TREE;
 
   return build_nonstandard_integer_type (TYPE_PRECISION (type), unsignedp);
 }
 
 /* If TYPE is an integral or pointer type, return an integer type with
the same precision which is unsigned, or itself if TYPE is already an
unsigned integer type.  */
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 192542)
+++ c-family/c-common.c (working copy)
@@ -11467,20 +11467,22 @@ scalar_to_vector (location_t loc, enum t
  return stv_firstarg;
  }
break;
 
   case BIT_IOR_EXPR:
   case BIT_XOR_EXPR:
   case BIT_AND_EXPR:
integer_only_op = true;
/* ... fall through ...  */
 
+  case VEC_COND_EXPR:
+
   case PLUS_EXPR:
   case MINUS_EXPR:
   case MULT_EXPR:
   case TRUNC_DIV_EXPR:
   case CEIL_DIV_EXPR:
   case FLOOR_DIV_EXPR:
   case ROUND_DIV_EXPR:
   case EXACT_DIV_EXPR:
   case TRUNC_MOD_EXPR:
   case FLOOR_MOD_EXPR:
Index: cp/call.c
===
--- cp/call.c   (revision 192542)
+++ cp/call.c   (working copy)
@@ -4366,43 +4366,120 @@ build_conditional_expr_1 (tree arg1, tre
pedwarn (input_location, OPT_Wpedantic, 
 ISO C++ forbids omitting the middle term of a ?: expression);
 
   /* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C.  */
   if (real_lvalue_p (arg1))
arg2 = arg1 = stabilize_reference (arg1);
   else
arg2 = arg1 = save_expr (arg1);
 }
 
+  /* If something has already gone wrong, just pass that fact up the
+ tree.  */
+  if (error_operand_p (arg1)
+  || error_operand_p (arg2)
+  || error_operand_p (arg3))
+return error_mark_node;
+
+  orig_arg2 = arg2;
+  orig_arg3 = arg3;
+
+  if (VECTOR_INTEGER_TYPE_P (TREE_TYPE (arg1)))
+{
+  arg1 = force_rvalue (arg1, complain);
+  arg2 = force_rvalue (arg2, complain);
+  arg3 = force_rvalue (arg3, complain);
+
+  tree arg1_type = TREE_TYPE (arg1);
+  arg2_type = TREE_TYPE (arg2);
+  arg3_type = TREE_TYPE (arg3);
+
+  if (TREE_CODE (arg2_type) != VECTOR_TYPE
+  TREE_CODE (arg3_type) != VECTOR_TYPE)
+   {
+ if (complain  tf_error)
+   error (at least one operand of a vector conditional operator 
+  must be a vector);
+ return error_mark_node;
+   }
+
+  if ((TREE_CODE (arg2_type) == VECTOR_TYPE)
+ != (TREE_CODE (arg3_type) == VECTOR_TYPE))
+   {
+ enum stv_conv convert_flag =
+   scalar_to_vector (input_location, VEC_COND_EXPR, arg2, arg3,
+ complain  tf_error);
+
+ switch (convert_flag)
+   {
+ case stv_error:
+   return error_mark_node;
+ case stv_firstarg:
+   {
+ arg2 = convert (TREE_TYPE (arg3_type), arg2);
+ arg2 = build_vector_from_val (arg3_type, arg2);
+ arg2_type = TREE_TYPE (arg2);
+ break;

[PATCH] partial fix for PR target/54404

[Jack Howarth]

   The attached patch eliminates the failures in 
g++.dg/other/darwin-cfstring1.C 
and obj-c++.dg/strings/const-cfstring-2.mm by adding -ftrack-macro-expansion=0 
to dg-options which partially eliminates the remaining failures in PR 
target/54404.
These changes eliminate the failures...

FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98  (test for errors, line 21)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98  (test for errors, line 22)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11  (test for errors, line 21)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11  (test for errors, line 22)
FAIL: g++.dg/other/darwin-cfstring1.C -std=gnu++11 (test for excess errors)
FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for 
warnings, line 22)
FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for 
warnings, line 23)
FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for 
warnings, line 25)
FAIL: obj-c++.dg/strings/const-cfstring-2.mm -fnext-runtime  (test for 
warnings, line 26)

at -m32/-m64 on darwin. Tested on x86_64-apple-darwin12, x86_64-apple-darwin10 
and powerpc-apple-darwin9.
Okay for gcc trunk?
Jack


gcc/testsuite/

2012-10-17  Dominique Dhumieres  domi...@lps.ens.fr
Jack Howarth howa...@bromo.med.uc.edu

PR target/54404
* g++.dg/other/darwin-cfstring1.C: Add -ftrack-macro-expansion=0 to 
dg-options.
* obj-c++.dg/strings/const-cfstring-2.mm: Likewise.

Index: gcc/testsuite/g++.dg/other/darwin-cfstring1.C
===
--- gcc/testsuite/g++.dg/other/darwin-cfstring1.C   (revision 192531)
+++ gcc/testsuite/g++.dg/other/darwin-cfstring1.C   (working copy)
@@ -4,7 +4,7 @@
 /* Developed by Ziemowit Laski zla...@apple.com.  */
 
 /* { dg-do compile { target *-*-darwin* } } */
-/* { dg-options -mconstant-cfstrings } */
+/* { dg-options -ftrack-macro-expansion=0 -mconstant-cfstrings } */
 
 #include CoreFoundation/CFString.h
 
Index: gcc/testsuite/obj-c++.dg/strings/const-cfstring-2.mm
===
--- gcc/testsuite/obj-c++.dg/strings/const-cfstring-2.mm(revision 
192531)
+++ gcc/testsuite/obj-c++.dg/strings/const-cfstring-2.mm(working copy)
@@ -6,7 +6,7 @@
 /* So far, CFString is darwin-only.  */
 /* { dg-do compile { target *-*-darwin* } } */
 /* { dg-skip-if NeXT only { *-*-* } { -fgnu-runtime } {  } } */
-/* { dg-options -mconstant-cfstrings -Wnonportable-cfstrings } */
+/* { dg-options -ftrack-macro-expansion=0 -mconstant-cfstrings 
-Wnonportable-cfstrings } */
 
 #import Foundation/NSString.h
 #import CoreFoundation/CFString.h

Re: RFC: LRA for x86/x86-64 [7/9] -- continuation

[Steven Bosscher]

On Wed, Oct 17, 2012 at 9:53 PM, Vladimir Makarov wrote:
 On 12-10-15 12:49 PM, Richard Sandiford wrote:
 Getting rid of reload always seemed like a pipe dream, and if the only
 known drawback of this replacement is that it takes a while on extreme
 testcases, that's an amazing achievement.  (Not to say compile time
 isn't important, just that there were so many other hurdles to overcome.)

Just to be clear, LRA now does no worse from a compile time POV than,
say, tree-ssa-live. Most of the scalability problems have been
addressed.

 It is my second attempt.  The first one was YARA project.  I got a lot of
 experience from this project and knowledge how not to do this.
 LRA will be still a long lasting project.  I don't think I found all
 weirdness of reload just trying 8 targets (fixing one bug on one target
 frequently resulted in new bugs on other targets so it required to do
 frequently cardinal changes to the original code). Only after trying the 8
 targets I got feeling that this approach could well.

Hats off to you, Vlad, for your years of effort on improving GCC's RA!

Ciao!
Steven

Re: Tidy store_bit_field_1 co.

[Eric Botcazou]

 The patch is probably quite hard to review, sorry.  I've made the changelog
 a bit more detailed than usual in order to list the individual points.

You meant scary, didn't you? :-)

   * expmed.c (store_bit_field_1): Remove unit, offset, bitpos and
   byte_offset from the outermost scope.  Express conditions in terms
   of bitnum rather than offset, bitpos and byte_offset.  Split the
   plain move cases into two, one for memory accesses and one for
   register accesses.  Allow simplify_gen_subreg to fail rather
   than calling validate_subreg.  Move the handling of multiword
   OP0s after the code that coerces VALUE to an integer mode.
   Use simplify_gen_subreg for this case and assert that it succeeds.
   If the field still spans several words, pass it directly to
   store_split_bit_field.  Assume after that point that both sources
   and register targets fit within a word.  Replace x-prefixed
   variables with non-prefixed forms.  Compute the bitpos for insv
   register operands directly in the chosen unit size, rather than
   going through an intermediate BITS_PER_WORD unit size.
   Update the call to store_fixed_bit_field.
   (store_fixed_bit_field): Replace the bitpos and offset parameters
   with a single bitnum parameter, of the same form as store_bit_field.
   Assume that OP0 contains the full field.  Simplify the memory offset
   calculation.  Assert that the processed OP0 has an integral mode.
   (store_split_bit_field): Update the call to store_fixed_bit_field.

I agree that splitting the memory and register cases is a good idea, as well 
as unifying the interface.  A few remarks:

 -476,34 +468,36 @@ store_bit_field_1 (rtx str_rtx, unsigne
  }
 
/* If the target is a register, overwriting the entire object, or storing
 - a full-word or multi-word field can be done with just a SUBREG. +
 a full-word or multi-word field can be done with just a SUBREG.  */ +  if
 (!MEM_P (op0)
 +   bitsize == GET_MODE_BITSIZE (fieldmode)
 +   ((bitsize % BITS_PER_WORD == 0
 + bitnum % BITS_PER_WORD == 0)
 +   || (bitsize == GET_MODE_BITSIZE (GET_MODE (op0))
 +bitnum == 0)))
 +{
 +  /* Use the subreg machinery either to narrow OP0 to the required
 +  words or to cope with mode punning between equal-sized modes.  */
 +  rtx sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0),
 +  bitnum / BITS_PER_UNIT);
 +  if (sub)
 + {
 +   emit_move_insn (sub, value);
 +   return true;
 + }
 +}

I'd use the following variant for the sake of symmetry with the MEM_P case:

  if (!MEM_P (op0)
   bitnum % BITS_PER_WORD == 0
   bitsize == GET_MODE_BITSIZE (fieldmode)
   [...]

 -  /* If OP0 is a register, BITPOS must count within a word.
 - But as we have it, it counts within whatever size OP0 now has.
 - On a bigendian machine, these are not the same, so convert.  */
 -  if (BYTES_BIG_ENDIAN
 -   !MEM_P (op0)
 -   unit  GET_MODE_BITSIZE (GET_MODE (op0)))
 -bitpos += unit - GET_MODE_BITSIZE (GET_MODE (op0));
 -
/* Storing an lsb-aligned field in a register
 - can be done with a movestrict instruction.  */
 + can be done with a movstrict instruction.  */
 
if (!MEM_P (op0)
 -   (BYTES_BIG_ENDIAN ? bitpos + bitsize == unit : bitpos == 0)
 +   (BYTES_BIG_ENDIAN
 +   ? bitnum + bitsize == GET_MODE_BITSIZE (GET_MODE (op0))
 +   : bitnum == 0)
 bitsize == GET_MODE_BITSIZE (fieldmode)
 optab_handler (movstrict_optab, fieldmode) != CODE_FOR_nothing)
  {
 @@ -558,8 +546,7 @@ store_bit_field_1 (rtx str_rtx, unsigned
 arg0 = SUBREG_REG (arg0);
   }
 
 -  subreg_off = (bitnum % BITS_PER_WORD) / BITS_PER_UNIT
 -+ (offset * UNITS_PER_WORD);
 +  subreg_off = bitnum / BITS_PER_UNIT;
if (validate_subreg (fieldmode, GET_MODE (arg0), arg0, subreg_off))
   {
 arg0 = gen_rtx_SUBREG (fieldmode, arg0, subreg_off);

Aren't you losing movstrict opportunities in big-endian mode?  If GET_MODE 
(op0) is 2 words and bitnum + bitsize == BITS_PER_WORD.

 @@ -638,34 +625,6 @@ store_bit_field_1 (rtx str_rtx, unsigned
return true;
  }
 
 -  /* From here on we can assume that the field to be stored in is
 - a full-word (whatever type that is), since it is shorter than a word. 
 */ -
 -  /* OFFSET is the number of words or bytes (UNIT says which)
 - from STR_RTX to the first word or byte containing part of the field. 
 */ -
 -  if (!MEM_P (op0))
 -{
 -  if (offset != 0
 -   || GET_MODE_SIZE (GET_MODE (op0))  UNITS_PER_WORD)
 - {
 -   if (!REG_P (op0))
 - {
 -   /* Since this is a destination (lvalue), we can't copy
 -  it to a pseudo.  We can remove a SUBREG that does not
 -  change the size of the operand.  Such a SUBREG may
 -  have 

Fix bugs introduced by switch-case profile propagation

[Easwaran Raman]

Hi,
 This patch fixes bugs introduced by my previous patch to propagate
profiles during switch expansion. Bootstrap and profiledbootstrap
successful on x86_64. Confirmed that it fixes the crashes reported in
PR middle-end/54957. OK for trunk?

- Easwaran

2012-10-17   Easwaran Raman  era...@google.com

PR target/54938
PR middle-end/54957
* optabs.c (emit_cmp_and_jump_insn_1): Add REG_BR_PROB note
only if it doesn't already exist.
* except.c (sjlj_emit_function_enter): Remove unused variable.
* stmt.c (get_outgoing_edge_probs): Return 0 if BB is NULL.
(emit_case_dispatch_table): Handle the case where STMT_BB is
NULL.
(expand_sjlj_dispatch_table): Pass BB containing before_case
to emit_case_dispatch_table.

Index: gcc/optabs.c
===
--- gcc/optabs.c (revision 192488)
+++ gcc/optabs.c (working copy)
@@ -4268,11 +4268,9 @@ emit_cmp_and_jump_insn_1 (rtx test, enum machine_m
profile_status != PROFILE_ABSENT
insn
JUMP_P (insn)
-   any_condjump_p (insn))
-{
-  gcc_assert (!find_reg_note (insn, REG_BR_PROB, 0));
-  add_reg_note (insn, REG_BR_PROB, GEN_INT (prob));
-}
+   any_condjump_p (insn)
+   !find_reg_note (insn, REG_BR_PROB, 0))
+add_reg_note (insn, REG_BR_PROB, GEN_INT (prob));
 }

 /* Generate code to compare X with Y so that the condition codes are
Index: gcc/except.c
===
--- gcc/except.c (revision 192488)
+++ gcc/except.c (working copy)
@@ -1153,7 +1153,7 @@ sjlj_emit_function_enter (rtx dispatch_label)
   if (dispatch_label)
 {
 #ifdef DONT_USE_BUILTIN_SETJMP
-  rtx x, last;
+  rtx x;
   x = emit_library_call_value (setjmp_libfunc, NULL_RTX, LCT_RETURNS_TWICE,
TYPE_MODE (integer_type_node), 1,
plus_constant (Pmode, XEXP (fc, 0),
Index: gcc/stmt.c
===
--- gcc/stmt.c (revision 192488)
+++ gcc/stmt.c (working copy)
@@ -1867,6 +1867,8 @@ get_outgoing_edge_probs (basic_block bb)
   edge e;
   edge_iterator ei;
   int prob_sum = 0;
+  if (!bb)
+return 0;
   FOR_EACH_EDGE(e, ei, bb-succs)
 prob_sum += e-probability;
   return prob_sum;
@@ -1916,8 +1918,8 @@ emit_case_dispatch_table (tree index_expr, tree in
   rtx fallback_label = label_rtx (case_list-code_label);
   rtx table_label = gen_label_rtx ();
   bool has_gaps = false;
-  edge default_edge = EDGE_SUCC(stmt_bb, 0);
-  int default_prob = default_edge-probability;
+  edge default_edge = stmt_bb ? EDGE_SUCC(stmt_bb, 0) : NULL;
+  int default_prob = default_edge ? default_edge-probability : 0;
   int base = get_outgoing_edge_probs (stmt_bb);
   bool try_with_tablejump = false;

@@ -1997,7 +1999,8 @@ emit_case_dispatch_table (tree index_expr, tree in
   default_prob = 0;
 }

-  default_edge-probability = default_prob;
+  if (default_edge)
+default_edge-probability = default_prob;

   /* We have altered the probability of the default edge. So the probabilities
  of all other edges need to be adjusted so that it sums up to
@@ -2289,7 +2292,8 @@ expand_sjlj_dispatch_table (rtx dispatch_index,

   emit_case_dispatch_table (index_expr, index_type,
  case_list, default_label,
- minval, maxval, range, NULL);
+ minval, maxval, range,
+BLOCK_FOR_INSN (before_case));
   emit_label (default_label);
   free_alloc_pool (case_node_pool);
 }

Re: [asan] Protection of globals

[Diego Novillo]

On 2012-10-17 07:11 , Jakub Jelinek wrote:


2012-10-17  Jakub Jelinek  ja...@redhat.com

* varasm.c: Include asan.h.
(assemble_noswitch_variable): Grow size by asan_red_zone_size
if decl is asan protected.
(place_block_symbol): Likewise.
(assemble_variable): If decl is asan protected, increase
DECL_ALIGN if needed, and for decls emitted using
assemble_variable_contents append padding zeros after it.
* Makefile.in (varasm.o): Depend on asan.h.
* asan.c: Include output.h.
(asan_pp, asan_pp_initialized): New variables.
(asan_pp_initialize, asan_pp_string): New functions.
(asan_emit_stack_protection): Use asan_pp{,_initialized}
instead of local pp{,_initialized} vars, use asan_pp_initialize
and asan_pp_string helpers.
(asan_needs_local_alias, asan_protect_global,
asan_global_struct, asan_add_global): New functions.
(asan_finish_file): Protect global vars that can be protected.
* asan.h (asan_protect_global): New prototype.
(asan_red_zone_size): New inline function.


This is OK.


Thanks.  Diego.

Re: [asan] Protection of stack vars (take 3)

[Diego Novillo]

On 2012-10-17 05:35 , Jakub Jelinek wrote:


2012-10-17  Jakub Jelinek  ja...@redhat.com

* Makefile.in (asan.o): Depend on $(EXPR_H) $(OPTABS_H).
(cfgexpand.o): Depend on asan.h.
* asan.c: Include expr.h and optabs.h.
(asan_shadow_set): New variable.
(asan_shadow_cst, asan_emit_stack_protection): New functions.
(asan_init_shadow_ptr_types): Initialize also asan_shadow_set.
* cfgexpand.c: Include asan.h.  Define HOST_WIDE_INT heap vector.
(partition_stack_vars): If i is large alignment and j small
alignment or vice versa, break out of the loop instead of continue,
and put the test earlier.  If flag_asan, break out of the loop
if for small alignment size is different.
(struct stack_vars_data): New type.
(expand_stack_vars): Add DATA argument.  Change PRED type to
function taking size_t argument instead of tree.  Adjust pred calls.
Fill DATA in and add needed padding in between variables if -fasan.
(defer_stack_allocation): Defer everything for flag_asan.
(stack_protect_decl_phase_1, stack_protect_decl_phase_2): Take
size_t index into stack_vars array instead of the decl directly.
(asan_decl_phase_3): New function.
(expand_used_vars): Return var destruction sequence.  Adjust
expand_stack_vars calls, add another one for flag_asan.  Call
asan_emit_stack_protection if expand_stack_vars added anything
to the vectors.
(expand_gimple_basic_block): Add disable_tail_calls argument.
(gimple_expand_cfg): Pass true to it if expand_used_vars returned
non-NULL.  Emit the sequence returned by expand_used_vars after
return_label.
* asan.h (asan_emit_stack_protection): New prototype.
(asan_shadow_set): New decl.
(ASAN_RED_ZONE_SIZE, ASAN_STACK_MAGIC_LEFT, ASAN_STACK_MAGIC_MIDDLE,
ASAN_STACK_MAGIC_RIGHT, ASAN_STACK_FRAME_MAGIC): Define.
(asan_protect_stack_decl): New inline.
* toplev.c (process_options): Also disable -fasan on
!FRAME_GROWS_DOWNWARDS targets.


This is OK.  Thanks.


Diego.

Re: [asan] Emit GIMPLE directly, small cleanups

[Eric Botcazou]

 Eric, Rainer, what do you think of the other two options I outlined in
 my earlier message?
 
 1- Copy the upstream testsuite into gcc/testsuite/asan.  This gives us
 the flexibility of adding new tests as the GCC implementation matures.
 
 2- Deal with libasan as we deal with zlib/boehm-gc.
 
 I prefer option #1, personally.

I feel a bit umconfortable saying this given the gcc/testsuite/ada/acats 
precedent, but I don't think we should import foreing testsuites into 
gcc/testsuite, unless they are adapted to our harness.  I don't think we
want to run again into the issues we had with acats (Rainer puts a lot of 
efforts to clean up the mess here).

-- 
Eric Botcazou

Re: [path] PR 54900: store data race in if-conversion pass

[Aldy Hernandez]

On 10/16/12 23:21, Jeff Law wrote:

On 10/16/2012 07:51 PM, Richard Henderson wrote:

On 2012-10-17 09:53, Aldy Hernandez wrote:

+/* Like memory_modified_in_insn_p, but return TRUE if INSN will
+   *SURELY* modify the memory contents of MEM.  */
+bool
+memory_surely_modified_in_insn_p (const_rtx mem, const_rtx insn)


I don't like the word surely.  Are we certain or not?

It's longer, but perhaps definitely or must_be?

I'd go with must_be or something similar.  must is pretty common
terminology when talking about aliasing properties.

jeff


must_be it is.

Committed the patch below.

Thanks.
PR rtl-optimization/54900
* ifcvt.c (noce_can_store_speculate_p): Call
memory_must_be_modified_in_insn_p.
* alias.c (memory_must_be_modified_in_insn_p): New.
(set_dest_equal_p): New.
* rtl.h (memory_must_be_modified_in_p): Protoize.

diff --git a/gcc/alias.c b/gcc/alias.c
index 244ca52..c5e6417 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -2762,6 +2762,39 @@ memory_modified_in_insn_p (const_rtx mem, const_rtx insn)
   return memory_modified;
 }
 
+/* Return TRUE if the destination of a set is rtx identical to
+   ITEM.  */
+static inline bool
+set_dest_equal_p (const_rtx set, const_rtx item)
+{
+  rtx dest = SET_DEST (set);
+  return rtx_equal_p (dest, item);
+}
+
+/* Like memory_modified_in_insn_p, but return TRUE if INSN will
+   *DEFINITELY* modify the memory contents of MEM.  */
+bool
+memory_must_be_modified_in_insn_p (const_rtx mem, const_rtx insn)
+{
+  if (!INSN_P (insn))
+return false;
+  insn = PATTERN (insn);
+  if (GET_CODE (insn) == SET)
+return set_dest_equal_p (insn, mem);
+  else if (GET_CODE (insn) == PARALLEL)
+{
+  int i;
+  for (i = 0; i  XVECLEN (insn, 0); i++)
+   {
+ rtx sub = XVECEXP (insn, 0, i);
+ if (GET_CODE (sub) == SET
+   set_dest_equal_p (sub, mem))
+   return true;
+   }
+}
+  return false;
+}
+
 /* Initialize the aliasing machinery.  Initialize the REG_KNOWN_VALUE
array.  */
 
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 2f486a2..5654c66 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2415,7 +2415,7 @@ noce_can_store_speculate_p (basic_block top_bb, const_rtx 
mem)
  || (CALL_P (insn)  (!RTL_CONST_CALL_P (insn)
return false;
 
- if (memory_modified_in_insn_p (mem, insn))
+ if (memory_must_be_modified_in_insn_p (mem, insn))
return true;
  if (modified_in_p (XEXP (mem, 0), insn))
return false;
diff --git a/gcc/rtl.h b/gcc/rtl.h
index eeeb6ba..09f1e77 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -2616,6 +2616,7 @@ extern void init_alias_analysis (void);
 extern void end_alias_analysis (void);
 extern void vt_equate_reg_base_value (const_rtx, const_rtx);
 extern bool memory_modified_in_insn_p (const_rtx, const_rtx);
+extern bool memory_must_be_modified_in_insn_p (const_rtx, const_rtx);
 extern bool may_be_sp_based_p (rtx);
 extern rtx gen_hard_reg_clobber (enum machine_mode, unsigned int);
 extern rtx get_reg_known_value (unsigned int);

PR c/53063 Handle Wformat with LangEnabledBy

[Manuel López-Ibáñez]

Bootstrapped and regression tested on x86_64-linux-gnu. Since Wformat
didn't have Var() associated, its corresponding entry was set to -1,
which is what warning(OPT_Wformat) checks for. Therefore, any such
warnings which were not guarded by if(warn_format), were enabled by
default. I only found one case in the objective-C FE.

The old code accepts -Wformat=X with X any number but -Wno-format=2
does not have any effect. The documentation only mentions -Wformat,
-Wno-format, -Wformat=2 and -Wno-format=2. I followed the
documentation but I can also implement -Wformat=0 being an alias for
-Wno-format and -Wformat=1 an alias for -Wformat and simply reject
-Wno-format=.

2012-10-17  Manuel López-Ibáñez  m...@gcc.gnu.org

PR c/53063
c-family/
* c.opt (Wformat, Wformat-extra-args, Wformat-nonliteral,
Wformat-contains-nul, Wformat-security, Wformat-y2k,
Wformat-zero-length, Wformat=2, Wnonnull): Use LangEnabledBy.
* c-opts.c (c_common_handle_option): Do not handle explicitly
here.
* c-common.c (warn_format): Delete.
* c-format.c (set_Wformat): Delete.
* c-common.h (warn_format,set_Wformat): Do not declare.
testsuite/
* gcc.dg/warn-nsstring.c: Add -Wformat.
* gcc.misc-tests/help.exp (check_for_options): Use
-Wstrict-aliasing for test.


wformat.diff
Description: Binary data

Re: PR c++/54928 infinite ICE when reporting ICE on macro expansion

[Gabriel Dos Reis]

On Wed, Oct 17, 2012 at 6:26 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
 On 17 October 2012 11:55, Dodji Seketeli do...@redhat.com wrote:
 Hello Manuel,

 Let's CC Gaby on this one as well.

 Manuel López-Ibáñez lopeziba...@gmail.com writes:

 The problem is that the macro unwinder code is changing the original
 diagnostic type and not restoring it, so the code detecting that we
 ICE fails to abort, which triggers another ICE, and so on. But there
 is no point in modifying the original diagnostic, we can simply create
 a temporary copy and use that for macro unwinding.

 We modify the context as well, and we set it back to its original value
 before getting out.  Why not just doing the same for the diagnostic_info
 type? I mean, just save diagnostics-kind before changing it, and set it
 back to the saved value before getting out?  That is less expensive than
 copying all of the diagnostic_info.

 Well, the difference is that for context, we are not sure that what we
 get at the end of the function is actually the same that we received.
 I am not sure if there is some buffer/obstack growth there. For
 diagnostic_info it is very different: we want to return exactly the
 original. (And in fact, both maybe_unwind_expanded_macro_loc and
 diagnostic_build_prefix should take a const * diagnostic_info).

 Also, I am not sure why we need to restore the prefix. Once the
 warning/error has been printed and we are just attaching notes from
 the unwinder, we don't care about the original prefix so we may simply
 destroy it. In fact, I think we are *leaking memory* by not destroying
 the prefix. Perhaps the prefix should be destroyed always after the
 finalizer and the default finalizer should be empty?

 Actually, I would propose going even a step further and use a more
 high-level api instead of calling into the pretty-printer directly.
 Something like: diagnostic_attach_note(context, const *
 diagnostic_info, location_t, const char * message, ...) that for
 example will check for context-inhibit_notes_p, will make sure the
 message is translated, will make sure that diagnostic_info is not
 overriden, will print the caret (or not), etc. This will live in
 diagnostic.c and could be used by customized diagnostic hooks to
 attach notes to an existing diagnostic. It would be a bit less
 optimized than the current code, but more re-usable.

 What do you think?

That makes sense and is what we should do.


 It would be good to have Gaby's opinion as well, since what I am
 proposing is more far-reaching.

 Cheers,

 Manuel.

Re: [PATCH] partial fix for PR target/54404

[Mike Stump]

On Oct 17, 2012, at 12:59 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
   The attached patch eliminates the failures in 
 g++.dg/other/darwin-cfstring1.C 
 and obj-c++.dg/strings/const-cfstring-2.mm by adding 
 -ftrack-macro-expansion=0 

 Okay for gcc trunk?

Ok.

[patch] fix outdated path in cpp.texi

[Jonathan Wakely]

http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html claims the search
path for C++ headers starts with /usr/include/g++-v3 which hasn't been
true for many years.

2012-10-18  Jonathan Wakely  jwakely@gmail.com

* doc/cpp.texi (Search Path): Fix outdated C++ path.

Tested with make doc html - OK for trunk and the active branches?
commit 0361812a731853c926adfcaab2e68137b80b9a65
Author: Jonathan Wakely jwakely@gmail.com
Date:   Thu Oct 18 00:32:07 2012 +0100

* doc/cpp.texi (Search Path): Fix outdated C++ path.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index fa5989e..e05029b 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -856,7 +856,7 @@ requested with @code{@w{#include @var{file}}} in:
 /usr/include
 @end smallexample
 
-For C++ programs, it will also look in @file{/usr/include/g++-v3},
+For C++ programs, it will also look in @file{/usr/include/c++/@var{version}},
 first.  In the above, @var{target} is the canonical name of the system
 GCC was configured to compile code for; often but not always the same as
 the canonical name of the system it runs on.  @var{version} is the

Re: [C++] Handle ?: for vectors

[Jason Merrill]

On 10/17/2012 12:56 PM, Marc Glisse wrote:

+  if (!COMPARISON_CLASS_P (arg1))
+   {
+ if (TYPE_UNSIGNED (TREE_TYPE (arg1_type)))
+   {
+ arg1_type = signed_type_for (arg1_type);
+ arg1 = convert (arg1_type, arg1);
+   }
+ arg1 = build2 (LT_EXPR, arg1_type, arg1,
+build_zero_cst (arg1_type));
+   }


Why LT_EXPR rather than NE_EXPR?

Jason

Re: [C++ Patch] PR 54501

[Jason Merrill]

Hmm, I thought I fixed a very similar bug recently.

I'm concerned that this change will cause problems with brace-elision 
situations.  But then again, can we have a zero-length array followed by 
anything else?


Jason

[patch] m32c: fix pr54950

[DJ Delorie]

Fixed 16-bit widening multiplies by a constant by limiting constant
matches to 16 bit constants.  Applied.

PR target/54950
* config/m32c/predicates.md (m32c_const_u16_operand): New.
* config/m32c/muldiv.md: Use it.

Index: config/m32c/predicates.md
===
--- config/m32c/predicates.md   (revision 192552)
+++ config/m32c/predicates.md   (working copy)
@@ -293,3 +293,7 @@
 (define_predicate m32c_1mask16_operand
   (and (match_operand 0 const_int_operand)
(match_test m32c_const_ok_for_constraint_p(INTVAL(op), 'I', 
\Imw\
+
+(define_predicate m32c_const_u16_operand
+  (and (match_operand 0 const_int_operand)
+   (match_test fprintf(stderr, \u16=%d\\n\, INTVAL(op)),INTVAL (op) = 
0  INTVAL (op) = 65535)))
Index: config/m32c/muldiv.md
===
--- config/m32c/muldiv.md   (revision 192552)
+++ config/m32c/muldiv.md   (working copy)
@@ -108,7 +108,7 @@
 (define_insn umulhisi3_c
   [(set (match_operand:SI 0 ra_operand =Rsi)
 (mult:SI (zero_extend:SI (match_operand:HI 1 mra_operand %0))
- (match_operand 2 immediate_operand i)))]
+ (match_operand 2 m32c_const_u16_operand i)))]
   
   mulu.w\t%u2,%1
   [(set_attr flags o)]

building gcc with powerpc gold

[Alan Modra]

These two tests currently fail if using gold, in the first instance
because powerpc64 gold doesn't support mixing old dot-sym objects
with new objects, and in the second instance because gold doesn't have
a --no-toc-sort option.  Both macros ought to be defined for gold.
Tested etc.  OK to apply everywhere?

* configure.ac (HAVE_LD_NO_DOT_SYMS): Set if using gold.
(HAVE_LD_LARGE_TOC): Likewise.
* configure: Regenerate.

Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 192236)
+++ gcc/configure.ac(working copy)
@@ -4379,7 +4379,9 @@
 AC_CACHE_CHECK(linker support for omitting dot symbols,
 gcc_cv_ld_no_dot_syms,
 [gcc_cv_ld_no_dot_syms=no
-if test $in_tree_ld = yes ; then
+if test x$ld_is_gold = xyes; then
+  gcc_cv_ld_no_dot_syms=yes
+elif test $in_tree_ld = yes ; then
   if test $gcc_cv_gld_major_version -eq 2 -a $gcc_cv_gld_minor_version 
-ge 16 -o $gcc_cv_gld_major_version -gt 2; then
 gcc_cv_ld_no_dot_syms=yes
   fi
@@ -4416,7 +4418,9 @@
 AC_CACHE_CHECK(linker large toc support,
 gcc_cv_ld_large_toc,
 [gcc_cv_ld_large_toc=no
-if test $in_tree_ld = yes ; then
+if test x$ld_is_gold = xyes; then
+  gcc_cv_ld_large_toc=yes
+elif test $in_tree_ld = yes ; then
   if test $gcc_cv_gld_major_version -eq 2 -a $gcc_cv_gld_minor_version 
-ge 21 -o $gcc_cv_gld_major_version -gt 2; then
 gcc_cv_ld_large_toc=yes
   fi

-- 
Alan Modra
Australia Development Lab, IBM

Re: [C++] Handle ?: for vectors

[Marc Glisse]

On Wed, 17 Oct 2012, Jason Merrill wrote:


On 10/17/2012 12:56 PM, Marc Glisse wrote:

+  if (!COMPARISON_CLASS_P (arg1))
+   {
+ if (TYPE_UNSIGNED (TREE_TYPE (arg1_type)))
+   {
+ arg1_type = signed_type_for (arg1_type);
+ arg1 = convert (arg1_type, arg1);
+   }
+ arg1 = build2 (LT_EXPR, arg1_type, arg1,
+build_zero_cst (arg1_type));
+   }


Why LT_EXPR rather than NE_EXPR?


Assuming we try to follow OpenCL:

6.3i

The ternary selection operator (?:) operates on three expressions (exp1 ? 
exp2 : exp3). This operator evaluates the first expression exp1, which can 
be a scalar or vector result except float. If the result is a scalar value 
then it selects to evaluate the second expression if the result compares 
unequal to 0, otherwise it selects to evaluate the third expression. If 
the result is a vector value, then this is equivalent to calling 
select(exp3, exp2, exp1). The select function is described in table 6.14. 
The second and third expressions can be any type, as long their types 
match, or there is a conversion in section 6.2.1 Implicit Conversions that 
can be applied to one of the expressions to make their types match, or one 
is a vector and the other is a scalar and the scalar may be subject to the 
usual arithmetic conversion to the element type used by the vector operand 
and widened to the same type as the vector type. This resulting matching 
type is the type of the entire expression.



table 6.14:

gentype select (gentype a, gentype b, igentype c)

For each component of a vector type,
result[i] = if MSB of c[i] is set ? b[i] : a[i].

===

We could deviate from OpenCL in a few places though, if you prefer.

Note that operator! (not implemented) still means == 0.


Thanks for the quick comment despite the meeting,

--
Marc Glisse

Re: [C++] Handle ?: for vectors

[Jason Merrill]

On 10/17/2012 10:30 PM, Marc Glisse wrote:

For each component of a vector type,
result[i] = if MSB of c[i] is set ? b[i] : a[i].


Curious.  Do you know why they produce and expect -1 for true?  It 
certainly seems to be a deliberate design choice, so I wonder what 
motivated it.


I think people will expect a 0 value to be considered true, so I am 
inclined to deviate in this case.


Jason

Re: [patch] m32c: fix pr54950

[Ramana Radhakrishnan]

On 18 Oct 2012, at 02:50, DJ Delorie d...@redhat.com wrote:

 
 Fixed 16-bit widening multiplies by a constant by limiting constant
 matches to 16 bit constants.  Applied.
 
PR target/54950
* config/m32c/predicates.md (m32c_const_u16_operand): New.
* config/m32c/muldiv.md: Use it.
 
 Index: config/m32c/predicates.md
 ===
 --- config/m32c/predicates.md(revision 192552)
 +++ config/m32c/predicates.md(working copy)
 @@ -293,3 +293,7 @@
 (define_predicate m32c_1mask16_operand
   (and (match_operand 0 const_int_operand)
(match_test m32c_const_ok_for_constraint_p(INTVAL(op), 'I', 
 \Imw\
 +
 +(define_predicate m32c_const_u16_operand
 +  (and (match_operand 0 const_int_operand)
 +   (match_test fprintf(stderr, \u16=%d\\n\, INTVAL(op)),INTVAL (op) 
 = 0  INTVAL (op) = 65535)))


Are you sure you meant to have an fprintf in a match_test ?


Ramana
 Index: config/m32c/muldiv.md
 ===
 --- config/m32c/muldiv.md(revision 192552)
 +++ config/m32c/muldiv.md(working copy)
 @@ -108,7 +108,7 @@
 (define_insn umulhisi3_c
   [(set (match_operand:SI 0 ra_operand =Rsi)
 (mult:SI (zero_extend:SI (match_operand:HI 1 mra_operand %0))
 - (match_operand 2 immediate_operand i)))]
 + (match_operand 2 m32c_const_u16_operand i)))]
   
   mulu.w\t%u2,%1
   [(set_attr flags o)]

Re: [patch] m32c: fix pr54950

[DJ Delorie]

 Are you sure you meant to have an fprintf in a match_test ?

I definitely did not.  Removed.  Thanks!