Re: [PATCH] IPA REF: alias refactoring

[Jan Hubicka]

> Hi,
> this patch enhances alias manipulation for symtab_node. Honza suggested 
> following changes.
> 
> Patch is pre approved, will be committed if no comments and regressions.
> Bootstrapped on x86_64-pc-linux-gnu, regression tests have been running.
> 
> Thanks,
> Martin
> 
> gcc/ChangeLog:
> 
> * cgraph.h (iterate_direct_aliases): New function.
> (FOR_EACH_ALIAS): New macro iterates all direct aliases for a node.
> * cgraph.c (cgraph_for_node_thunks_and_aliases): Usage of
> FOR_EACH_ALIAS added.
> (cgraph_for_node_and_aliases): Likewise.
> * cgraphunit.c (assemble_thunks_and_aliases): Likewise.
> * ipa-inline.c (reset_edge_caches): Likewise.
> (update_caller_keys): Likewise.
> * trans-mem.c (ipa_tm_execute): Likewise.
> *varpool.c (varpool_analyze_node): Likewise.
> (varpool_for_node_and_aliases): Likewise.
> * ipa-ref.h (first_referring_alias): New function.
> (last_referring_alias): Likewise.

I missed it last time around, I think first_alias/last_alias are better names.
first_alias is unused. If you added it I guess FOR_EACH_ALIAS should use it.

We probably also can bring has_aliases_p inline and implement it using
first_referring_alias.

> +  /* If deleted item is IPA_REF_ALIAS, we have to move last
> +  item of IPA_REF_LIST type to the deleted position. After that
> +  we replace last node with deletion slot.  */
> +  struct ipa_ref *last_alias = list->last_referring_alias ();

You can avoid walking to last alias when the removed item is not IPA_REF_ALIAS.

> +
> +  /* IPA_REF_ALIAS is always put at the beginning of the list.   */
inserted?

OK with these changes (or if you already comitted, just do them incrementally)

Honza

Re: [PATCH] Pass correct memory attributes for build constant

[Jan Hubicka]

> On 06/25/14 21:38, Kito Cheng wrote:
> >For example in arm-elf-eabi, movmem need word align, otherwise it will
> >expand a libcall:
> >
> >And gcc configure with "--target=arm-elf-eabi --disable-nls
> >--disable-shared --enable-languages=c,c++ --enable-threads=single
> >--enable-lto --with-newlib"
> >
> >test.c:
> >extern bar(unsigned char p[3][2]);
> >void foo(int i)
> >{
> > unsigned char data[3][2] = {{1,1}, {1,0}, {1,1}};
> >
> > bar(data);
> >}
> First, note, I'm not an ARM expert.  However, the first question I
> have is are we sure the initializer is always going to be suitably
> aligned?   What guarantees this initializer is going to have 32 bit

On not so related note,  vectorizer knows everything about how to increase
alignment of a declaration (not in constant pool for now, because that one is
riddled by implementation defaults) on demand.   It would be nice to teach
string operation expanders to do so when they think it helps.
(see vect_can_force_dr_alignment_p)
> alignment like you want?  I can see how that *section* gets its
> alignment, but I don't offhand see what in the ARM backend ensures
> that a CONSTRUCTOR tree has larger than normal known alignment.

I think those boil down into CONSTANT_DECL that is aligned by DATA_ALIGNMENT.
But it would be great to have API to boos these up on the demand.
I find the whole macro macinery around memcpy/memset bit difficult - one think
I would like it do to is this trick, other thing is to allow vector registers to
be used by COPY_BY_PIECES.

Honza
> 
> I think that needs to be settled first, then we need to verify that
> the trees are correctly carrying that alignment requirement around
> and that the code uses it appropriately (and I have my doubts
> because EXP is a CONSTRUCTOR element and those seem to be largely
> ignored in the code we're looking to change).
> 
> I would also strongly recommend turning your testcase into something
> we can add to the testsuite.
> 
> If you look in gcc/testsuite/gcc.target/arm you'll see several
> examples.  I think you just want to compile this down to assembly
> code with the optimizer enabled, then verify there is no call to
> memcpy in the resulting output.  20030909-1.c would seem to be a
> reasonable example of a test that does something similar.
> 
> 
> Jeff

Re: [patch 1/4] change specific int128 -> generic intN

[DJ Delorie]

> Yes; I think that makes sense, unless someone produces a clearer 
> definition of what TYPE_SIZE means that isn't redundant.

Does TYPE_SIZE have a different meaning than TYPE_PRECISION
for non-integer types?  Floats, vectors, complex?

Re: [PATCH] Pass correct memory attributes for build constant

[Jeff Law]

On 06/25/14 21:38, Kito Cheng wrote:

For example in arm-elf-eabi, movmem need word align, otherwise it will
expand a libcall:

And gcc configure with "--target=arm-elf-eabi --disable-nls
--disable-shared --enable-languages=c,c++ --enable-threads=single
--enable-lto --with-newlib"

test.c:
extern bar(unsigned char p[3][2]);
void foo(int i)
{
 unsigned char data[3][2] = {{1,1}, {1,0}, {1,1}};

 bar(data);
}
First, note, I'm not an ARM expert.  However, the first question I have 
is are we sure the initializer is always going to be suitably aligned? 
  What guarantees this initializer is going to have 32 bit alignment 
like you want?  I can see how that *section* gets its alignment, but I 
don't offhand see what in the ARM backend ensures that a CONSTRUCTOR 
tree has larger than normal known alignment.


I think that needs to be settled first, then we need to verify that the 
trees are correctly carrying that alignment requirement around and that 
the code uses it appropriately (and I have my doubts because EXP is a 
CONSTRUCTOR element and those seem to be largely ignored in the code 
we're looking to change).


I would also strongly recommend turning your testcase into something we 
can add to the testsuite.


If you look in gcc/testsuite/gcc.target/arm you'll see several examples. 
 I think you just want to compile this down to assembly code with the 
optimizer enabled, then verify there is no call to memcpy in the 
resulting output.  20030909-1.c would seem to be a reasonable example of 
a test that does something similar.



Jeff

Re: [GOOGLE] Report the difference between profiled and guessed or annotated branch probabilities.

[Xinliang David Li]

Hi Yi,

1) please add comments before new functions as documentation -- follow
the coding style guideline
2) missing documenation on the new flags (pointed out by Gerald)
3) Please refactor the check code in afdo_calculate_branch_prob into a
helper function

4) the change log is not needed for google branches, but if provided,
the format should follow the style guide (e.g, function name in () ).

David


On Fri, Jun 27, 2014 at 11:07 AM, Yi Yang  wrote:
> Hi,
>
> This patch adds an option. When the option is enabled, GCC will add a
> record about it in an elf section called
> ".gnu.switches.text.branch.annotation" for every branch.
>
> gcc/
>
> 2014-06-27 Yi Yang 
>
> * auto-profile.c: Main comparison and reporting logic.
> * cfg-flags.def: Add an extra flag representing an edge's
> probability is predicted by annotations.
> * predict.c: Set up the extra flag on an edge when appropriate.
> * common.opt: Add an extra GCC option to turn on this report mechanism

Re: [GOOGLE] Report the difference between profiled and guessed or annotated branch probabilities.

[Yi Yang]

I'm glad this feature is useful to people.

I haven't looked at the normal profiling process though. If anybody
would like to port this code to normal profiling, I'm more than
pleased to see that happen. Maybe I'll do that myself when I have
time, but do not count on that :)

On Fri, Jun 27, 2014 at 12:18 PM, Andi Kleen  wrote:
> Yi Yang  writes:
>
>> Hi,
>>
>> This patch adds an option. When the option is enabled, GCC will add a
>> record about it in an elf section called
>> ".gnu.switches.text.branch.annotation" for every branch.
>
> This would be nice to have even in mainline for the normal profiling.
>
> -Andi
>
> --
> a...@linux.intel.com -- Speaking for myself only

Re: [patch 1/4] change specific int128 -> generic intN

[Joseph S. Myers]

On Fri, 27 Jun 2014, DJ Delorie wrote:

> Are you proposing we remove TYPE_SIZE completely?

Yes; I think that makes sense, unless someone produces a clearer 
definition of what TYPE_SIZE means that isn't redundant.

If you find a particular use of TYPE_SIZE is using a size that isn't 
correct for your type whose precision is not a multiple of BITS_PER_UNIT, 
then in my model the correct fix is to change that use of TYPE_SIZE rather 
than to change the value of TYPE_SIZE for that type - and such a change 
(to use TYPE_PRECISION, maybe) would also be incremental progress towards 
eliminating TYPE_SIZE.

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

Re: [patch 1/4] change specific int128 -> generic intN

[DJ Delorie]

Are you proposing we remove TYPE_SIZE completely?

C++ PATCH for c++/61433 (ICE with -fcompare-debug)

[Jason Merrill]

dump_template_bindings tries to do tsubsting in order to print what 
dependent types used in the template signature actually resolve to.  But 
that doesn't work to well when we're in a clone context, where we don't 
have a reasonable DECL_LANG_SPECIFIC to work with.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2b1389491f53fd7ecc9dfe90b55c1d48c4c4548a
Author: Jason Merrill 
Date:   Fri Jun 27 16:19:47 2014 -0400

	PR c++/61433
	* error.c (dump_template_bindings): Don't tsubst in a clone.

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 27a167a..fa3bdc4 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -318,6 +318,11 @@ dump_template_bindings (cxx_pretty_printer *pp, tree parms, tree args,
   if (vec_safe_is_empty (typenames) || uses_template_parms (args))
 return;
 
+  /* Don't try to print typenames when we're processing a clone.  */
+  if (current_function_decl
+  && !DECL_LANG_SPECIFIC (current_function_decl))
+return;
+
   FOR_EACH_VEC_SAFE_ELT (typenames, i, t)
 {
   if (need_semicolon)
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/pr61433.C b/gcc/testsuite/g++.dg/debug/dwarf2/pr61433.C
new file mode 100644
index 000..a63b8a9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/pr61433.C
@@ -0,0 +1,23 @@
+// PR c++/61433
+// { dg-do compile { target c++11 } }
+// { dg-options "-O -fcompare-debug -fno-inline -fno-ipa-pure-const -fipa-sra" }
+
+template 
+struct A
+{
+  template 
+  struct B
+  {
+int MEM;
+  };
+};
+struct D {};
+struct C: public A::B
+{};
+template 
+auto k(T t, U u, V v) -> decltype (t.U::template B::MEM)
+{}
+int main()
+{
+  k( C(), A(), D() );
+}

Re: [patch 1/4] change specific int128 -> generic intN

[Joseph S. Myers]

On Fri, 27 Jun 2014, DJ Delorie wrote:

> If you still disagree, let's first figure out what the right
> relationship between TYPE_SIZE and TYPE_SIZE_UNIT is, for types that
> aren't a multiple of BITS_PER_UNIT.

My suggestion: TYPE_SIZE should always be TYPE_SIZE_UNIT times 
BITS_PER_UNIT, so including any padding bits (and so should not exist, 
really - it's an extra pointer bulking up lots of trees with redundant 
information), while TYPE_PRECISION is what gives the number of value / 
sign bits.  If you're allocating bit-fields, TYPE_PRECISION will say how 
many bits to use; if you're allocating registers (which might not always 
correspond neatly to multiples of BITS_PER_UNIT), TYPE_MODE is what's 
relevant; otherwise, you're allocating whole bytes in memory and can use 
TYPE_SIZE_UNIT.

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

[wwwdocs] Make a number of links relative

[Gerald Pfeifer]

This is the right thing in general, so that sites like www.gnu.org
that host a copy of our web pages do not link to gcc.gnu.org unless
necessary (for things like Bugzilla, mailing list archives,...).

And it saves us some http-to-https conversations.

Installed.

Gerald

Index: news.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v
retrieving revision 1.140
diff -u -r1.140 news.html
--- news.html   27 Jun 2014 11:48:46 -  1.140
+++ news.html   27 Jun 2014 20:38:32 -
@@ -614,8 +614,7 @@
 
 May 13, 2004
 
-The http://gcc.gnu.org/projects/tree-ssa/";>tree-ssa
-branch has been tree-ssa branch has been https://gcc.gnu.org/ml/gcc/2004-05/msg00679.html";>merged into
 mainline.
 
@@ -627,7 +626,7 @@
 
 February 25, 2004
 
-The http://gcc.gnu.org/projects/tree-ssa/";>tree-ssa branch
+The tree-ssa branch
 has been frozen to be incorporated into GCC 4.0.0.  Tree SSA
 incorporates two new high-level intermediate languages (GENERIC and
 GIMPLE), an optimization framework for GIMPLE based on the Static
Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.233
diff -u -r1.233 readings.html
--- readings.html   31 Oct 2013 18:03:28 -  1.233
+++ readings.html   27 Jun 2014 20:38:32 -
@@ -138,7 +138,7 @@
Manufacturer: Renesas
Exact chip name: H8/300
GDB includes a simulator.
-   http://gcc.gnu.org/projects/h8300-abi.html";>H8/300
+   H8/300
  Application Binary Interface for GCC.
  
  
Index: projects/beginner.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/beginner.html,v
retrieving revision 1.58
diff -u -r1.58 beginner.html
--- projects/beginner.html  27 Jun 2014 15:04:40 -  1.58
+++ projects/beginner.html  27 Jun 2014 20:38:57 -
@@ -98,7 +98,7 @@
 
 Perform additional GCC testing.
 
-See http://gcc.gnu.org/testing/";>GCC Testing Efforts
+See GCC Testing Efforts
 for ideas and information about what's already being done.
 
 
Index: projects/ia64.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/ia64.html,v
retrieving revision 1.22
diff -u -r1.22 ia64.html
--- projects/ia64.html  27 Jun 2014 15:04:40 -  1.22
+++ projects/ia64.html  27 Jun 2014 20:38:58 -
@@ -119,7 +119,7 @@
 is available through -fbranch-probabilities
 using data generated by first compiling with -fprofile-arcs.
 This is described in
-http://gcc.gnu.org/news/profiledriven.html";>Infrastructure for
+Infrastructure for
 Profile Driven Optimizations, which also lists items for future work.
 
 The following items came out of the June 2001 summit as issues to

Re: [patch] Simplify allocator use

[François Dumont]

On 26/06/2014 13:31, Jonathan Wakely wrote:

On 25/06/14 21:56 +0100, Jonathan Wakely wrote:

The other adds an RAII type to help manage pointers obtained from
allocators. The new type means I can remove several ugly try-catch
blocks that are all very similar in structure and have been bothering
me for some time. The new type also makes it trivial to support
allocators with fancy pointers, fixing long-standing (but not very
important) bugs in std::promise and std::shared_ptr.


This patch applies the __allocated_ptr type to hashtable_policy.h to
remove most explicit deallocation (yay!)  The buckets are still
allocated and deallocated manually, because __allocated_ptr only works
for allocations of single objects, not arrays.

As well as __allocated_ptr this change relies on two things:

1) the node type has a trivial destructor, so we don't actually need
  to call it, we can just reuse or release its storage.
  (See 3.8 [basic.life] p1)

2) allocator_traits::construct and allocator_traits::destroy can be
  used with an allocator that has a different value_type, so we don't
  need to create a rebound copy to destroy every element, we can just
  use the node-allocator.
  (See http://cplusplus.github.io/LWG/lwg-active.html#2218 which is
  Open, but I've discussed the issue with Howard, Pablo and others,
  and I think libc++ already relies on this assumption).

François, could you check it, and let me know if you see anything
wrong or have any comments?


That looks fine to me, nice simplification.

François

Re: testsuite allocators patch

[François Dumont]

On 27/06/2014 21:48, Paolo Carlini wrote:

Hi,

On 06/27/2014 07:33 PM, Jonathan Wakely wrote:

I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.

Ok, thanks. I'm reverting the last two libstdc++-v3 commits.

Paolo.

It run fine on my side but maybe because of other modifications I have. 
I will revert those and reapply the patch to see what is wrong.


Sorry

François

Re: [patch 1/4] change specific int128 -> generic intN

[DJ Delorie]

> No stor-layout.c listed here but...

I knew I'd miss at least one in the split-up...

> > Index: gcc/stor-layout.c
> > ===
> > --- gcc/stor-layout.c   (revision 211858)
> > +++ gcc/stor-layout.c   (working copy)
> > @@ -2123,13 +2142,13 @@ layout_type (tree type)
> > 
> >  case BOOLEAN_TYPE:
> >  case INTEGER_TYPE:
> >  case ENUMERAL_TYPE:
> >SET_TYPE_MODE (type,
> >  smallest_mode_for_size (TYPE_PRECISION (type), MODE_INT));
> > -  TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type)));
> > +  TYPE_SIZE (type) = bitsize_int (GET_MODE_PRECISION (TYPE_MODE
> > (type))); TYPE_SIZE_UNIT (type) = size_int (GET_MODE_SIZE (TYPE_MODE
> > (type))); break;
> 
> This doesn't look correct, you might end up with types smaller than their 
> modes and breaking the TYPE_SIZE/TYPE_SIZE_UNIT relationship.

The whole point of using _PRECISION is to have the size be exactly the
same as the mode (bitsize is bigger than the mode for partial-int
modes).  TYPE_SIZE_UNIT should be its storage size, right?  If the
type is not a multiple of BITS_PER_UNIT, the actual size and
stored-in-memory size are going to be different.

The problem in the old code is that BITSIZE is not the size in bits of
the type, it's the size in bytes times BITS_PER_UNIT.  This meant that
all partial-int modes would be converted into their non-partial modes
eventually.  Most of my patch is about avoiding that.

If you still disagree, let's first figure out what the right
relationship between TYPE_SIZE and TYPE_SIZE_UNIT is, for types that
aren't a multiple of BITS_PER_UNIT.

> > @@ -2516,16 +2535,33 @@ initialize_sizetypes (void)
> >  precision = LONG_TYPE_SIZE;
> >else if (strcmp (SIZETYPE, "long long unsigned int") == 0)
> >  precision = LONG_LONG_TYPE_SIZE;
> >else if (strcmp (SIZETYPE, "short unsigned int") == 0)
> >  precision = SHORT_TYPE_SIZE;
> >else
> > gcc_unreachable ();
> > 
> >bprecision
> > -= MIN (precision + BITS_PER_UNIT_LOG + 1, MAX_FIXED_MODE_SIZE);
> > += MIN (precision, MAX_FIXED_MODE_SIZE);
> >bprecision
> >  = GET_MODE_PRECISION (smallest_mode_for_size (bprecision, MODE_INT));
> >if (bprecision > HOST_BITS_PER_DOUBLE_INT)
> >  bprecision = HOST_BITS_PER_DOUBLE_INT;
> > 
> >/* Create stubs for sizetype and bitsizetype so we can create constants. 
> 
> Why are you reducing the precision here?

I'm not reducing it, I'm removing a case where it's rounded up.
Rounding up a 20-bit PSImode gives you SImode eventually.

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Jason Merrill]

On 06/27/2014 09:41 AM, Ed Smith-Rowland wrote:

The C++14 draft was finalized at the February meeting in Issaquah; the
ratification process isn't quite done, but I haven't heard any reason
to doubt that it will be done soon.  The __cplusplus date is 201402L.



I guess we should set this correctly in libcpp/init.c or wherever. Do
you see a problem with changing it from its current value of 201300?  We
don't use the actual number AFAICT.  I guess we could also use a fake
date for c++1z/c++17.  Say 201500?


Sounds good.


I've been thinking of adding a thing or two to C++1z like clang has -
The Disabling trigraph expansion by default looks easy.


Aren't trigraphs off by default already?


They are *off* by default with gnu++NN and *on* by default with c++NN.
We want them *off* by default for all (gnu|c)++(1z|17).  But -trigraphs
will restore them for all versions.


OK.

Jason

Re: [PATCH] PR preprocessor/60723 - missing system-ness marks for macro

[Jason Merrill]

On 06/27/2014 03:27 AM, Dodji Seketeli wrote:

+ && print.prev_was_system_token != !!in_system_header_at(loc))
+   /* The system-ness of this token is different from the one
+  of the previous token.  Let's emit a line change to
+  mark the new system-ness before we emit the token.  */
+   line_marker_emitted = do_line_change(pfile, token, loc, false);


Missing spaces before '('.  OK with that fixed.

Jason

[wwwdocs] Remove a self reference from projects/sched-treegion.html

[Gerald Pfeifer]

Looking at http vs https links I noticed that this page has a self
reference, which we can simply remove.

This way we can omit the http->https conversion altogether.

Applied.

Gerald

Index: projects/sched-treegion.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/sched-treegion.html,v
retrieving revision 1.6
diff -u -r1.6 sched-treegion.html
--- projects/sched-treegion.html7 Mar 2010 23:07:30 -   1.6
+++ projects/sched-treegion.html27 Jun 2014 20:28:28 -
@@ -33,9 +33,7 @@
 of the implementation of an architecture-independent, aggressive global 
 instruction scheduler based on Treegions. We also present a technique for 
 efficiently tail duplicating treegions considering the tradeoff between 
-codes size and ILP. Information about the branch can be found at 
-http://gcc.gnu.org/projects/sched-treegion.html";>
-http://gcc.gnu.org/projects/sched-treegion.html.  The implementation 
+codes size and ILP.  The implementation 
 currently resides on the sched-treegion-branch.
 
 Natural Treegion Formation

Re: [PATCH, alpha]: Wrap {un,}aligned_store sequence with memory blockages.

[Richard Henderson]

On 06/27/2014 10:04 AM, Uros Bizjak wrote:
> This happened due to the way stores to QImode and HImode locations are
> implemented on non-BWX targets. The sequence reads full word, does its
> magic to the part and stores the full word with changed part back to
> the memory. However - the scheduler mixed two sequences, violating the
> atomicity of RMW sequence.

Except that addresses with AND in them (ldq_u, stq_u) are already supposed to
be memory barriers.  So you shouldn't need to add such to them again.

I think something else has gone wrong somewhere.


r~

Re: Ok to backport r210653 (fix for PR58930) to gcc-4_9-branch?

[Jason Merrill]

On 06/27/2014 11:04 AM, Paul Pluzhnikov wrote:

Ok to backport r210653 (fix for PR58930) to gcc-4_9-branch?


OK, yes.

Jason

Re: testsuite allocators patch

[Paolo Carlini]

Hi,

On 06/27/2014 07:33 PM, Jonathan Wakely wrote:

I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.

Ok, thanks. I'm reverting the last two libstdc++-v3 commits.

Paolo.

[wwwdocs] Update http://gcc.gnu.org/PR links to https

[Gerald Pfeifer]

...across all web pages.

Once again the patch is too large for the lists, so I'm attaching
it in compressed format.

Gerald

patch-gcc.gnu.org\\PR-https.bz2
Description: application/bzip

Re: [GOOGLE] Report the difference between profiled and guessed or annotated branch probabilities.

[Andi Kleen]

Yi Yang  writes:

> Hi,
>
> This patch adds an option. When the option is enabled, GCC will add a
> record about it in an elf section called
> ".gnu.switches.text.branch.annotation" for every branch.

This would be nice to have even in mainline for the normal profiling.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH, rtl]: Teach _.barriers and _.eh_range passes to not split a call and its corresponding CALL_ARG_LOCATION note.

[Richard Henderson]

On 06/26/2014 02:15 PM, Uros Bizjak wrote:
> * except.c (emit_note_eh_region_end): New helper function.
> (convert_to_eh_region_ranges): Use emit_note_eh_region_end to
> emit EH_REGION_END note.

This bit looks good.


>rtx insn, next, prev;
> -  for (insn = get_insns (); insn; insn = next)
> +  for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
>  {
> -  next = NEXT_INSN (insn);
>if (BARRIER_P (insn))
>   {
> prev = prev_nonnote_insn (insn);
> if (!prev)
>   continue;
> +
> +   /* Make sure we do not split a call and its corresponding
> +  CALL_ARG_LOCATION note.  */
> +   next = NEXT_INSN (prev);
> +   if (next == NULL)
> + continue;
> +   if (NOTE_P (next)
> +   && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
> + prev = next;
> +

This bit looks more complicated than it needs to be.
It would also be helpful for legibility to move the
declarations from the top to the first uses.

The next == NULL test can never be true, since we've
already searched backward from insn.


r~

Re: [GOOGLE] Report the difference between profiled and guessed or annotated branch probabilities.

[Gerald Pfeifer]

On Fri, 27 Jun 2014, Yi Yang wrote:
> 2014-06-27 Yi Yang 
> 
> * auto-profile.c: Main comparison and reporting logic.
> * cfg-flags.def: Add an extra flag representing an edge's
> probability is predicted by annotations.
> * predict.c: Set up the extra flag on an edge when appropriate.
> * common.opt: Add an extra GCC option to turn on this report mechanism

Shouldn't there be documentation for this as well?  (In gcc/doc/*.texi?)

Gerald

[GOOGLE] Report the difference between profiled and guessed or annotated branch probabilities.

[Yi Yang]

Hi,

This patch adds an option. When the option is enabled, GCC will add a
record about it in an elf section called
".gnu.switches.text.branch.annotation" for every branch.

gcc/

2014-06-27 Yi Yang 

* auto-profile.c: Main comparison and reporting logic.
* cfg-flags.def: Add an extra flag representing an edge's
probability is predicted by annotations.
* predict.c: Set up the extra flag on an edge when appropriate.
* common.opt: Add an extra GCC option to turn on this report mechanism
diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
index 74d3d1d..f7698cd 100644
--- a/gcc/auto-profile.c
+++ b/gcc/auto-profile.c
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "opts.h"	  /* for in_fnames.	 */
 #include "tree-pass.h"	  /* for ipa pass.  */
 #include "cfgloop.h"	  /* for loop_optimizer_init.  */
+#include "md5.h"	  /* for hashing function names. */
 #include "gimple.h"
 #include "cgraph.h"
 #include "tree-flow.h"
@@ -1367,6 +1368,80 @@ afdo_propagate (void)
 }
 }
 
+struct locus_information_t {
+  char filename[1024];
+  unsigned lineno;
+  unsigned function_lineno;
+  char function_hash[33];
+};
+
+static bool
+get_locus_information (location_t locus, locus_information_t* li) {
+  if (locus == UNKNOWN_LOCATION || !LOCATION_FILE(locus))
+return false;
+  snprintf(li->filename, 1024, "%s", LOCATION_FILE(locus));
+  li->lineno = LOCATION_LINE(locus);
+
+  tree block = LOCATION_BLOCK (locus);
+  tree function_decl = current_function_decl;
+  
+  if (block && TREE_CODE (block) == BLOCK)
+{
+  for (block = BLOCK_SUPERCONTEXT (block);
+	   block && (TREE_CODE (block) == BLOCK);
+	   block = BLOCK_SUPERCONTEXT (block))
+	{
+	  location_t tmp_locus = BLOCK_SOURCE_LOCATION (block);
+	  if (LOCATION_LOCUS (tmp_locus) == UNKNOWN_LOCATION)
+	continue;
+
+	  tree decl = get_function_decl_from_block (block);
+	  function_decl = decl;
+	  break;
+	}
+}
+
+  if (!(function_decl && TREE_CODE (function_decl) == FUNCTION_DECL))
+return false;
+  unsigned function_length = 0;
+  function *f = DECL_STRUCT_FUNCTION(function_decl);
+
+  li->function_lineno = LOCATION_LINE(DECL_SOURCE_LOCATION(function_decl));
+
+  if (f)
+{
+  function_length = LOCATION_LINE(f->function_end_locus) -
+	li->function_lineno;
+}
+
+  const char *fn_name = fndecl_name(function_decl);
+  unsigned char md5_result[16];
+
+  md5_ctx ctx;
+
+  md5_init_ctx(&ctx);
+  md5_process_bytes(fn_name, strlen(fn_name), &ctx);
+  md5_process_bytes(&function_length, sizeof(function_length), &ctx);
+  md5_finish_ctx(&ctx, md5_result);
+
+  for (int i = 0; i < 16; ++i)
+{
+  sprintf(li->function_hash + i*2, "%02x", md5_result[i]);
+}
+  
+  return true;
+}
+
+void
+fill_invalid_locus_information(locus_information_t* li) {
+  snprintf(li->filename, 1024, "");
+  li->lineno = 0;
+  li->function_lineno = 0;
+  for (int i = 0; i < 32; ++i)
+li->function_hash[i] = '0';
+  li->function_hash[32] = '\0';
+}
+
 /* Propagate counts on control flow graph and calculate branch
probabilities.  */
 
@@ -1407,8 +1482,62 @@ afdo_calculate_branch_prob (void)
   if (num_unknown_succ == 0 && total_count > 0)
 	{
 	  FOR_EACH_EDGE (e, ei, bb->succs)
-	e->probability =
-		(double) e->count * REG_BR_PROB_BASE / total_count;
+	{
+	  double probability =
+		  (double) e->count * REG_BR_PROB_BASE / total_count;
+
+	  if (flag_check_branch_annotation &&
+		  bb->succs->length() == 2 &&
+		  maybe_hot_count_p (cfun, bb->count) &&
+		  bb->count >= 100)
+		{
+		  gimple_stmt_iterator gsi;
+		  gimple last = NULL;
+
+		  for (gsi = gsi_last_nondebug_bb (bb);
+		   !gsi_end_p (gsi);
+		   gsi_prev_nondebug (&gsi))
+		{
+		  last = gsi_stmt (gsi);
+
+		  if (gimple_has_location (last))
+			break;
+		}
+
+		  struct locus_information_t li;
+		  bool annotated;
+
+		  if (e->flags & EDGE_PREDICTED_BY_EXPECT)
+		annotated = true;
+		  else
+		annotated = false;
+
+		  if (get_locus_information(e->goto_locus, &li))
+		;
+		  else if (get_locus_information(gimple_location(last), &li))
+		;
+		  else
+		fill_invalid_locus_information(&li);
+
+		  switch_to_section (get_section (
+		  ".gnu.switches.text.branch.annotation",
+		  SECTION_DEBUG | SECTION_MERGE |
+		  SECTION_STRINGS | (SECTION_ENTSIZE & 1),
+		  NULL));
+		  char buf[1024];
+		  snprintf (buf, 1024, "%s;%u;%d;"
+			HOST_WIDEST_INT_PRINT_DEC";%.6lf;%.6lf;%s;%u",
+			li.filename, li.lineno, bb->count, annotated?1:0,
+			probability/REG_BR_PROB_BASE,
+			e->probability/(double)REG_BR_PROB_BASE,
+			li.function_hash, li.function_lineno);
+		  dw2_asm_output_nstring (buf, (size_t)-1, NULL);
+
+		  break;
+		}
+
+	  e->probability = probability;
+	}
 	}
 }
   FOR_ALL_BB (bb)
@@ -1417,8 +1546,11 @@ afdo_calculate_branch_prob (void)
   edge_iterator ei;
 
   FOR_EACH_EDGE (e, ei, bb->succs)
-	e->

Re: testsuite allocators patch

[Jonathan Wakely]

I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.

On 27 June 2014 08:27, Paolo Carlini  wrote:
> Hi,
>
>
> On 06/27/2014 12:38 AM, Jonathan Wakely wrote:
>>
>> On 26/06/14 23:21 +0200, Paolo Carlini wrote:
>>>
>>> Hi,
>>>
>>> I'm afraid something went badly wrong with this commit, I'm seeing tens
>>> of fails. See eg:
>>>
>>>https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg02439.html
>>
>>
>> It seems that uneq_allocator is no longer copy constructible.
>
> Can you spot a quick fix, like a thinko, or do you think Francois has to
> look into it? I'm inclined to revert it for now, the noise is quite
> annoying...
>
> Thanks,
> Paolo.

Re: [Patch, PR 61061] Add state limit for regex NFA

[Paolo Carlini]

Hi,

On 06/27/2014 06:53 PM, Tim Shen wrote:

PS: sorry for being distracted by other issues: what happened to the other
regex issue? I think we are simply going to apply, when ready, your more
complete fix, right?

The problem given in the other PR (PR 61582) is also solved by this
patch (but I forgot to mention that); They are all examples like
nested range quantifiers.
Good, thanks. I'll let Jon properly reviewing the patch, he followed 
your recent work more closely than me.

PR 61424's patch is ready; I was waiting for some "Ok go ahead", but
now I realize that I need to send the complete patch first :) I'll
send it later.
Yes, I meant that one, was too lazy to look it up ;) Thanks in advance, 
anyway!


Paolo.

Re: [C/C++ PATCH] Implement -Wsizeof-array-argument (PR c/6940)

[Joseph S. Myers]

On Fri, 27 Jun 2014, Marek Polacek wrote:

> The following is a revamped patch for -Wsizeof-array-argument.  Almost two
> months back there was an initial attempt by Prathamesh:
> , but that patch
> never made it in.  This version implements the warning for both C and C++
> FEs, adds more testing, enables the warning by default (I can move it to
> -Wall, of course), makes the warning work properly even for multidimensional
> arrays, etc.
> Its purpose is to detect suspicious usage of the sizeof operator on an array
> function parameter.  A few years back I fixed exactly this kind of bug in
> elfutils - so -Wsizeof-array-argument might be indeed useful.  (The warning 
> didn't
> trigger during GCC bootstrap though.)
> 
> Jason/Joseph, could you please look at the C++, resp. C FE parts?

The C changes are OK.

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

[PATCH, alpha]: Wrap {un,}aligned_store sequence with memory blockages.

[Uros Bizjak]

Hello!

The motivation for this patch was exposed miscompilation of gfortran
on alpha that resulted in:

FAIL: gfortran.dg/assumed_rank_3.f90:15.20:

print *, ubound(x,dim=3)  ! << wrong dim
1
Error: Assumed-rank variable x at (1) may only be used as actual argument

The problem was in the miscompilation of resolve_actual_arglist from
resolve.c.  This function initializes two nearby global bool variables
with the following sequence:

  actual_arg = true;
  first_actual_arg = true;

but due to the miscompilation, the actual_arg was never set to true.
This happened due to the way stores to QImode and HImode locations are
implemented on non-BWX targets. The sequence reads full word, does its
magic to the part and stores the full word with changed part back to
the memory. However - the scheduler mixed two sequences, violating the
atomicity of RMW sequence.

This can be illustrated with following test:

--cut here--
static char *a;
static char *b;

void foo (void)
{
  a[1] = 1;
  b[2] = 1;
}

int bar (void)
{
  return a && b;
}
--cut here--

$foo..ng:
.prologue 1
lda $1,1($31)
lda $2,a
ldq $3,0($2)   <-- load a
lda $2,b
lda $7,1($3)
ldq_u $5,1($3)   <-- load a
insbl $1,$7,$4
ldq $2,0($2)   <-- load b
mskbl $5,$7,$5
lda $6,2($2)
bis $4,$5,$4
stq_u $4,1($3)  <-- store a
insbl $1,$6,$1
ldq_u $3,2($2)   <-- load b
mskbl $3,$6,$3
cpys $f31,$f31,$f31
bis $1,$3,$1
stq_u $1,2($2)   <-- store b
ret $31,($26),1
.end foo

if a and b alias to the same wide memory location, then "b"  RMW
sequence corrupts "a".

The solution is to wrap the sequences with memory blockages to prevent
scheduler to move read and write around. These blockages thus ensure
atomicity of the sequence.

2014-06-27  Uros Bizjak  

* config/alpha/alpha.md (unspec): Add UNSPEC_MEMORY_BLOCKAGE.
(*memory_blockage): New.
(aligned_store): Wrap the expanded sequence with memory blockages
(unaligned_store): Ditto.

The patch was bootstrapped and regression tested on alpha-linux-gnu,
with the compiler, configured with "--target=alpha-linux-gnu
--host=alpha-linux-gnu --build=alpha-linux-gnu".

OK for mainline and release branches?

Uros.
Index: config/alpha/alpha.md
===
--- config/alpha/alpha.md   (revision 212063)
+++ config/alpha/alpha.md   (working copy)
@@ -58,6 +58,9 @@
   UNSPEC_ATOMIC
   UNSPEC_CMPXCHG
   UNSPEC_XCHG
+
+  ;; Scheduling
+  UNSPEC_MEMORY_BLOCKAGE
 ])
 
 ;; UNSPEC_VOLATILE:
@@ -3689,6 +3692,16 @@
   [(set_attr "length" "0")
(set_attr "type" "none")])
 
+;; Do not schedule instructions accessing memory across this point.
+
+(define_insn "*memory_blockage"
+  [(set (match_operand:BLK 0)
+   (unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BLOCKAGE))]
+  ""
+  ""
+  [(set_attr "length" "0")
+   (set_attr "type" "none")])
+
 (define_insn "jump"
   [(set (pc)
(label_ref (match_operand 0)))]
@@ -4269,7 +4282,9 @@
 ;; the value should be placed.  Operands 3 and 4 are SImode temporaries.
 
 (define_expand "aligned_store"
-  [(set (match_operand:SI 3 "register_operand")
+  [(set (match_dup 6)
+   (unspec:BLK [(match_dup 6)] UNSPEC_MEMORY_BLOCKAGE))
+   (set (match_operand:SI 3 "register_operand")
(match_operand:SI 0 "memory_operand"))
(set (subreg:DI (match_dup 3) 0)
(and:DI (subreg:DI (match_dup 3) 0) (match_dup 5)))
@@ -4278,11 +4293,15 @@
   (match_operand:DI 2 "const_int_operand")))
(set (subreg:DI (match_dup 4) 0)
(ior:DI (subreg:DI (match_dup 4) 0) (subreg:DI (match_dup 3) 0)))
-   (set (match_dup 0) (match_dup 4))]
+   (set (match_dup 0) (match_dup 4))
+   (set (match_dup 6)
+   (unspec:BLK [(match_dup 6)] UNSPEC_MEMORY_BLOCKAGE))]
   ""
 {
   operands[5] = GEN_INT (~ (GET_MODE_MASK (GET_MODE (operands[1]))
<< INTVAL (operands[2])));
+  operands[6] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
+  MEM_VOLATILE_P (operands[6]) = 1;
 })
 
 ;; For the unaligned byte and halfword cases, we use code similar to that
@@ -4293,7 +4312,9 @@
 ;; operand 2 can be that register.
 
 (define_expand "unaligned_store"
-  [(set (match_operand:DI 3 "register_operand")
+  [(set (match_dup 6)
+   (unspec:BLK [(match_dup 6)] UNSPEC_MEMORY_BLOCKAGE))
+   (set (match_operand:DI 3 "register_operand")
(mem:DI (and:DI (match_operand:DI 0 "address_operand")
(const_int -8
(set (match_operand:DI 2 "register_operand")
@@ -4308,9 +4329,15 @@
   (ashift:DI (match_dup 2) (const_int 3
(set (match_dup 4) (ior:DI (match_dup 4) (match_dup 3)))
(set (mem:DI (and:DI (match_dup 0) (const_int -8)))
-   (match_dup 4))]
+   (match_dup 4))
+   (set (match_dup 6)
+   (unspec:BLK [(match_dup 6)] UNSPEC_MEMORY_BLOCKAGE))]
   ""
-  "operan

Re: [Patch, PR 61061] Add state limit for regex NFA

[Tim Shen]

On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini
 wrote:
> The actual patch is missing.. ;)

Sigh...every time. Sorry.

> PS: sorry for being distracted by other issues: what happened to the other
> regex issue? I think we are simply going to apply, when ready, your more
> complete fix, right?

The problem given in the other PR (PR 61582) is also solved by this
patch (but I forgot to mention that); They are all examples like
nested range quantifiers.

PR 61424's patch is ready; I was waiting for some "Ok go ahead", but
now I realize that I need to send the complete patch first :) I'll
send it later.


-- 
Regards,
Tim Shen
commit 78a8e40d53f3083f5217b30908fda9442e0a92c5
Author: Tim Shen 
Date:   Thu Jun 26 20:35:33 2014 -0700

PR libstdc++/61061
PR libstdc++/61582
* include/bits/regex_automaton.h (_NFA<>::_M_insert_state): Add
a NFA state limit. If it's exceeded, regex_constants::error_space
will be throwed.
* include/bits/regex_automaton.tcc (_StateSeq<>::_M_clone): Use
map (which is sparse) instead of vector. This reduce n times clones'
cost from O(n^2) to O(n).
* include/std/regex: Add map dependency.
* testsuite/28_regex/algorithms/regex_match/ecma/char/61601.cc: New
testcase.

diff --git a/libstdc++-v3/include/bits/regex_automaton.h 
b/libstdc++-v3/include/bits/regex_automaton.h
index 1b0da14..27ec671 100644
--- a/libstdc++-v3/include/bits/regex_automaton.h
+++ b/libstdc++-v3/include/bits/regex_automaton.h
@@ -28,6 +28,11 @@
  *  Do not attempt to use it directly. @headername{regex}
  */
 
+// This macro defines the maximal state number a NFA can have.
+#ifndef _GLIBCXX_REGEX_STATE_LIMIT
+#define _GLIBCXX_REGEX_STATE_LIMIT 10
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 namespace __detail
@@ -254,6 +259,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _M_insert_state(_StateT __s)
   {
this->push_back(std::move(__s));
+   if (this->size() > _GLIBCXX_REGEX_STATE_LIMIT)
+ __throw_regex_error(regex_constants::error_space);
return this->size()-1;
   }
 
diff --git a/libstdc++-v3/include/bits/regex_automaton.tcc 
b/libstdc++-v3/include/bits/regex_automaton.tcc
index 1c6cfdd..08d271e 100644
--- a/libstdc++-v3/include/bits/regex_automaton.tcc
+++ b/libstdc++-v3/include/bits/regex_automaton.tcc
@@ -189,7 +189,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _StateSeq<_TraitsT>
 _StateSeq<_TraitsT>::_M_clone()
 {
-  std::vector<_StateIdT> __m(_M_nfa.size(), -1);
+  std::map<_StateIdT, _StateIdT> __m;
   std::stack<_StateIdT> __stack;
   __stack.push(_M_start);
   while (!__stack.empty())
@@ -203,21 +203,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  if (__dup._M_opcode == _S_opcode_alternative
  || __dup._M_opcode == _S_opcode_repeat
  || __dup._M_opcode == _S_opcode_subexpr_lookahead)
-   if (__dup._M_alt != _S_invalid_state_id && __m[__dup._M_alt] == -1)
+   if (__dup._M_alt != _S_invalid_state_id
+   && __m.count(__dup._M_alt) == 0)
  __stack.push(__dup._M_alt);
  if (__u == _M_end)
continue;
- if (__dup._M_next != _S_invalid_state_id && __m[__dup._M_next] == -1)
+ if (__dup._M_next != _S_invalid_state_id
+ && __m.count(__dup._M_next) == 0)
__stack.push(__dup._M_next);
}
-  for (auto __v : __m)
+  for (auto __it : __m)
{
- if (__v == -1)
-   continue;
+ auto __v = __it.second;
  auto& __ref = _M_nfa[__v];
  if (__ref._M_next != _S_invalid_state_id)
{
- _GLIBCXX_DEBUG_ASSERT(__m[__ref._M_next] != -1);
+ _GLIBCXX_DEBUG_ASSERT(__m.count(__ref._M_next) > 0);
  __ref._M_next = __m[__ref._M_next];
}
  if (__ref._M_opcode == _S_opcode_alternative
@@ -225,7 +226,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  || __ref._M_opcode == _S_opcode_subexpr_lookahead)
if (__ref._M_alt != _S_invalid_state_id)
  {
-   _GLIBCXX_DEBUG_ASSERT(__m[__ref._M_alt] != -1);
+   _GLIBCXX_DEBUG_ASSERT(__m.count(__ref._M_alt) > 0);
__ref._M_alt = __m[__ref._M_alt];
  }
}
diff --git a/libstdc++-v3/include/std/regex b/libstdc++-v3/include/std/regex
index 9161f48..470772af 100644
--- a/libstdc++-v3/include/std/regex
+++ b/libstdc++-v3/include/std/regex
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git 
a/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/61601.cc 
b/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/61601.cc
new file mode 100644
index 000..88efab5
--- /dev/null
+++ b/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/61601.cc
@@ -0,0 +1,48 @@
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2013-2014 Free Software Foundation, Inc.
+//

Re: [build, driver] RFC: Support compressed debug sections

[Eric Christopher]

On Thu, Jun 26, 2014 at 6:32 AM, Rainer Orth
 wrote:
> Eric Christopher  writes:
>
 If it is just to reach compatibility with the debugger, then I’d rather
 either just mandate a certain debugger or autoconf for what the current
 debugger supports.  As of late people seem to just break the debugging
 experience with non-updated gdbs and assume that a newer gdb is used.
>>>
>>> You cannot do that: unlike the assembler and linker used, which are
>>> often hardcoded into gcc, the debugger can easily be changed below the
>>> compiler's feet, so to speak.  Besides, on several platforms, you have
>>> more than one debugger available (like gdb and dbx, or others), so this
>>> isn't an option.  Apart from that, the debugging experience when
>>> e.g. emitting very recent DWARF extensions and trying to use them with a
>>> gdb that doesn't understand them usually leads to some debug info
>>> missing.  In this case, emitting compressed debug with a debugger that
>>> cannot read it leads to the debugger claiming (correctly, from its
>>> point of view) that there's no debugging info present.  I don't want to
>>> tell users who come complaining `I compiled with -g, but my debugger
>>> tells me there's no debug info present': `look, your debugger lies, it
>>> is present, but it cannot read it'.  That's a lot worse than the
>>> DWARF extensions scenario above.
>>
>> Agreed :)
>>
>> FWIW it's already a gas/assembler option, I'm curious about wanting to
>> expose it via the compiler?
>
> One reason: ease of use:
>
> * -gz is far easier to use/type than -Wa,--compress-debug-sections +
>   -Wl,--compress-debug-sections, and
>

Very true. Maybe make it a -gcompress-dwarf-sections?

> * one common option irrespective of assemblers (the Solaris assembler
>   will gain eventually gain compressed debug support, too) and linkers
>   used (Solaris ld requires -z compress-sections=), and even the
>   Apple assembler might at some point ;-)
>

The assembler itself does, but as far as I know none of the consumers
can deal with it. Right now it supports the same options as gas.

>>> On top of all that, compressed debug is a tradeoff: in some cases it may
>>> be worth it to save space on debug info if disk space is at a premium
>>> for some reason (e.g. for release builds), but in others you want to
>>> compile as fast as possible, but assembling and linking compressed debug
>>> takes more CPU time.  Otherwise we could just as well default to -Os,
>>> telling our users it's better for them since it generates faster and
>>> smaller code, not minding the compile time cost and worse debugging
>>> experience.
>>
>> FWIW I've found in some limited timing that compression is nearly
>> always worth it here at Google - even for compile time given the cost
>> of writing files versus cpu time. Might be worth making it a default
>> at some point in the future and making sure the option is invertible.
>
> One might be not so lucky with different/slower CPUs, though.  I wonder
> how this would affect bootstrap times on my current SPARC systems ;-(
>

I'd have thought you'd still largely be write bound for compilation. *shrug*

> But yes, a configure option to default -gz to on would certainly be
> helpful at some point.

*nod*

-eric

Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.

[Yufeng Zhang]

On 27 June 2014 16:32, Tejas Belagod  wrote:
>>>
>>> 2014-06-23  Tejas Belagod  
> diff --git a/gcc/config/aarch64/aarch64-simd-builtin-types.def
> b/gcc/config/aarch64/aarch64-simd-builtin-types.def
> new file mode 100644
> index 000..aa6a84e
> --- /dev/null
> +++ b/gcc/config/aarch64/aarch64-simd-builtin-types.def
> @@ -0,0 +1,50 @@
> +/* Builtin AdvSIMD types.
> +   Copyright (C) 2014 Free Software Foundation, Inc.
> +   Contributed by ARM Ltd.
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it
> +   under the terms of the GNU General Public License as published by
> +   the Free Software Foundation; either version 3, or (at your option)
> +   any later version.
> +
> +   GCC is distributed in the hope that it will be useful, but
> +   WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   General Public License for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with GCC; see the file COPYING3.  If not see
> +   .  */
> +
> +  ENTRY (Int8x8_t, V8QI, none, 10)
> +  ENTRY (Int8x16_t, V16QI, none, 11)
> +  ENTRY (Int16x4_t, V4HI, none, 11)
> +  ENTRY (Int16x8_t, V8HI, none, 11)
> +  ENTRY (Int32x2_t, V2SI, none, 11)
> +  ENTRY (Int32x4_t, V4SI, none, 11)
> +  ENTRY (Int64x1_t, DI, none, 11)
> +  ENTRY (Int64x2_t, V2DI, none, 11)
> +  ENTRY (Uint8x8_t, V8QI, unsigned, 11)
> +  ENTRY (Uint8x16_t, V16QI, unsigned, 12)
> +  ENTRY (Uint16x4_t, V4HI, unsigned, 12)
> +  ENTRY (Uint16x8_t, V8HI, unsigned, 12)
> +  ENTRY (Uint32x2_t, V2SI, unsigned, 12)
> +  ENTRY (Uint32x4_t, V4SI, unsigned, 12)
> +  ENTRY (Uint64x1_t, DI, unsigned, 12)
> +  ENTRY (Uint64x2_t, V2DI, unsigned, 12)
> +  ENTRY (Poly8_t, QI, poly, 9)
> +  ENTRY (Poly16_t, HI, poly, 10)
> +  ENTRY (Poly64_t, DI, poly, 10)
> +  ENTRY (Poly128_t, TI, poly, 11)
> +  ENTRY (Poly8x8_t, V8QI, poly, 11)
> +  ENTRY (Poly8x16_t, V16QI, poly, 12)
> +  ENTRY (Poly16x4_t, V4HI, poly, 12)
> +  ENTRY (Poly16x8_t, V8HI, poly, 12)
> +  ENTRY (Poly64x1_t, DI, poly, 12)
> +  ENTRY (Poly64x2_t, V2DI, poly, 12)
> +  ENTRY (Float32x2_t, V2SF, none, 13)
> +  ENTRY (Float32x4_t, V4SF, none, 13)
> +  ENTRY (Float64x1_t, DF, none, 13)

Will this revert Alan Lawrance's commit in 211892, which defines
Float64x1_t to have V1DF mode?

Thanks,
Yufeng

commit cffa849a621eb949bbdc4ce8468c932889450e6d
Author: alalaw01 
Date:   Mon Jun 23 12:46:52 2014 +

PR/60825 Make float64x1_t in arm_neon.h a proper vector type

Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

[Jeff Law]

On 06/27/14 05:56, Jakub Jelinek wrote:

On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:

I'm going to go for a single load/store and MOVE_MAX for now - I
have quite some fallout to deal with anyway (analyzed strlenopt-1.c
FAIL only, the other strlenopt cases are probably similar)

FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "strlen (" 2
FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "memcpy (" 4


But is it really desirable to do this kind of expansion so early on GIMPLE?
Doing it during folding is e.g. very much harmful to offloading, the
offloading target might have different preferences from the host.
So, if it is really beneficial (do you have some benchmark that shows
that?), can it be done e.g. in the strlen pass or even somewhat later?
You want to do it early enough in the pipeline to expose those to the 
bulk of the gimple optimizers.  My recollection was that was the biggest 
win for the customer case I looked at -- suddenly we can expose those 
objects to CSE, DSE & friends and lots of crud just starts to go away.


Jeff

Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)

[Jeff Law]

On 06/27/14 08:26, David Malcolm wrote:


Yeah, that's probably my primary concern here.  The patch kit is going
to be big (currently at 133 patches [1]), and so I want something that
we can sanely keep track of, that is easily reviewable, and will be as
easy as possible to merge.

i.e. I don't want to get bogged down in a big revamp of the rest of the
RTL interface if I can help it.
Precisely.  After revamping the objects at the toplevel of the insn 
chain, we can evaluate what project makes the most sense to tackle.




If it's desirable to actually make insns be a separate class, I'm
considering the goal of making the attributes of insns become actual
fields, something like:
I think having the toplevel objects in the insn chain as a separate 
class makes sense.  My biggest concerns are a variety of implementation 
details like is there code that wants to use the various rtl walkers on 
those toplevel objects.


Which (and I hate to say it) makes me wonder if this is a two step 
process.  First step is to have the subclass style implementation.  Then 
we look deeper at what would need to change to break those toplevel 
objects out into a distinct class.  In theory if we do things right, we 
leverage the new types and static checking to catch all the "don't 
assume the toplevel objects in the insn chain are rtxs" issues.


Two stage also gives others a chance to chime in if they're aware of 
good reasons not to make the change.




But even if we don't get there and simply keep insns as subclasses of
rtx, I think that having insn-handling code marked as such in the
type-system is a win from a readability standpoint.

Absolutely.



Hope these ideas sound sane

They do.  I think we're very much on the same page here.

Jeff

Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.

[Tejas Belagod]

2014-06-23  Tejas Belagod  

* config/aarch64/aarch64-builtins.c (aarch64_build_scalar_type):
Remove.
(aarch64_scalar_builtin_types, aarch64_simd_type,
aarch64_simd_types,
 aarch64_mangle_builtin_scalar_type,
aarch64_mangle_builtin_vector_type,
 aarch64_mangle_builtin_type, aarch64_simd_builtin_std_type,
 aarch64_lookup_simd_builtin_type, aarch64_simd_builtin_type,
 aarch64_init_simd_builtin_types,
 aarch64_init_simd_builtin_scalar_types): New.
(aarch64_init_simd_builtins): Refactor.
(aarch64_fold_builtin): Remove redundant defn.
(aarch64_init_crc32_builtins): Use aarch64_simd_builtin_std_type.
* config/aarch64/aarch64-simd-builtin-types.def: New.


Has the content of this new file been included in the patch?



Oops! Thanks for spotting that. Here is a new patch with the missing bit.

OK?

Thanks,
Tejas.diff --git a/gcc/config/aarch64/aarch64-builtins.c 
b/gcc/config/aarch64/aarch64-builtins.c
index a94ef52..1119f33 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -471,256 +471,331 @@ static GTY(()) tree 
aarch64_builtin_decls[AARCH64_BUILTIN_MAX];
 #define NUM_DREG_TYPES 6
 #define NUM_QREG_TYPES 6
 
-/* Return a tree for a signed or unsigned argument of either
-   the mode specified by MODE, or the inner mode of MODE.  */
-tree
-aarch64_build_scalar_type (enum machine_mode mode,
-  bool unsigned_p,
-  bool poly_p)
-{
-#undef INT_TYPES
-#define INT_TYPES \
-  AARCH64_TYPE_BUILDER (QI) \
-  AARCH64_TYPE_BUILDER (HI) \
-  AARCH64_TYPE_BUILDER (SI) \
-  AARCH64_TYPE_BUILDER (DI) \
-  AARCH64_TYPE_BUILDER (EI) \
-  AARCH64_TYPE_BUILDER (OI) \
-  AARCH64_TYPE_BUILDER (CI) \
-  AARCH64_TYPE_BUILDER (XI) \
-  AARCH64_TYPE_BUILDER (TI) \
-
-/* Statically declare all the possible types we might need.  */
-#undef AARCH64_TYPE_BUILDER
-#define AARCH64_TYPE_BUILDER(X) \
-  static tree X##_aarch64_type_node_p = NULL; \
-  static tree X##_aarch64_type_node_s = NULL; \
-  static tree X##_aarch64_type_node_u = NULL;
-
-  INT_TYPES
-
-  static tree float_aarch64_type_node = NULL;
-  static tree double_aarch64_type_node = NULL;
-
-  gcc_assert (!VECTOR_MODE_P (mode));
-
-/* If we've already initialised this type, don't initialise it again,
-   otherwise ask for a new type of the correct size.  */
-#undef AARCH64_TYPE_BUILDER
-#define AARCH64_TYPE_BUILDER(X) \
-  case X##mode: \
-if (unsigned_p) \
-  return (X##_aarch64_type_node_u \
- ? X##_aarch64_type_node_u \
- : X##_aarch64_type_node_u \
- = make_unsigned_type (GET_MODE_PRECISION (mode))); \
-else if (poly_p) \
-   return (X##_aarch64_type_node_p \
- ? X##_aarch64_type_node_p \
- : X##_aarch64_type_node_p \
- = make_unsigned_type (GET_MODE_PRECISION (mode))); \
-else \
-   return (X##_aarch64_type_node_s \
- ? X##_aarch64_type_node_s \
- : X##_aarch64_type_node_s \
- = make_signed_type (GET_MODE_PRECISION (mode))); \
-break;
+/* Internal scalar builtin types.  These types are used to support
+   neon intrinsic builtins.  They are _not_ user-visible types.  Therefore
+   the mangling for these types are implementation defined.  */
+const char *aarch64_scalar_builtin_types[] = {
+  "__builtin_aarch64_simd_qi",
+  "__builtin_aarch64_simd_hi",
+  "__builtin_aarch64_simd_si",
+  "__builtin_aarch64_simd_sf",
+  "__builtin_aarch64_simd_di",
+  "__builtin_aarch64_simd_df",
+  "__builtin_aarch64_simd_poly8",
+  "__builtin_aarch64_simd_poly16",
+  "__builtin_aarch64_simd_poly64",
+  "__builtin_aarch64_simd_poly128",
+  "__builtin_aarch64_simd_ti",
+  "__builtin_aarch64_simd_uqi",
+  "__builtin_aarch64_simd_uhi",
+  "__builtin_aarch64_simd_usi",
+  "__builtin_aarch64_simd_udi",
+  "__builtin_aarch64_simd_ei",
+  "__builtin_aarch64_simd_oi",
+  "__builtin_aarch64_simd_ci",
+  "__builtin_aarch64_simd_xi",
+  NULL
+};
 
-  switch (mode)
-{
-  INT_TYPES
-  case SFmode:
-   if (!float_aarch64_type_node)
- {
-   float_aarch64_type_node = make_node (REAL_TYPE);
-   TYPE_PRECISION (float_aarch64_type_node) = FLOAT_TYPE_SIZE;
-   layout_type (float_aarch64_type_node);
- }
-   return float_aarch64_type_node;
-   break;
-  case DFmode:
-   if (!double_aarch64_type_node)
- {
-   double_aarch64_type_node = make_node (REAL_TYPE);
-   TYPE_PRECISION (double_aarch64_type_node) = DOUBLE_TYPE_SIZE;
-   layout_type (double_aarch64_type_node);
- }
-   return double_aarch64_type_node;
-   break;
-  default:
-   gcc_unreachable ();
-}
-}
+#define ENTRY(E, M, Q, G) E,
+enum aarch64_simd_type
+{
+#include "aarch64-simd-builtin-types.def"
+};
+#undef ENTRY
 
-tree
-aarch64_build_vector_type (enum machine_mode mode,
-  boo

Re: [doc] Remove duplicate -Wmaybe-uninitialized

[Gerald Pfeifer]

On Mon, 23 Jun 2014, Jeff Law wrote:
>>  * doc/invoke.texi (Warning Options): Remove duplicated
>>  -Wmaybe-uninitialized.
> Probably falls under the obvious rule.  Regardless, this is OK.

It definitely does. :-)

Gerald

Re: Unreviewed build patch

[DJ Delorie]

>   https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html

Build parts are approved.

Ok to backport r210653 (fix for PR58930) to gcc-4_9-branch?

[Paul Pluzhnikov]

Greetings,

On Fri, Jun 27, 2014 at 2:18 AM, paolo.carlini at oracle dot com
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930
>
> --- Comment #6 from Paolo Carlini  ---
> The patch isn't trivial but I understand that it fixes quite a few issues. 
> Thus
> certainly no objections from me. Just ask on the mailing list: if Jason 
> agrees,
> please go ahead. Thanks.

Ok to backport r210653 (fix for PR58930) to gcc-4_9-branch?

(If not, I'll backport to google/gcc-4_9 instead.)

Thanks,
-- 
Paul Pluzhnikov

[wwwdocs] Convert remaining links to gcc.gnu.org/ml to https [3/3]

[Gerald Pfeifer]

And here are the last links into our mailing list archives.  Quite
a lot overall, across the three patches!

Installed.

Gerald

Index: benchmarks/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/benchmarks/index.html,v
retrieving revision 1.29
diff -u -r1.29 index.html
--- benchmarks/index.html   1 Nov 2012 18:17:35 -   1.29
+++ benchmarks/index.html   27 Jun 2014 14:48:56 -
@@ -90,7 +90,7 @@
 
 A memory tester (maintained by Jan Hubicka) is periodically checking GCC memory
 usage.  The reports are sent to the http://gcc.gnu.org/ml/gcc-regression/";>gcc-regressions mailing list
+href="https://gcc.gnu.org/ml/gcc-regression/";>gcc-regressions mailing list
 when some noticeable change is detected.   Dumps from the latest run and
 summaries are available at http://gcc.opensuse.org/memory/";>http://gcc.opensuse.org/memory/
Index: java/contrib.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/java/contrib.html,v
retrieving revision 1.36
diff -u -r1.36 contrib.html
--- java/contrib.html   25 Apr 2011 11:45:29 -  1.36
+++ java/contrib.html   27 Jun 2014 14:48:56 -
@@ -42,7 +42,7 @@
 
   Send libgcj patches to mailto:java-patc...@gcc.gnu.org";>java-patc...@gcc.gnu.org.
-  This list is http://gcc.gnu.org/ml/java-patches/";>archived.
+  This list is https://gcc.gnu.org/ml/java-patches/";>archived.
 
   Patches to the GCJ front end — the gcc/java
   directory — should be sent to the libgcj.jar.Note that newwer versions of 
   GCJ will reject the core class library if it wasn't 
-  http://gcc.gnu.org/ml/java/2001-03/msg00383.html";>generated
+  https://gcc.gnu.org/ml/java/2001-03/msg00383.html";>generated
   by GCJ itself.
 
   
Index: java/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/java/index.html,v
retrieving revision 1.176
diff -u -r1.176 index.html
--- java/index.html 1 Nov 2012 23:48:19 -   1.176
+++ java/index.html 27 Jun 2014 14:48:56 -
@@ -67,7 +67,7 @@
 September 11, 2006
 Joel Dice has
 http://gcc.gnu.org/ml/java/2006-09/msg00020.html";>announced https://gcc.gnu.org/ml/java/2006-09/msg00020.html";>announced http://ulibgcj.sourceforge.net/status.html";>micro-libgcj
 0.1, a lightweight version of libgcj intended to provide a usable
 subset of Java's features while remaining small and self-contained.
@@ -90,7 +90,7 @@
 
 May 20, 2006
 John David Anglin and Andreas Tobler checked in a http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01004.html";>patch
+href="https://gcc.gnu.org/ml/gcc-patches/2006-05/msg01004.html";>patch
 to enable libjava to be built by default on the HP-UX PA 32-bit platform.
 
 
@@ -102,7 +102,7 @@
 
 April 26, 2006
 Andrew Haley has merged in a http://gcc.gnu.org/ml/java-patches/2006-q2/msg00100.html";>patch
+href="https://gcc.gnu.org/ml/java-patches/2006-q2/msg00100.html";>patch
 that eliminates conservative scanning of static data and considerably speeds
 up garbage collection in many cases (for example, halving the time spent in
 garbage collection when running http://www.eclipse.org/";>Eclipse).
@@ -110,7 +110,7 @@
 
 April 17, 2006
 Tom Tromey has http://gcc.gnu.org/ml/java/2006-04/msg00046.html";>announced the
+href="https://gcc.gnu.org/ml/java/2006-04/msg00046.html";>announced the
 availability of two experimental Just-In-Time (JIT) interpreters for GCJ based
 on http://freecode.com/projects/libjit";>libjit and http://llvm.org/";>LLVM respectively. The source code for these
@@ -128,7 +128,7 @@
 
 March 15, 2006
 David Daney has merged in a http://gcc.gnu.org/ml/java-patches/2006-q1/msg00289.html";>patch that
+href="https://gcc.gnu.org/ml/java-patches/2006-q1/msg00289.html";>patch that
 adds the new -freduced-reflection option to GCJ. This option
 prevents GCJ from generating most of the reflection metadata for classes
 resulting in smaller binaries. There are some caveats to using this option 
Index: java/news.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/java/news.html,v
retrieving revision 1.15
diff -u -r1.15 news.html
--- java/news.html  29 Dec 2012 17:33:42 -  1.15
+++ java/news.html  27 Jun 2014 14:48:56 -
@@ -37,10 +37,10 @@
 
 July 15, 2005
 Tom Tromey has http://gcc.gnu.org/ml/java-patches/2005-q3/msg00093.html";>integrated
+href="https://gcc.gnu.org/ml/java-patches/2005-q3/msg00093.html";>integrated
 http://www.gnu.org/software/classpath/";>GNU Classpath into the
 GCJ build in such a way that it becomes http://gcc.gnu.org/ml/java/2005-05/msg00202.html";>much easier to
+href="https://gcc.gnu.org/ml/java/2005-05/msg00202.html";>much easier to
 import the latest GNU Classpath into GCJ. This particular import brings in GNU
 Classpath 0.17 (http://www.gnu.org/software/classpath/announce/20050715.html";>release
@@ -53,7 +53

Fix var-tracking ICE with COND_EXEC

[Joseph S. Myers]

With a 4.8-based compiler for ARM, I've observed an ICE in the
var-tracking.c:add_stores handling of COND_EXEC.  A large testcase
from building Qt can be found at
; a somewhat
reduced version (for the compiler with which I observed the problem)
is attached (to be built with -march=armv7-a -S -g -O2 -std=c++0x
-fno-exceptions -fPIE), but the issue seems very sensitive to details
of optimization and the test not really suitable for the testsuite.

The assertion

  gcc_assert (oval != v);

fails.  As I understand it, this is asserting that the conditional
store is not storing a value already present in the location in
question.  Now, it's not clear to me this should be relying on
optimizations like that.  In this case, the key peculiarity of the
code that may have caused the lack of optimization involves the
shared_null static const data member.  The destination of the problem
conditional store holds a value loaded from that member at some
point.  The source of that store was previously (conditionally, on the
same condition) stored into that constant location.  (Maybe in the
original code this store into a const location can't actually occur,
but that's the code being processed after inlining.)  So if you treat
that location as constant it follows that the two values are the same
(and that we have undefined behavior at runtime), while if you don't
then the values are clearly different (the store ends up being a
conditional increment).

This patch simply makes add_stores do nothing in this case of a
conditional store that does nothing.

Tested with no regressions for cross to arm-none-linux-gnueabi.  OK to
commit?

2014-06-27  Joseph Myers  

* var-tracking.c (add_stores): Return instead of asserting if old
and new values for conditional store are the same.

Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c  (revision 211889)
+++ gcc/var-tracking.c  (working copy)
@@ -6014,7 +6014,8 @@ add_stores (rtx loc, const_rtx expr, void *cuip)
 {
   cselib_val *oval = cselib_lookup (oloc, GET_MODE (oloc), 0, VOIDmode);
 
-  gcc_assert (oval != v);
+  if (oval == v)
+   return;
   gcc_assert (REG_P (oloc) || MEM_P (oloc));
 
   if (oval && !cselib_preserved_value_p (oval))

-- 
Joseph S. Myers
jos...@codesourcery.comtypedef unsigned int size_t;
namespace std
{
  typedef unsigned int size_t;
  template struct remove_reference
  {
typedef _Tp type;
  };
  template constexpr typename std::remove_reference<_Tp>::type&& 
move(_Tp&& __t) noexcept
  {
return static_cast::type&&>(__t);
  }
  template inline void swap(_Tp& __a, _Tp& __b)
  {
_Tp __tmp = std::move(__a);
__a = std::move(__b);
__b = std::move(__tmp);
  }
}
extern "C"
{
  inline void* operator new(std::size_t, void* __p) noexcept
  {
return __p;
  }
}
struct QA1
{
  static inline int load(const int &_q_value) noexcept
  {
return _q_value;
  }
  static bool aref(int &_q_value) noexcept
  {
return ++_q_value != 0;
  }
  static bool aderef(int &_q_value) noexcept
  {
return --_q_value != 0;
  }
};
class QB1
{
public:
  int _q_value;
  int baload() const noexcept
  {
return QA1::load(_q_value);
  }
  bool baref() noexcept
  {
return QA1::aref(_q_value);
  }
  bool baderef() noexcept
  {
return QA1::aderef(_q_value);
  }
};
class QR
{
public:
  inline bool ref() noexcept
  {
int count = qb.baload();
if (count == 0) return false;
if (count != -1) qb.baref();
return true;
  }
  inline bool deref() noexcept
  {
int count = qb.baload();
if (count == 0) return false;
if (count == -1) return true;
return qb.baderef();
  }
  bool isShared() const noexcept
  {
int count = qb.baload();
return (count != 1) && (count != 0);
  }
  QB1 qb;
};
extern "C"
{
  extern size_t strlen (const char *__s) throw ();
}
struct QArrayData
{
  QR ref;
  static void deallocate(QArrayData *data, size_t objectSize, size_t alignment);
  static const QArrayData shared_null[2];
  static QArrayData *sharedNull()
  {
return const_cast(shared_null);
  }
};
struct QTypedArrayData : QArrayData
{
  QArrayData header;
  static void deallocate(QArrayData *data)
  {
QArrayData::deallocate(data, sizeof(unsigned short), 4);
  }
  static QTypedArrayData *sharedNull()
  {
return static_cast(QArrayData::sharedNull());
  }
};
typedef QTypedArrayData QStringData;
class QString
{
public: typedef QStringData Data;
  inline QString();
  inline QString(const QString &);
  inline ~QString();
  inline QString &operator=(QString &&other)
  {
std::swap(d, other.d);
return *this;
  }
  static inline QString fromUtf8(const char *str, int size = -1)
  {
return fromUtf8_helper(str, size);
  }
  inline QString(const char *ch) : d(fromAscii_helper(ch, ch ? int(strlen(ch)) 
: -1))
  {
  }
  inline QString &operator=(const char *ch)
  {
return (*this = fromUt

Re: [PATCH] Fix undefined behavior in ira-build.c

[Vladimir Makarov]

On 2014-06-27, 3:16 AM, Jakub Jelinek wrote:

Hi!

This fixes the most common source of the new runtime diagnostics
during bootstrap-ubsan, if num is 0, ira_object_id_map is often
0 as well.

Ok for trunk/4.9?



Sure, Jakub.  You can use num > 1 as Richard pointed out.

Thanks.


2014-06-27  Jakub Jelinek  

* ira-build.c (sort_conflict_id_map): Don't call
qsort if num is 0, as ira_object_id_map might be NULL.

Convert links from gcc-*/ to gcc.gnu.org/ml to https [2/3]

[Gerald Pfeifer]

Installed.

(500k patch, attached in compress format.)

Gerald

patch.bz2
Description: application/bzip

Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)

[David Malcolm]

On Wed, 2014-06-25 at 10:36 +0100, Richard Sandiford wrote:
> Oleg Endo  writes:
> > Personally, I'd like to see usage of standard STL-like iterator usage.
> > I've proposed something for edge_iterator a while ago, but people don't
> > seem very fond of it.  See also
> > https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01129.html
> >
> > Have you also considered passing the new rtx_* types by value or
> > reference instead of pointer?  A long time ago I've quickly put together
> > a class 'rtxx' which was just a pointer wrapper for the rtx_def*
> > (basically the same as I proposed for edge_iterator).
> > I've converted the SH backend code to use it just to see what it would
> > look like.  The conversion itself was pretty straight forward -- just
> > replace 'rtx' with 'rtxx'.  Appropriate conversion
> > operators/constructors in 'class rtxx' made both interchangeable and
> > allowed co-existence of both and thus step-by-step conversion of the
> > code base.
> > Another advantage of passing around by value/ref is that it allows
> > operator overloading.  One use case could be instead of:
> >
> > if (MEM_P (XEXP (x, 0)))
> >   *total = address_cost (XEXP (XEXP (x, 0), 0),
> >  GET_MODE (XEXP (x, 0)),
> >  MEM_ADDR_SPACE (XEXP (x, 0)), true);
> >
> >
> > something like that (overloading operator[]):
> > if (x[0] == rtx_mem::type)
> >   *total = address_cost (x[0][0], x[0].mode (),
> >  x[0].mem_addr_space (), true);
> >
> > ... where rtx_mem::type would be some type for which 'rtxx' (or whatever
> > the name of the base class is) would provide the according operator
> > ==, != overloads.
> 
> I think this is an example of another problem with gcc coding style:
> that we're far too afraid of temporary variables.  In David's scheme
> I think this would be:
> 
>   if (rtx_mem *mem = as_a  (XEXP (x, 0)))
> *total = address_cost (XEXP (mem, 0), GET_MODE (mem),
>MEM_ADDR_SPACE (mem), true);

FWIW you want a dyn_cast<> rather than an as_a<> here, giving:

  if (rtx_mem *mem = dyn_cast  (XEXP (x, 0)))
*total = address_cost (XEXP (mem, 0), GET_MODE (mem),
   MEM_ADDR_SPACE (mem), true);

> which with members would become:
> 
>   if (rtx_mem *mem = as_a  (...))
> *total = address_cost (mem->address (), mem->mode (), mem->address_space 
> (),
>true);

(likewise)

> (although if we go down that route, I hope we can add an exception to the
> formatting rule so that no space should be used before "()".)
> 
> I suppose with the magic values it would be:
> 
>   if (rtx_mem mem = as_a  (x[0]))
> *total = address_cost (mem[0], mem.mode (), mem.address_space (), true);

(likewise).

> but I'm not sure that that would really be more readable.

[...snip...; see my other mail for notes on restricting the scope of the
current patch kit to an insn vs expr separation, for the sake of my
sanity :) ]

Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)

[David Malcolm]

On Wed, 2014-06-25 at 14:39 -0600, Jeff Law wrote:
> On 06/25/14 03:36, Richard Sandiford wrote:
> >
> > I think this is an example of another problem with gcc coding style:
> > that we're far too afraid of temporary variables.  In David's scheme
> > I think this would be:
> Historical coding style :(It's particularly bad in RTL land, but you 
> see the same problems in places like fold-const.
> 
> 
> >
> >if (rtx_mem *mem = as_a  (XEXP (x, 0)))
> >  *total = address_cost (XEXP (mem, 0), GET_MODE (mem),
> > MEM_ADDR_SPACE (mem), true);
> >
> > which with members would become:
> >
> >if (rtx_mem *mem = as_a  (...))
> >  *total = address_cost (mem->address (), mem->mode (), 
> > mem->address_space (),
> > true);
> >
> > (although if we go down that route, I hope we can add an exception to the
> > formatting rule so that no space should be used before "()".)
> There was some talk of revamping the rules of parens for member function 
> calls.  I don't recall what the final outcome was.
> 
> I prefer the latter, but I tend to worry about making David's patches 
> even more invasive than they already are :-)

:)

Yeah, that's probably my primary concern here.  The patch kit is going
to be big (currently at 133 patches [1]), and so I want something that
we can sanely keep track of, that is easily reviewable, and will be as
easy as possible to merge.

i.e. I don't want to get bogged down in a big revamp of the rest of the
RTL interface if I can help it.

I'm attempting to focus on splitting out insns from expressions.  As
mentioned before, in the v1 of this patch kit I also introduced rtx
subclasses for various core types like INSN_LIST, SEQUENCE, etc - but in
this iteration I'm attempting to do it without those - not yet sure if
it's possible.

If it's desirable to actually make insns be a separate class, I'm
considering the goal of making the attributes of insns become actual
fields, something like:

class rtx_insn /* we can bikeshed over the name */
{
public:
  rtx_insn *m_prev;
  rtx_insn *m_next;
  int m_uid;
};

#define PREV_INSN(INSN) ((INSN)->m_prev)
#define NEXT_INSN(INSN) ((INSN)->m_next)
#define INSN_UID(INSN)  ((INSN)->m_uid)
  /* or we could convert them to functions returning
 references, I guess */

...etc for the subclasses, giving something that gdb can print sanely,
and, I hope, more amenable to optimization when gcc itself is compiled.

But even if we don't get there and simply keep insns as subclasses of
rtx, I think that having insn-handling code marked as such in the
type-system is a win from a readability standpoint.

Either way, I think this should be much more "grokkable" by new
contributors.  My own experience is that RTL was the aspect of GCC I had
most difficulty with when I was a newbie - hence my motivation to "drain
this swamp".

Hope these ideas sound sane
Dave

[1] FWIW the latest version of the patches is here:
http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v9/
at 133 patches (as before it's relative to r211061).  I'm aiming for
lots of *small* patches.  Successful bootstrap and regrtest on x86_64;
builds on 187 configurations.  Perhaps the biggest change since last
time is that the "scaffolding" phase of the patches introduces a hack
into the generated inns-*.c so that the .md files see rtx_insn * rather
than plain rtx (for "insn" and "curr_insn"), which should allow lots of
target-specific hooks used from .md files to be similarly converted:
http://dmalcolm.fedorapeople.org/gcc/patch-backups/rtx-classes/v9/0036-Use-rtx_insn-internally-within-generated-functions.patch


> > I suppose with the magic values it would be:
> >
> >if (rtx_mem mem = as_a  (x[0]))
> >  *total = address_cost (mem[0], mem.mode (), mem.address_space (), 
> > true);
> >
> > but I'm not sure that that would really be more readable.
> Please, no...
> 
> 
> >
> > But like you say, I'm not sure whether it would really be a win in the end.
> > I think what makes this example so hard to read is again that we refuse
> > to put XEXP (x, 0) in a temporary variable and just write it out in full
> > 4 times instead.
> >
> >if ((GET_CODE (op0) == SMAX || GET_CODE (op0) == SMIN)
> >&& CONST_INT_P (XEXP (op0, 1))
> >&& REG_P (XEXP (op0, 0))
> >&& CONST_INT_P (op1))
> >
> > is a bit more obvious.
> And probably faster as well since we've CSE'd the memory reference.  In 
> this specific example it probably doesn't matter, but often there's a 
> call somewhere between XEXPs that we'd like to CSE that destroys our 
> ability to CSE away memory references.
> 
> This kind of problem is prevasive in the RTL analysis/optimizers.
> 

Re: [c++-concepts] Fix assertion failure with cp_maybe_constrained_type_specifier

[Ed Smith-Rowland]

On 06/26/2014 11:28 PM, Jason Merrill wrote:

On 06/26/2014 09:38 PM, Ed Smith-Rowland wrote:

So is C++14 a done deal with a __cplusplus date and all?


The C++14 draft was finalized at the February meeting in Issaquah; the 
ratification process isn't quite done, but I haven't heard any reason 
to doubt that it will be done soon.  The __cplusplus date is 201402L.
I guess we should set this correctly in libcpp/init.c or wherever. Do 
you see a problem with changing it from its current value of 201300?  We 
don't use the actual number AFAICT.  I guess we could also use a fake 
date for c++1z/c++17.  Say 201500?



I've been thinking of adding a thing or two to C++1z like clang has -
The Disabling trigraph expansion by default looks easy.


Aren't trigraphs off by default already?

They are *off* by default with gnu++NN and *on* by default with c++NN.  
We want them *off* by default for all (gnu|c)++(1z|17).  But -trigraphs 
will restore them for all versions.

Jason

Re: [PATCH] Remove bswap STRICT_ALING target limitation

[Rainer Orth]

Richard Biener  writes:

>>> 2014-06-27  Richard Biener  
>>>
>>> * tree-ssa-math-opts.c (bswap_replace): Fix
>>> SLOW_UNALIGNED_ACCESS test to only apply to unaligned object.
>>
>>This should fix PR bootstrap/61320.
>
> That would be odd.

It's almost exactly the workaround patch you've provided in that PR and
which I had to use ever since.  I just noticed because that didn't apply
anymore.  Currently running a bootstrap; we'll see how that goes.

Rainer

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

Re: [C++ Patch] PR 61614

[Jason Merrill]

OK.

Jason

Re: [PATCH] Remove bswap STRICT_ALING target limitation

[Richard Biener]

On June 27, 2014 2:50:33 PM CEST, Rainer Orth  
wrote:
>Richard Biener  writes:
>
>> The following patch enables bswap-from-load for STRICT_ALIGNMENT
>> targets when the load is aligned instead of unconditionally
>> (which probably was not intended).
>>
>> (note to self: we should fully transition to use
>SLOW_UNALIGNED_ACCESS)
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>>
>> Richard.
>>
>> 2014-06-27  Richard Biener  
>>
>>  * tree-ssa-math-opts.c (bswap_replace): Fix
>>  SLOW_UNALIGNED_ACCESS test to only apply to unaligned object.
>
>This should fix PR bootstrap/61320.

That would be odd.

Richard.

>   Rainer

Re: [PATCH, PR 61160] Artificial thunks need combined_args_to_skip

[Martin Jambor]

On Sat, May 31, 2014 at 01:08:31AM +0200, Martin Jambor wrote:
> Hi,
> 
> the second issue in PR 61160 is that because artificial thunks
> (produced by duplicate_thunk_for_node) do not have
> combined_args_to_skip, calls to them do not get actual arguments
> removed, while the actual functions do loose their formal parameters,
> leading to mismatches.
> 
> Currently, the combined_args_to_skip is computed in of
> cgraph_create_virtual_clone only after all the edge redirection and
> thunk duplication is done so it had to be moved to a spot before
> that.  Since we already pass args_to_skip to cgraph_clone_node, I
> moved the computation there (otherwise it would have to duplicate the
> old value and also pass the new one to the redirection routine).
> 
> I have also noticed that the code producing combined_args_to_skip from
> an old value and new args_to_skip cannot work in LTO because we do not
> have DECL_ARGUMENTS available at WPA in LTO.  The wrong code is
> however never executed and so I replaced it with a simple bitmap_ior.
> This changes the semantics of args_to_skip for any user of
> cgraph_create_virtual_clone that would like to remove some parameters
> from something which is already a clone.  However, currently there are
> no such users and the new semantics is saner because WPA code will be
> happier using the old indices rather than remapping everything the
> whole time.
> 
> I am still in the process of bootstrapping and testing this patch on
> trunk, I will test it on the 4.9 branch too.  OK if it passes
> everywhere?
> 

The patch has been approved by Honza on IRC.  Since then, a conflict
has occured on the trunk so I committed this variant after re-testing.

Thanks,

Martin


2014-06-27  Martin Jambor  

PR ipa/61160
* cgraphclones.c (duplicate_thunk_for_node): Removed parameter
args_to_skip, use those from node instead.  Copy args_to_skip and
combined_args_to_skip from node to the new thunk.
(redirect_edge_duplicating_thunks): Removed parameter args_to_skip.
(cgraph_create_virtual_clone): Moved computation of
combined_args_to_skip...
(cgraph_clone_node): ...here, simplify it to bitmap_ior..

testsuite/
* g++.dg/ipa/pr61160-2.C: New test.
* g++.dg/ipa/pr61160-3.C: Likewise.

diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index d57cd9f..2e7dc90 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -301,14 +301,13 @@ set_new_clone_decl_and_node_flags (cgraph_node *new_node)
thunk is this_adjusting but we are removing this parameter.  */
 
 static cgraph_node *
-duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node *node,
- bitmap args_to_skip)
+duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node *node)
 {
   cgraph_node *new_thunk, *thunk_of;
   thunk_of = cgraph_function_or_thunk_node (thunk->callees->callee);
 
   if (thunk_of->thunk.thunk_p)
-node = duplicate_thunk_for_node (thunk_of, node, args_to_skip);
+node = duplicate_thunk_for_node (thunk_of, node);
 
   struct cgraph_edge *cs;
   for (cs = node->callers; cs; cs = cs->next_caller)
@@ -320,17 +319,18 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node,
   return cs->caller;
 
   tree new_decl;
-  if (!args_to_skip)
+  if (!node->clone.args_to_skip)
 new_decl = copy_node (thunk->decl);
   else
 {
   /* We do not need to duplicate this_adjusting thunks if we have removed
 this.  */
   if (thunk->thunk.this_adjusting
- && bitmap_bit_p (args_to_skip, 0))
+ && bitmap_bit_p (node->clone.args_to_skip, 0))
return node;
 
-  new_decl = build_function_decl_skip_args (thunk->decl, args_to_skip,
+  new_decl = build_function_decl_skip_args (thunk->decl,
+   node->clone.args_to_skip,
false);
 }
   gcc_checking_assert (!DECL_STRUCT_FUNCTION (new_decl));
@@ -347,6 +347,8 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node,
   new_thunk->thunk = thunk->thunk;
   new_thunk->unique_name = in_lto_p;
   new_thunk->former_clone_of = thunk->decl;
+  new_thunk->clone.args_to_skip = node->clone.args_to_skip;
+  new_thunk->clone.combined_args_to_skip = node->clone.combined_args_to_skip;
 
   struct cgraph_edge *e = cgraph_create_edge (new_thunk, node, NULL, 0,
  CGRAPH_FREQ_BASE);
@@ -363,12 +365,11 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node,
chain.  */
 
 void
-redirect_edge_duplicating_thunks (struct cgraph_edge *e, struct cgraph_node *n,
- bitmap args_to_skip)
+redirect_edge_duplicating_thunks (struct cgraph_edge *e, struct cgraph_node *n)
 {
   cgraph_node *orig_to = cgraph_function_or_thunk_node (e->callee);
   if (orig_to->thunk.thunk_p)
-n = duplicate_thunk_for_node (orig_to, n, args_to_skip);
+n = duplicate_thunk_for_node

Re: [Patch ARM/testsuite 02/22] Add unary operators: vabs and vneg.

[Christophe Lyon]

On 27 June 2014 15:04, Christophe Lyon  wrote:
> On 27 June 2014 14:52, Ramana Radhakrishnan  wrote:
>> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
>>  wrote:
>>>
>>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc 
>>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
>>> new file mode 100644
>>> index 000..33f9b5f
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
>>> @@ -0,0 +1,72 @@
>>> +/* Template file for unary operator validation.
>>> +
>>> +   This file is meant to be included by the relevant test files, which
>>> +   have to define the intrinsic family to test. If a given intrinsic
>>> +   supports variants which are not supported by all the other unary
>>> +   operators, these can be tested by providing a definition for
>>> +   EXTRA_TESTS.  */
>>> +
>>> +#include 
>>> +#include "arm-neon-ref.h"
>>> +#include "compute-ref-data.h"
>>> +
>>> +#define FNNAME1(NAME) exec_ ## NAME
>>> +#define FNNAME(NAME) FNNAME1(NAME)
>>> +
>>> +void FNNAME (INSN_NAME) (void)
>>> +{
>>> +  /* Basic test: y=OP(x), then store the result.  */
>>> +#define TEST_UNARY_OP1(INSN, Q, T1, T2, W, N)  \
>>> +  VECT_VAR(vector_res, T1, W, N) = \
>>> +INSN##Q##_##T2##W(VECT_VAR(vector, T1, W, N)); \
>>> +  vst1##Q##_##T2##W(VECT_VAR(result, T1, W, N), VECT_VAR(vector_res, T1, 
>>> W, N))
>>> +
>>> +#define TEST_UNARY_OP(INSN, Q, T1, T2, W, N)   \
>>> +  TEST_UNARY_OP1(INSN, Q, T1, T2, W, N)
>>> \
>>> +
>>> +  /* No need for 64 bits variants in the general case.  */
>>> +  DECL_VARIABLE(vector, int, 8, 8);
>>> +  DECL_VARIABLE(vector, int, 16, 4);
>>> +  DECL_VARIABLE(vector, int, 32, 2);
>>> +  DECL_VARIABLE(vector, int, 8, 16);
>>> +  DECL_VARIABLE(vector, int, 16, 8);
>>> +  DECL_VARIABLE(vector, int, 32, 4);
>>> +
>>> +  DECL_VARIABLE(vector_res, int, 8, 8);
>>> +  DECL_VARIABLE(vector_res, int, 16, 4);
>>> +  DECL_VARIABLE(vector_res, int, 32, 2);
>>> +  DECL_VARIABLE(vector_res, int, 8, 16);
>>> +  DECL_VARIABLE(vector_res, int, 16, 8);
>>> +  DECL_VARIABLE(vector_res, int, 32, 4);
>>> +
>>> +  clean_results ();
>>> +
>>> +  /* Initialize input "vector" from "buffer".  */
>>> +  VLOAD(vector, buffer, , int, s, 8, 8);
>>> +  VLOAD(vector, buffer, , int, s, 16, 4);
>>> +  VLOAD(vector, buffer, , int, s, 32, 2);
>>> +  VLOAD(vector, buffer, q, int, s, 8, 16);
>>> +  VLOAD(vector, buffer, q, int, s, 16, 8);
>>> +  VLOAD(vector, buffer, q, int, s, 32, 4);
>>> +
>>> +  /* Apply a unary operator named INSN_NAME.  */
>>> +  TEST_UNARY_OP(INSN_NAME, , int, s, 8, 8);
>>> +  TEST_UNARY_OP(INSN_NAME, , int, s, 16, 4);
>>> +  TEST_UNARY_OP(INSN_NAME, , int, s, 32, 2);
>>> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 8, 16);
>>> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 16, 8);
>>> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 32, 4);
>>> +
>>> +  CHECK_RESULTS (TEST_MSG, "");
>>> +
>>> +#ifdef EXTRA_TESTS
>>> +  EXTRA_TESTS();
>>> +#endif
>>> +}
>>> +
>>> +int main (void)
>>> +{
>>> +  FNNAME (INSN_NAME)();
>>> +
>>> +  return 0;
>>> +}
>>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c 
>>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c
>>> new file mode 100644
>>> index 000..ca3901a
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c
>>> @@ -0,0 +1,74 @@
>>> +#define INSN_NAME vabs
>>> +#define TEST_MSG "VABS/VABSQ"
>>> +
>>> +/* Extra tests for functions requiring floating-point types.  */
>>> +void exec_vabs_f32(void);
>>> +#define EXTRA_TESTS exec_vabs_f32
>>> +
>>> +#include "unary_op.inc"
>>> +
>>> +/* Expected results.  */
>>> +VECT_VAR_DECL(expected,int,8,8) [] = { 0x10, 0xf, 0xe, 0xd,
>>> +  0xc, 0xb, 0xa, 0x9 };
>>> +VECT_VAR_DECL(expected,int,16,4) [] = { 0x10, 0xf, 0xe, 0xd };
>>> +VECT_VAR_DECL(expected,int,32,2) [] = { 0x10, 0xf };
>>> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x };
>>> +VECT_VAR_DECL(expected,uint,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
>>> +   0x33, 0x33, 0x33, 0x33 };
>>> +VECT_VAR_DECL(expected,uint,16,4) [] = { 0x, 0x, 0x, 0x };
>>> +VECT_VAR_DECL(expected,uint,32,2) [] = { 0x, 0x };
>>> +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x };
>>> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
>>> +   0x33, 0x33, 0x33, 0x33 };
>>> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x, 0x, 0x, 0x };
>>> +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x, 0x };
>>> +VECT_VAR_DECL(expected,int,8,16) [] = { 0x10, 0xf, 0xe, 0xd, 0xc, 0xb, 
>>> 0xa, 0x9,
>>> +   0x8, 0x7, 0x6, 0x5, 0x4, 0x3, 0x2, 
>>> 0x1 };
>>> +VECT_VAR_DECL(expected,int,16,8) [] = { 0x10, 0xf, 0xe, 0xd,
>>> +   0

Re: [Patch ARM/testsuite 03/22] Add binary operators: vadd, vand, vbic, veor, vorn, vorr, vsub.

[Christophe Lyon]

On 27 June 2014 14:55, Ramana Radhakrishnan  wrote:
> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
>  wrote:
>> vadd tests also show how to add directives to scan the assembly
>> output.
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc 
>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
>> new file mode 100644
>> index 000..3483e0e
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
>> @@ -0,0 +1,70 @@
>> +/* Template file for binary operator validation.
>> +
>> +   This file is meant to be included by the relevant test files, which
>> +   have to define the intrinsic family to test. If a given intrinsic
>> +   supports variants which are not supported by all the other binary
>> +   operators, these can be tested by providing a definition for
>> +   EXTRA_TESTS.  */
>> +
>> +#include 
>> +#include "arm-neon-ref.h"
>> +#include "compute-ref-data.h"
>> +
>> +#define FNNAME1(NAME) exec_ ## NAME
>> +#define FNNAME(NAME) FNNAME1(NAME)
>> +
>> +void FNNAME (INSN_NAME) (void)
>> +{
>> +  /* Basic test: y=OP(x1,x2), then store the result.  */
>> +#define TEST_BINARY_OP1(INSN, Q, T1, T2, W, N) \
>> +  VECT_VAR(vector_res, T1, W, N) = \
>> +INSN##Q##_##T2##W(VECT_VAR(vector, T1, W, N),  \
>> + VECT_VAR(vector2, T1, W, N)); \
>> +  vst1##Q##_##T2##W(VECT_VAR(result, T1, W, N), VECT_VAR(vector_res, T1, W, 
>> N))
>> +
>> +#define TEST_BINARY_OP(INSN, Q, T1, T2, W, N)  \
>> +  TEST_BINARY_OP1(INSN, Q, T1, T2, W, N)   \
>> +
>> +  DECL_VARIABLE_ALL_VARIANTS(vector);
>> +  DECL_VARIABLE_ALL_VARIANTS(vector2);
>> +  DECL_VARIABLE_ALL_VARIANTS(vector_res);
>> +
>> +  clean_results ();
>> +
>> +  /* Initialize input "vector" from "buffer".  */
>> +  TEST_MACRO_ALL_VARIANTS_2_5(VLOAD, vector, buffer);
>> +
>> +  /* Fill input vector2 with arbitrary values.  */
>> +  VDUP(vector2, , int, s, 8, 8, 2);
>> +  VDUP(vector2, , int, s, 16, 4, -4);
>> +  VDUP(vector2, , int, s, 32, 2, 3);
>> +  VDUP(vector2, , int, s, 64, 1, 100);
>> +  VDUP(vector2, , uint, u, 8, 8, 20);
>> +  VDUP(vector2, , uint, u, 16, 4, 30);
>> +  VDUP(vector2, , uint, u, 32, 2, 40);
>> +  VDUP(vector2, , uint, u, 64, 1, 2);
>> +  VDUP(vector2, q, int, s, 8, 16, -10);
>> +  VDUP(vector2, q, int, s, 16, 8, -20);
>> +  VDUP(vector2, q, int, s, 32, 4, -30);
>> +  VDUP(vector2, q, int, s, 64, 2, 24);
>> +  VDUP(vector2, q, uint, u, 8, 16, 12);
>> +  VDUP(vector2, q, uint, u, 16, 8, 3);
>> +  VDUP(vector2, q, uint, u, 32, 4, 55);
>> +  VDUP(vector2, q, uint, u, 64, 2, 3);
>> +
>> +  /* Apply a binary operator named INSN_NAME.  */
>> +  TEST_MACRO_ALL_VARIANTS_1_5(TEST_BINARY_OP, INSN_NAME);
>> +
>> +  CHECK_RESULTS (TEST_MSG, "");
>> +
>> +#ifdef EXTRA_TESTS
>> +  EXTRA_TESTS();
>> +#endif
>> +}
>> +
>> +int main (void)
>> +{
>> +  FNNAME (INSN_NAME) ();
>> +
>> +  return 0;
>> +}
>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/vadd.c 
>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vadd.c
>> new file mode 100644
>> index 000..64edc3f
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vadd.c
>> @@ -0,0 +1,109 @@
>> +#define INSN_NAME vadd
>> +#define TEST_MSG "VADD/VADDQ"
>> +
>> +/* Extra tests for functions requiring floating-point types.  */
>> +void exec_vadd_f32(void);
>> +#define EXTRA_TESTS exec_vadd_f32
>> +
>> +#include "binary_op.inc"
>> +
>> +/* Expected results.  */
>> +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf2, 0xf3, 0xf4, 0xf5,
>> +  0xf6, 0xf7, 0xf8, 0xf9 };
>> +VECT_VAR_DECL(expected,int,16,4) [] = { 0xffec, 0xffed, 0xffee, 0xffef };
>> +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfff3, 0xfff4 };
>> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x54 };
>> +VECT_VAR_DECL(expected,uint,8,8) [] = { 0x4, 0x5, 0x6, 0x7,
>> +   0x8, 0x9, 0xa, 0xb };
>> +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xe, 0xf, 0x10, 0x11 };
>> +VECT_VAR_DECL(expected,uint,32,2) [] = { 0x18, 0x19 };
>> +VECT_VAR_DECL(expected,uint,64,1) [] = { 0xfff2 };
>> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
>> +   0x33, 0x33, 0x33, 0x33 };
>> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x, 0x, 0x, 0x };
>> +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x, 0x };
>> +VECT_VAR_DECL(expected,int,8,16) [] = { 0xe6, 0xe7, 0xe8, 0xe9,
>> +   0xea, 0xeb, 0xec, 0xed,
>> +   0xee, 0xef, 0xf0, 0xf1,
>> +   0xf2, 0xf3, 0xf4, 0xf5 };
>> +VECT_VAR_DECL(expected,int,16,8) [] = { 0xffdc, 0xffdd, 0xffde, 0xffdf,
>> +   0xffe0, 0xffe1, 0xffe2, 0xffe3 };
>> +VECT_VAR_DECL(expected,int,32,4) [] = { 0x

Re: [Patch ARM/testsuite 02/22] Add unary operators: vabs and vneg.

[Christophe Lyon]

On 27 June 2014 14:52, Ramana Radhakrishnan  wrote:
> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
>  wrote:
>>
>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc 
>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
>> new file mode 100644
>> index 000..33f9b5f
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
>> @@ -0,0 +1,72 @@
>> +/* Template file for unary operator validation.
>> +
>> +   This file is meant to be included by the relevant test files, which
>> +   have to define the intrinsic family to test. If a given intrinsic
>> +   supports variants which are not supported by all the other unary
>> +   operators, these can be tested by providing a definition for
>> +   EXTRA_TESTS.  */
>> +
>> +#include 
>> +#include "arm-neon-ref.h"
>> +#include "compute-ref-data.h"
>> +
>> +#define FNNAME1(NAME) exec_ ## NAME
>> +#define FNNAME(NAME) FNNAME1(NAME)
>> +
>> +void FNNAME (INSN_NAME) (void)
>> +{
>> +  /* Basic test: y=OP(x), then store the result.  */
>> +#define TEST_UNARY_OP1(INSN, Q, T1, T2, W, N)  \
>> +  VECT_VAR(vector_res, T1, W, N) = \
>> +INSN##Q##_##T2##W(VECT_VAR(vector, T1, W, N)); \
>> +  vst1##Q##_##T2##W(VECT_VAR(result, T1, W, N), VECT_VAR(vector_res, T1, W, 
>> N))
>> +
>> +#define TEST_UNARY_OP(INSN, Q, T1, T2, W, N)   \
>> +  TEST_UNARY_OP1(INSN, Q, T1, T2, W, N) 
>>\
>> +
>> +  /* No need for 64 bits variants in the general case.  */
>> +  DECL_VARIABLE(vector, int, 8, 8);
>> +  DECL_VARIABLE(vector, int, 16, 4);
>> +  DECL_VARIABLE(vector, int, 32, 2);
>> +  DECL_VARIABLE(vector, int, 8, 16);
>> +  DECL_VARIABLE(vector, int, 16, 8);
>> +  DECL_VARIABLE(vector, int, 32, 4);
>> +
>> +  DECL_VARIABLE(vector_res, int, 8, 8);
>> +  DECL_VARIABLE(vector_res, int, 16, 4);
>> +  DECL_VARIABLE(vector_res, int, 32, 2);
>> +  DECL_VARIABLE(vector_res, int, 8, 16);
>> +  DECL_VARIABLE(vector_res, int, 16, 8);
>> +  DECL_VARIABLE(vector_res, int, 32, 4);
>> +
>> +  clean_results ();
>> +
>> +  /* Initialize input "vector" from "buffer".  */
>> +  VLOAD(vector, buffer, , int, s, 8, 8);
>> +  VLOAD(vector, buffer, , int, s, 16, 4);
>> +  VLOAD(vector, buffer, , int, s, 32, 2);
>> +  VLOAD(vector, buffer, q, int, s, 8, 16);
>> +  VLOAD(vector, buffer, q, int, s, 16, 8);
>> +  VLOAD(vector, buffer, q, int, s, 32, 4);
>> +
>> +  /* Apply a unary operator named INSN_NAME.  */
>> +  TEST_UNARY_OP(INSN_NAME, , int, s, 8, 8);
>> +  TEST_UNARY_OP(INSN_NAME, , int, s, 16, 4);
>> +  TEST_UNARY_OP(INSN_NAME, , int, s, 32, 2);
>> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 8, 16);
>> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 16, 8);
>> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 32, 4);
>> +
>> +  CHECK_RESULTS (TEST_MSG, "");
>> +
>> +#ifdef EXTRA_TESTS
>> +  EXTRA_TESTS();
>> +#endif
>> +}
>> +
>> +int main (void)
>> +{
>> +  FNNAME (INSN_NAME)();
>> +
>> +  return 0;
>> +}
>> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c 
>> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c
>> new file mode 100644
>> index 000..ca3901a
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c
>> @@ -0,0 +1,74 @@
>> +#define INSN_NAME vabs
>> +#define TEST_MSG "VABS/VABSQ"
>> +
>> +/* Extra tests for functions requiring floating-point types.  */
>> +void exec_vabs_f32(void);
>> +#define EXTRA_TESTS exec_vabs_f32
>> +
>> +#include "unary_op.inc"
>> +
>> +/* Expected results.  */
>> +VECT_VAR_DECL(expected,int,8,8) [] = { 0x10, 0xf, 0xe, 0xd,
>> +  0xc, 0xb, 0xa, 0x9 };
>> +VECT_VAR_DECL(expected,int,16,4) [] = { 0x10, 0xf, 0xe, 0xd };
>> +VECT_VAR_DECL(expected,int,32,2) [] = { 0x10, 0xf };
>> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x };
>> +VECT_VAR_DECL(expected,uint,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
>> +   0x33, 0x33, 0x33, 0x33 };
>> +VECT_VAR_DECL(expected,uint,16,4) [] = { 0x, 0x, 0x, 0x };
>> +VECT_VAR_DECL(expected,uint,32,2) [] = { 0x, 0x };
>> +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x };
>> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
>> +   0x33, 0x33, 0x33, 0x33 };
>> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x, 0x, 0x, 0x };
>> +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x, 0x };
>> +VECT_VAR_DECL(expected,int,8,16) [] = { 0x10, 0xf, 0xe, 0xd, 0xc, 0xb, 0xa, 
>> 0x9,
>> +   0x8, 0x7, 0x6, 0x5, 0x4, 0x3, 0x2, 
>> 0x1 };
>> +VECT_VAR_DECL(expected,int,16,8) [] = { 0x10, 0xf, 0xe, 0xd,
>> +   0xc, 0xb, 0xa, 0x9 };
>> +VECT_VAR_DECL(expected,int,32,4) [] = { 0x10, 0xf, 0xe, 0xd };
>> +VECT_VAR_DECL(expected,int,64,2) [] = { 0x,
>> +  

Re: [build, driver] RFC: Support compressed debug sections

[Paolo Bonzini]

Il 26/06/2014 15:16, Rainer Orth ha scritto:

Hi Gerald,

sorry for the delay, I've been away for a couple of days.


On Tue, 3 Jun 2014, Rainer Orth wrote:

It's been another week, and I still need approval for the build, doc,
and Darwin changes:

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html


On the doc side, things are fine.

Just a suggestion or two:

+Produce compressed debug sections in DWARF format, if that is supported.

Supported by what?


By the toolchain used.  TBH, I just copied that fragment from various
other debug options (-gstabs, -gcoff, -gdwarf-N).  Given the precedent
and the verbosity of a more detailed explanation, I'd leave this as is.


"doesn't" -> "does not", especially given the emphasis we want to make
here.


Good point, fixed.


And could the "If the linker doesn't support writing compressed debug
sections, the option is rejected.  Otherwise, if the assembler doesn't
support them, @option{-gz} is silently ignored when producing object
files." be moved to the very end, or is this only applicable to the
case where no type has been specified?


No, you're right: it's better to first explain the values for type in
the working case, then explain potential error scenarios.

The section now reads

@item -gz@r{[}=@var{type}@r{]}
@opindex gz
Produce compressed debug sections in DWARF format, if that is supported.
If @var{type} is not given, the default type depends on the capabilities
of the assembler and linker used.  @var{type} may be one of
@option{none} (don't compress debug sections), @option{zlib} (use zlib
compression in ELF gABI format), or @option{zlib-gnu} (use zlib
compression in traditional GNU format).  If the linker doesn't support
writing compressed debug sections, the option is rejected.  Otherwise,
if the assembler does not support them, @option{-gz} is silently ignored
when producing object files.

Thanks for your comments.

I'm still missing review of the build parts after three weeks and
several reminders, though.  Paolo, Nathanael, Alexandre, could one of
you please have a look?


Build changes are good, thanks.

Paolo

Re: [Patch ARM/testsuite 03/22] Add binary operators: vadd, vand, vbic, veor, vorn, vorr, vsub.

[Ramana Radhakrishnan]

On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
 wrote:
> vadd tests also show how to add directives to scan the assembly
> output.
>
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc 
> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
> new file mode 100644
> index 000..3483e0e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
> @@ -0,0 +1,70 @@
> +/* Template file for binary operator validation.
> +
> +   This file is meant to be included by the relevant test files, which
> +   have to define the intrinsic family to test. If a given intrinsic
> +   supports variants which are not supported by all the other binary
> +   operators, these can be tested by providing a definition for
> +   EXTRA_TESTS.  */
> +
> +#include 
> +#include "arm-neon-ref.h"
> +#include "compute-ref-data.h"
> +
> +#define FNNAME1(NAME) exec_ ## NAME
> +#define FNNAME(NAME) FNNAME1(NAME)
> +
> +void FNNAME (INSN_NAME) (void)
> +{
> +  /* Basic test: y=OP(x1,x2), then store the result.  */
> +#define TEST_BINARY_OP1(INSN, Q, T1, T2, W, N) \
> +  VECT_VAR(vector_res, T1, W, N) = \
> +INSN##Q##_##T2##W(VECT_VAR(vector, T1, W, N),  \
> + VECT_VAR(vector2, T1, W, N)); \
> +  vst1##Q##_##T2##W(VECT_VAR(result, T1, W, N), VECT_VAR(vector_res, T1, W, 
> N))
> +
> +#define TEST_BINARY_OP(INSN, Q, T1, T2, W, N)  \
> +  TEST_BINARY_OP1(INSN, Q, T1, T2, W, N)   \
> +
> +  DECL_VARIABLE_ALL_VARIANTS(vector);
> +  DECL_VARIABLE_ALL_VARIANTS(vector2);
> +  DECL_VARIABLE_ALL_VARIANTS(vector_res);
> +
> +  clean_results ();
> +
> +  /* Initialize input "vector" from "buffer".  */
> +  TEST_MACRO_ALL_VARIANTS_2_5(VLOAD, vector, buffer);
> +
> +  /* Fill input vector2 with arbitrary values.  */
> +  VDUP(vector2, , int, s, 8, 8, 2);
> +  VDUP(vector2, , int, s, 16, 4, -4);
> +  VDUP(vector2, , int, s, 32, 2, 3);
> +  VDUP(vector2, , int, s, 64, 1, 100);
> +  VDUP(vector2, , uint, u, 8, 8, 20);
> +  VDUP(vector2, , uint, u, 16, 4, 30);
> +  VDUP(vector2, , uint, u, 32, 2, 40);
> +  VDUP(vector2, , uint, u, 64, 1, 2);
> +  VDUP(vector2, q, int, s, 8, 16, -10);
> +  VDUP(vector2, q, int, s, 16, 8, -20);
> +  VDUP(vector2, q, int, s, 32, 4, -30);
> +  VDUP(vector2, q, int, s, 64, 2, 24);
> +  VDUP(vector2, q, uint, u, 8, 16, 12);
> +  VDUP(vector2, q, uint, u, 16, 8, 3);
> +  VDUP(vector2, q, uint, u, 32, 4, 55);
> +  VDUP(vector2, q, uint, u, 64, 2, 3);
> +
> +  /* Apply a binary operator named INSN_NAME.  */
> +  TEST_MACRO_ALL_VARIANTS_1_5(TEST_BINARY_OP, INSN_NAME);
> +
> +  CHECK_RESULTS (TEST_MSG, "");
> +
> +#ifdef EXTRA_TESTS
> +  EXTRA_TESTS();
> +#endif
> +}
> +
> +int main (void)
> +{
> +  FNNAME (INSN_NAME) ();
> +
> +  return 0;
> +}
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/vadd.c 
> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vadd.c
> new file mode 100644
> index 000..64edc3f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vadd.c
> @@ -0,0 +1,109 @@
> +#define INSN_NAME vadd
> +#define TEST_MSG "VADD/VADDQ"
> +
> +/* Extra tests for functions requiring floating-point types.  */
> +void exec_vadd_f32(void);
> +#define EXTRA_TESTS exec_vadd_f32
> +
> +#include "binary_op.inc"
> +
> +/* Expected results.  */
> +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf2, 0xf3, 0xf4, 0xf5,
> +  0xf6, 0xf7, 0xf8, 0xf9 };
> +VECT_VAR_DECL(expected,int,16,4) [] = { 0xffec, 0xffed, 0xffee, 0xffef };
> +VECT_VAR_DECL(expected,int,32,2) [] = { 0xfff3, 0xfff4 };
> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x54 };
> +VECT_VAR_DECL(expected,uint,8,8) [] = { 0x4, 0x5, 0x6, 0x7,
> +   0x8, 0x9, 0xa, 0xb };
> +VECT_VAR_DECL(expected,uint,16,4) [] = { 0xe, 0xf, 0x10, 0x11 };
> +VECT_VAR_DECL(expected,uint,32,2) [] = { 0x18, 0x19 };
> +VECT_VAR_DECL(expected,uint,64,1) [] = { 0xfff2 };
> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
> +   0x33, 0x33, 0x33, 0x33 };
> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x, 0x, 0x, 0x };
> +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x, 0x };
> +VECT_VAR_DECL(expected,int,8,16) [] = { 0xe6, 0xe7, 0xe8, 0xe9,
> +   0xea, 0xeb, 0xec, 0xed,
> +   0xee, 0xef, 0xf0, 0xf1,
> +   0xf2, 0xf3, 0xf4, 0xf5 };
> +VECT_VAR_DECL(expected,int,16,8) [] = { 0xffdc, 0xffdd, 0xffde, 0xffdf,
> +   0xffe0, 0xffe1, 0xffe2, 0xffe3 };
> +VECT_VAR_DECL(expected,int,32,4) [] = { 0xffd2, 0xffd3,
> +   0xffd4, 0xffd5 };
> +VECT_VAR_DECL(expected,int,64,2) [] = { 0x8, 0x9 };
> +VECT_VAR_DECL(expected,uint,8,1

Re: [Patch ARM/testsuite 02/22] Add unary operators: vabs and vneg.

[Ramana Radhakrishnan]

On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
 wrote:
>
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc 
> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
> new file mode 100644
> index 000..33f9b5f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
> @@ -0,0 +1,72 @@
> +/* Template file for unary operator validation.
> +
> +   This file is meant to be included by the relevant test files, which
> +   have to define the intrinsic family to test. If a given intrinsic
> +   supports variants which are not supported by all the other unary
> +   operators, these can be tested by providing a definition for
> +   EXTRA_TESTS.  */
> +
> +#include 
> +#include "arm-neon-ref.h"
> +#include "compute-ref-data.h"
> +
> +#define FNNAME1(NAME) exec_ ## NAME
> +#define FNNAME(NAME) FNNAME1(NAME)
> +
> +void FNNAME (INSN_NAME) (void)
> +{
> +  /* Basic test: y=OP(x), then store the result.  */
> +#define TEST_UNARY_OP1(INSN, Q, T1, T2, W, N)  \
> +  VECT_VAR(vector_res, T1, W, N) = \
> +INSN##Q##_##T2##W(VECT_VAR(vector, T1, W, N)); \
> +  vst1##Q##_##T2##W(VECT_VAR(result, T1, W, N), VECT_VAR(vector_res, T1, W, 
> N))
> +
> +#define TEST_UNARY_OP(INSN, Q, T1, T2, W, N)   \
> +  TEST_UNARY_OP1(INSN, Q, T1, T2, W, N)  
>   \
> +
> +  /* No need for 64 bits variants in the general case.  */
> +  DECL_VARIABLE(vector, int, 8, 8);
> +  DECL_VARIABLE(vector, int, 16, 4);
> +  DECL_VARIABLE(vector, int, 32, 2);
> +  DECL_VARIABLE(vector, int, 8, 16);
> +  DECL_VARIABLE(vector, int, 16, 8);
> +  DECL_VARIABLE(vector, int, 32, 4);
> +
> +  DECL_VARIABLE(vector_res, int, 8, 8);
> +  DECL_VARIABLE(vector_res, int, 16, 4);
> +  DECL_VARIABLE(vector_res, int, 32, 2);
> +  DECL_VARIABLE(vector_res, int, 8, 16);
> +  DECL_VARIABLE(vector_res, int, 16, 8);
> +  DECL_VARIABLE(vector_res, int, 32, 4);
> +
> +  clean_results ();
> +
> +  /* Initialize input "vector" from "buffer".  */
> +  VLOAD(vector, buffer, , int, s, 8, 8);
> +  VLOAD(vector, buffer, , int, s, 16, 4);
> +  VLOAD(vector, buffer, , int, s, 32, 2);
> +  VLOAD(vector, buffer, q, int, s, 8, 16);
> +  VLOAD(vector, buffer, q, int, s, 16, 8);
> +  VLOAD(vector, buffer, q, int, s, 32, 4);
> +
> +  /* Apply a unary operator named INSN_NAME.  */
> +  TEST_UNARY_OP(INSN_NAME, , int, s, 8, 8);
> +  TEST_UNARY_OP(INSN_NAME, , int, s, 16, 4);
> +  TEST_UNARY_OP(INSN_NAME, , int, s, 32, 2);
> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 8, 16);
> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 16, 8);
> +  TEST_UNARY_OP(INSN_NAME, q, int, s, 32, 4);
> +
> +  CHECK_RESULTS (TEST_MSG, "");
> +
> +#ifdef EXTRA_TESTS
> +  EXTRA_TESTS();
> +#endif
> +}
> +
> +int main (void)
> +{
> +  FNNAME (INSN_NAME)();
> +
> +  return 0;
> +}
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c 
> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c
> new file mode 100644
> index 000..ca3901a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/vabs.c
> @@ -0,0 +1,74 @@
> +#define INSN_NAME vabs
> +#define TEST_MSG "VABS/VABSQ"
> +
> +/* Extra tests for functions requiring floating-point types.  */
> +void exec_vabs_f32(void);
> +#define EXTRA_TESTS exec_vabs_f32
> +
> +#include "unary_op.inc"
> +
> +/* Expected results.  */
> +VECT_VAR_DECL(expected,int,8,8) [] = { 0x10, 0xf, 0xe, 0xd,
> +  0xc, 0xb, 0xa, 0x9 };
> +VECT_VAR_DECL(expected,int,16,4) [] = { 0x10, 0xf, 0xe, 0xd };
> +VECT_VAR_DECL(expected,int,32,2) [] = { 0x10, 0xf };
> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x };
> +VECT_VAR_DECL(expected,uint,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
> +   0x33, 0x33, 0x33, 0x33 };
> +VECT_VAR_DECL(expected,uint,16,4) [] = { 0x, 0x, 0x, 0x };
> +VECT_VAR_DECL(expected,uint,32,2) [] = { 0x, 0x };
> +VECT_VAR_DECL(expected,uint,64,1) [] = { 0x };
> +VECT_VAR_DECL(expected,poly,8,8) [] = { 0x33, 0x33, 0x33, 0x33,
> +   0x33, 0x33, 0x33, 0x33 };
> +VECT_VAR_DECL(expected,poly,16,4) [] = { 0x, 0x, 0x, 0x };
> +VECT_VAR_DECL(expected,hfloat,32,2) [] = { 0x, 0x };
> +VECT_VAR_DECL(expected,int,8,16) [] = { 0x10, 0xf, 0xe, 0xd, 0xc, 0xb, 0xa, 
> 0x9,
> +   0x8, 0x7, 0x6, 0x5, 0x4, 0x3, 0x2, 
> 0x1 };
> +VECT_VAR_DECL(expected,int,16,8) [] = { 0x10, 0xf, 0xe, 0xd,
> +   0xc, 0xb, 0xa, 0x9 };
> +VECT_VAR_DECL(expected,int,32,4) [] = { 0x10, 0xf, 0xe, 0xd };
> +VECT_VAR_DECL(expected,int,64,2) [] = { 0x,
> +   0x };
> +VECT_VAR_DECL(expected,uint,8,16) [] = { 0x33, 0x33, 0x33, 0x33,
> +0x33, 0x33, 0x33, 0x

Re: [PATCH] Remove bswap STRICT_ALING target limitation

[Rainer Orth]

Richard Biener  writes:

> The following patch enables bswap-from-load for STRICT_ALIGNMENT
> targets when the load is aligned instead of unconditionally
> (which probably was not intended).
>
> (note to self: we should fully transition to use SLOW_UNALIGNED_ACCESS)
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Richard.
>
> 2014-06-27  Richard Biener  
>
>   * tree-ssa-math-opts.c (bswap_replace): Fix
>   SLOW_UNALIGNED_ACCESS test to only apply to unaligned object.

This should fix PR bootstrap/61320.

Rainer

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

Unreviewed build patch

[Rainer Orth]

The following patch

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01860.html

has been submitted more than a month ago, and everything but the build
parts has been approved.

Unfortunately, the build parts still need review, despite several
reminders.  I'd be really greatful if one of the build maintainers could
have a look.

Thanks.
Rainer

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

[wwwdocs] Convert links to gcc.gnu.org/ml to https [1/3]

[Gerald Pfeifer]

Installed.

Gerald

Index: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.49
diff -u -r1.49 backends.html
--- backends.html   9 May 2014 16:26:37 -   1.49
+++ backends.html   27 Jun 2014 11:17:05 -
@@ -111,8 +111,8 @@
 
 
 For AVR simulator, see http://gcc.gnu.org/ml/gcc/2003-10/msg00027.html";>
-http://gcc.gnu.org/ml/gcc/2003-10/msg00027.html.
+href="https://gcc.gnu.org/ml/gcc/2003-10/msg00027.html";>
+https://gcc.gnu.org/ml/gcc/2003-10/msg00027.html.
 
 * SPU's float is special; it has the same format as IEEE float but has
 an extended range and no infinity or NaNs. SPU's float will not produce
Index: codingconventions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.69
diff -u -r1.69 codingconventions.html
--- codingconventions.html  30 Sep 2013 20:40:29 -  1.69
+++ codingconventions.html  27 Jun 2014 11:17:06 -
@@ -129,8 +129,8 @@
 
 There is no established convention on when ChangeLog entries are to
 be made for testsuite changes; see messages http://gcc.gnu.org/ml/gcc/2000-09/msg00287.html";>1 and http://gcc.gnu.org/ml/gcc/2000-09/msg00290.html";>2.
+href="https://gcc.gnu.org/ml/gcc/2000-09/msg00287.html";>1 and https://gcc.gnu.org/ml/gcc/2000-09/msg00290.html";>2.
 
 If your change fixes a PR, put PR java/58 (where
 java/58 is the actual number of the PR) at the top
@@ -180,8 +180,8 @@
 strrchr are preferred to the old functions
 bcmp, bcopy, bzero,
 index and rindex; see messages http://gcc.gnu.org/ml/gcc/1998-09/msg01000.html";>1 and http://gcc.gnu.org/ml/gcc/1998-09/msg01127.html";>2.  The
+href="https://gcc.gnu.org/ml/gcc/1998-09/msg01000.html";>1 and https://gcc.gnu.org/ml/gcc/1998-09/msg01127.html";>2.  The
 older functions must no longer be used in GCC; apart from
 index, these identifiers are poisoned to prevent their
 use.
@@ -225,7 +225,7 @@
 their origin: the people who added them or submitted the bug report
 they relate to, possibly with a reference to a PR in our bug tracking
 system.  There are http://gcc.gnu.org/ml/gcc/2000-01/msg00593.html";>some copyright
+href="https://gcc.gnu.org/ml/gcc/2000-01/msg00593.html";>some copyright
 guidelines on what can be included in the testsuite.
 
 If a testcase itself is incorrect, but there's a possibility that an
@@ -713,7 +713,7 @@
 Testing for ERROR_MARKs should be done by comparing
 against error_mark_node rather than by comparing the
 TREE_CODE against ERROR_MARK; see http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00792.html";>message.
+href="https://gcc.gnu.org/ml/gcc-patches/2000-10/msg00792.html";>message.
 
 
 Parameters Affecting Generated Code
@@ -750,8 +750,8 @@
 where the macro is a wrapper for efficiency
 that should be considered as a function;
 see messages
-http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00901.html";>1
-and http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00912.html";>2.
+https://gcc.gnu.org/ml/gcc-patches/2000-09/msg00901.html";>1
+and https://gcc.gnu.org/ml/gcc-patches/2000-09/msg00912.html";>2.
 
 
 
Index: contributewhy.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/contributewhy.html,v
retrieving revision 1.7
diff -u -r1.7 contributewhy.html
--- contributewhy.html  21 Sep 2006 14:17:36 -  1.7
+++ contributewhy.html  27 Jun 2014 11:17:07 -
@@ -131,7 +131,7 @@
 
 Finally, please note that GPL-covered code may not be
 distributed under an NDA,
-http://gcc.gnu.org/ml/gcc/2001-07/msg01342.html";>as explained
+https://gcc.gnu.org/ml/gcc/2001-07/msg01342.html";>as explained
 by Richard Stallman.
 
 
Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revision 1.107
diff -u -r1.107 lists.html
--- lists.html  3 Dec 2013 01:04:41 -   1.107
+++ lists.html  27 Jun 2014 11:17:08 -
@@ -22,11 +22,11 @@
 Announcement lists:
 
 
-  http://gcc.gnu.org/ml/gcc-announce/";>gcc-announce
+  https://gcc.gnu.org/ml/gcc-announce/";>gcc-announce
   is a read-only low volume list where
   we post announcements about releases or other important events.
 
-  http://gcc.gnu.org/ml/java-announce/";>java-announce
+  https://gcc.gnu.org/ml/java-announce/";>java-announce
   is a low-volume, moderated, announcements-only list.  Only announcements
   related to the Java language front end or runtime library are posted
   here.
@@ -35,11 +35,11 @@
 Open lists:
 
 
-  http://gcc.gnu.org/ml/gcc-help/";>gcc-help
+  https://gcc.gnu.org/ml/gcc-help/";>gcc-help
   is a relatively high volume list for people searching for help in
   building or using GCC.
 
-  http://gcc.gnu.org/ml/gcc/";>gcc
+  https://gcc.gnu.org/ml/gcc/";>gcc
   is a high volume list for general development discussions about GCC.
   Anything relevant to the development or

Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

[Richard Biener]

On Fri, 27 Jun 2014, Jakub Jelinek wrote:

> On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:
> > I'm going to go for a single load/store and MOVE_MAX for now - I
> > have quite some fallout to deal with anyway (analyzed strlenopt-1.c
> > FAIL only, the other strlenopt cases are probably similar)
> > 
> > FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "strlen (" 2
> > FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "memcpy (" 4
> 
> But is it really desirable to do this kind of expansion so early on GIMPLE?
> Doing it during folding is e.g. very much harmful to offloading, the
> offloading target might have different preferences from the host.
> So, if it is really beneficial (do you have some benchmark that shows
> that?), can it be done e.g. in the strlen pass or even somewhat later?

strlen pass now runs very very late, for PR61619 it is important
before some constant propagation happening before vectorization.

But yes, it's not necessary doing that on GENERIC (nor is any of
those foldings - but as said, it's not the objective of the patch
to change where we do such optimizations).

Oh, and offloading targets always will have the issue facing
IL optimized for another target (LOGICAL_OP_NON_SHORT_CIRCUIT
for example).

Richard.

Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

[Jakub Jelinek]

On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:
> I'm going to go for a single load/store and MOVE_MAX for now - I
> have quite some fallout to deal with anyway (analyzed strlenopt-1.c
> FAIL only, the other strlenopt cases are probably similar)
> 
> FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "strlen (" 2
> FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "memcpy (" 4

But is it really desirable to do this kind of expansion so early on GIMPLE?
Doing it during folding is e.g. very much harmful to offloading, the
offloading target might have different preferences from the host.
So, if it is really beneficial (do you have some benchmark that shows
that?), can it be done e.g. in the strlen pass or even somewhat later?

Jakub

Re: [PATCH][RFC] Fix PR61473, inline small memcpy/memmove during tree opts

[Richard Biener]

On Thu, 12 Jun 2014, Jeff Law wrote:

> On 06/12/14 04:12, Richard Biener wrote:
> > 
> > This implements the requested inlining of memmove for possibly
> > overlapping arguments by doing first all loads and then all stores.
> > The easiest place is to do this in memory op folding where we already
> > perform inlining of some memcpy cases (but fail to do the equivalent
> > memcpy optimization - though RTL expansion later does it).
> > 
> > The following patch restricts us to max. word-mode size.  Ideally
> > we'd have a way to check for the number of real instructions needed
> > to load an (aligned) value of size N.  But maybe we don't care
> > and are fine with doing multiple loads / stores?
> > 
> > Anyway, the following is conservative (but maybe not enough).
> > 
> > Bootstrap / regtest running on x86_64-unknown-linux-gnu.
> > 
> > These transforms don't really belong to GENERIC folding (they
> > also run at -O0 ...), similar to most builtin foldings.  But this
> > patch is not to change that.
> > 
> > Any comments on the size/cost issue?
> I recall seeing something in one of the BZ databases that asked for 
> double-word to be expanded inline.  Presumably the reporter's code did 
> lots of double-word things of this nature.
> 
> Obviously someone else might want quad-word and so-on.  However, double 
> words seem like a very reasonable request.

Hmm, yeah.  Meanwhile I found the MOVE_MAX target macro which gives
me what I was looking for (max memory-reg move size with a single
instruction).  Eventually increasing the maximum number of
loads/stores to two also allows handling of (some) non-power-of-two sizes
and some more cases of unaligned accesses on SLOW_UNALIGNED_ACCESS
targets.  But then we're re-implementing move_by_pieces on GIMPLE ... ;)
(maybe not totally unreasonable?).

I'm going to go for a single load/store and MOVE_MAX for now - I
have quite some fallout to deal with anyway (analyzed strlenopt-1.c
FAIL only, the other strlenopt cases are probably similar)

FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "strlen (" 2
FAIL: gcc.dg/strlenopt-1.c scan-tree-dump-times strlen "memcpy (" 4

we generate (note unfolded read from "/"!)

  _15 = MEM[(char * {ref-all})"/"];
  MEM[(char * {ref-all})_14] = _15;

where strlenopt doesn't catch (short *)_14 = (short)"/\0" (maybe too
much asked, given endianess and so ...).

FAIL: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen "strlen (" 2
FAIL: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen "memcpy (" 8
FAIL: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen "strchr (" 0
FAIL: gcc.dg/strlenopt-10.c scan-tree-dump-times strlen "memcpy 
([^\\n\\r]*,
 1)" 1
FAIL: gcc.dg/strlenopt-18g.c scan-tree-dump-times strlen "memcpy (" 4
FAIL: gcc.dg/strlenopt-19.c scan-tree-dump-times strlen "memcpy (" 6
FAIL: gcc.dg/strlenopt-1f.c scan-tree-dump-times strlen "strlen (" 2
FAIL: gcc.dg/strlenopt-1f.c scan-tree-dump-times strlen "memcpy (" 4
FAIL: gcc.dg/strlenopt-2.c scan-tree-dump-times strlen "strlen (" 2
FAIL: gcc.dg/strlenopt-2.c scan-tree-dump-times strlen "memcpy (" 5
FAIL: gcc.dg/strlenopt-20.c scan-tree-dump-times strlen "memcpy (" 4
FAIL: gcc.dg/strlenopt-21.c scan-tree-dump-times strlen "memcpy (" 3
FAIL: gcc.dg/strlenopt-6.c scan-tree-dump-times strlen "memcpy (" 7
FAIL: gcc.dg/strlenopt-6.c scan-tree-dump-times strlen "strchr (" 0
FAIL: gcc.dg/strlenopt-7.c scan-tree-dump-times strlen "strlen (" 0
FAIL: gcc.dg/strlenopt-7.c scan-tree-dump-times strlen "memcpy (" 2
FAIL: gcc.dg/strlenopt-7.c scan-tree-dump-times optimized "return 3;" 1
FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "strlen (" 0
FAIL: gcc.dg/strlenopt-8.c scan-tree-dump-times strlen "memcpy (" 4
FAIL: gcc.dg/strlenopt-9.c scan-tree-dump-times strlen "memcpy (" 6

FAIL: gfortran.dg/coarray_lib_realloc_1.f90  -O   scan-tree-dump-times 
original
"__builtin_memcpy" 2

Both memcpy calls are now plain assignments.  The testcase needs
changing to test what it really wanted to test ...

FAIL: gfortran.dg/pr45636.f90  -O   scan-tree-dump-times forwprop2 
"memset" 0

This shows that funny DSE patterns in forwprop no longer work
when the store is not a memcpy but a plain assignment.  Of course
DSE also doesn't remove dead memset()s.  The testcase also shows
that we could/should handle memset() in the same way if it only
requires a single store from a constant.

Thanks,
Richard.

[wwwdocs] Shorten contribute.html a bit and convert links to https

[Gerald Pfeifer]

Applied.

(gcc-bugs also has changed its usage, it's not meant for direct
posting any more.)

Gerald

Index: contribute.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.84
diff -u -r1.84 contribute.html
--- contribute.html 22 Jun 2014 13:07:07 -  1.84
+++ contribute.html 27 Jun 2014 11:07:43 -
@@ -68,10 +68,9 @@
 
 Submissions which do not conform to the standards will be returned
 with a request to address any such problems.  To help with the
-preparation of patches respecting these rules, one can use the script
-https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh";>
-contrib/check_GNU_style.sh to detect some of the common
-mistakes. 
+preparation of patches you can use the script https://gcc.gnu.org/viewcvs/gcc/trunk/contrib/check_GNU_style.sh?view=markup";>
+contrib/check_GNU_style.sh.
 
 
 Testing Patches
@@ -79,8 +78,7 @@
 All patches must be thoroughly tested.  We encourage you to test
 changes with as many host and target combinations as is practical.  In
 addition to using real hardware, you can
-use simulators to increase your test
-coverage.
+use simulators.
 
 Much of GCC's code is used only by some targets, or used in quite
 different ways by different targets.  When choosing targets to test a
@@ -91,7 +89,7 @@
 
 You will of course have tested that your change does what you
 expected it to do: fix a bug, improve an optimization, add a new
-feature.  If the test framework permits, you should automate these
+feature.  Where possible you should automate these
 tests and add them to GCC's testsuite.  You must also perform
 regression tests to ensure that your patch does not break anything
 else.  Typically, this means comparing post-patch test results to
@@ -104,9 +102,8 @@
 If your change is to code that is not in a front end, or is to the
 C front end, you must perform a complete build of GCC and the runtime
 libraries included with it, on at least one target.  You must
-bootstrap all default languages, not just C.  You must also run all of the
-testsuites included with GCC and its runtime libraries.  For a normal
-native configuration, running
+bootstrap all default languages, not just C, and run all testsuites.
+For a normal native configuration, running
 
 make bootstrap
 make -k check
@@ -141,9 +138,7 @@
 In all cases you must test exactly the change that you intend to
 submit; it's not good enough to test an earlier variant.  The tree
 where you perform this test should not have any other changes applied
-to it, because otherwise you cannot be sure that your patch will work
-correctly on its own.  Include all your new testcases in your
-testsuite run.
+to it.  Include all your new testcases in your testsuite run.
 
 
 Documentation Changes
@@ -192,8 +187,7 @@
 For new features a description of the feature and your implementation.
 For bugs a description of what was wrong with the existing code, and a
 reference to any previous bug report (in the
-https://gcc.gnu.org/bugzilla/";>GCC bug tracker or the
-http://gcc.gnu.org/ml/gcc-bugs/";>gcc-bugs archives) and any
+https://gcc.gnu.org/bugzilla/";>GCC bug tracker) and any
 existing testcases for the problem in the GCC testsuite.
 
 

Re: [patch 1/4] change specific int128 -> generic intN

[Eric Botcazou]

> gcc/
>   * cppbuiltin.c (define_builtin_macros_for_type_sizes): Round
>   pointer size up to a power of two.
>   * defaults.h (DWARF2_ADDR_SIZE): Round up.
>   (POINTER_SIZE_UNITS): New, rounded up value.
>   * dwarf2asm.c (size_of_encoded_value): Use it.
>   (dw2_output_indirect_constant_1): Likewise.
>   * expmed.c (init_expmed_one_conv): We now know the sizes of
>   partial int modes.
>   * loop-iv.c (iv_number_of_iterations): Use precision, not size.
>   * optabs.c (expand_float): Use precision, not size.
>   (expand_fix): Likewise.
>   * simplify-rtx (simplify_unary_operation_1): Likewise.
>   * tree-dfa.c (get_ref_base_and_extent): Likewise.
>   * varasm.c (assemble_addr_to_section): Round up pointer sizes.
>   (default_assemble_integer) Likewise.
>   (dump_tm_clone_pairs): Likewise.
>   * tree-core.c: Adjust comment.

No stor-layout.c listed here but...

> Index: gcc/stor-layout.c
> ===
> --- gcc/stor-layout.c (revision 211858)
> +++ gcc/stor-layout.c (working copy)
> @@ -2123,13 +2142,13 @@ layout_type (tree type)
> 
>  case BOOLEAN_TYPE:
>  case INTEGER_TYPE:
>  case ENUMERAL_TYPE:
>SET_TYPE_MODE (type,
>smallest_mode_for_size (TYPE_PRECISION (type), MODE_INT));
> -  TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type)));
> +  TYPE_SIZE (type) = bitsize_int (GET_MODE_PRECISION (TYPE_MODE
> (type))); TYPE_SIZE_UNIT (type) = size_int (GET_MODE_SIZE (TYPE_MODE
> (type))); break;

This doesn't look correct, you might end up with types smaller than their 
modes and breaking the TYPE_SIZE/TYPE_SIZE_UNIT relationship.

> @@ -2516,16 +2535,33 @@ initialize_sizetypes (void)
>  precision = LONG_TYPE_SIZE;
>else if (strcmp (SIZETYPE, "long long unsigned int") == 0)
>  precision = LONG_LONG_TYPE_SIZE;
>else if (strcmp (SIZETYPE, "short unsigned int") == 0)
>  precision = SHORT_TYPE_SIZE;
>else
> gcc_unreachable ();
> 
>bprecision
> -= MIN (precision + BITS_PER_UNIT_LOG + 1, MAX_FIXED_MODE_SIZE);
> += MIN (precision, MAX_FIXED_MODE_SIZE);
>bprecision
>  = GET_MODE_PRECISION (smallest_mode_for_size (bprecision, MODE_INT));
>if (bprecision > HOST_BITS_PER_DOUBLE_INT)
>  bprecision = HOST_BITS_PER_DOUBLE_INT;
> 
>/* Create stubs for sizetype and bitsizetype so we can create constants. 

Why are you reducing the precision here?

-- 
Eric Botcazou

Re: [PATCH] remove broken and redundant diagnostic in i386_pe_section_type_flags

[Trevor Saunders]

On Fri, Jun 27, 2014 at 09:48:00AM +0200, Kai Tietz wrote:
> Hi Trev,
> 
> 2014-06-27 1:55 GMT+02:00  :
> > From: Trevor Saunders 
> >
> > Hi,
> >
> > While fixing up the hash_table patch's bustedness here I noticed the code
> > doesn't make any sense.  What it inserts into the hash table will never 
> > match
> > what we try and look up in it.  If you want to use hash_table or htab as a 
> > map
> > you need to deal with the keys yourself, it doesn't do it for you.
> >
> > varasm.c is the only caller of this target hook, and it correctly uses a
> > htab to check if the flags returned by the hook are the same as the
> > flags it has for the section, and emit an error if not.  Therefore if we 
> > fixed
> > this machinary it would only ever emit redundant errors, so it would seem to
> > make sense to get rid of it.
> 
> Agreed.
> 
> >  I don't have a setup to test windows targets at hand, but I checked I can
> > buildd a compiler targeting x86_64-cygwin with this patch.  Ok if someone 
> > can
> > really test it and it passes?
> 
> I've tested your patch on mingw.  So patch is Ok.  Please apply.

thanks, commited as r212069

Trev

> 
> Thanks,
> Kai
> 
> > Trev
> >
> > gccc/
> >
> > * config/i386/winnt.c (i386_pe_section_type_flags): Remove
> > redundant diagnostic machinary.

Re: [c++-concepts] Change constraint equivalence

[Andrew Sutton]

> Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
> cp/ChangeLog, the latter to testsuite/ChangeLog).

This is the format (and file) that Gaby requested when we started the
project. We can certainly distribute the entries, but I don't know if
its worthwhile right now.

Andrew

[PATCH] IPA REF: alias refactoring

[Martin Liška]

Hi,
this patch enhances alias manipulation for symtab_node. Honza suggested 
following changes.

Patch is pre approved, will be committed if no comments and regressions.
Bootstrapped on x86_64-pc-linux-gnu, regression tests have been running.

Thanks,
Martin

gcc/ChangeLog:

* cgraph.h (iterate_direct_aliases): New function.
(FOR_EACH_ALIAS): New macro iterates all direct aliases for a node.
* cgraph.c (cgraph_for_node_thunks_and_aliases): Usage of
FOR_EACH_ALIAS added.
(cgraph_for_node_and_aliases): Likewise.
* cgraphunit.c (assemble_thunks_and_aliases): Likewise.
* ipa-inline.c (reset_edge_caches): Likewise.
(update_caller_keys): Likewise.
* trans-mem.c (ipa_tm_execute): Likewise.
*varpool.c (varpool_analyze_node): Likewise.
(varpool_for_node_and_aliases): Likewise.
* ipa-ref.h (first_referring_alias): New function.
(last_referring_alias): Likewise.
* ipa-ref.c (ipa_ref::remove_reference): Removal function
is sensitive to IPA_REF_ALIASes.
* symtab.c (symtab_node::add_reference): Node of IPA_REF_ALIAS type
are put at the beginning of the list.
(symtab_node::iterate_direct_aliases): New function.

gcc/lto/ChangeLog:

* lto-partition.c (add_symbol_to_partition_1): Usage of
FOR_EACH_ALIAS added.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 7360f77..568eb45 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2194,8 +2194,7 @@ cgraph_for_node_thunks_and_aliases (struct cgraph_node *node,
 bool include_overwritable)
 {
   struct cgraph_edge *e;
-  int i;
-  struct ipa_ref *ref = NULL;
+  struct ipa_ref *ref;
 
   if (callback (node, data))
 return true;
@@ -2206,16 +2205,16 @@ cgraph_for_node_thunks_and_aliases (struct cgraph_node *node,
   if (cgraph_for_node_thunks_and_aliases (e->caller, callback, data,
 	  include_overwritable))
 	return true;
-  for (i = 0; node->iterate_referring (i, ref); i++)
-if (ref->use == IPA_REF_ALIAS)
-  {
-	struct cgraph_node *alias = dyn_cast  (ref->referring);
-	if (include_overwritable
-	|| cgraph_function_body_availability (alias) > AVAIL_OVERWRITABLE)
-	  if (cgraph_for_node_thunks_and_aliases (alias, callback, data,
-		  include_overwritable))
-	return true;
-  }
+
+  FOR_EACH_ALIAS (node, ref)
+{
+  struct cgraph_node *alias = dyn_cast  (ref->referring);
+  if (include_overwritable
+	  || cgraph_function_body_availability (alias) > AVAIL_OVERWRITABLE)
+	if (cgraph_for_node_thunks_and_aliases (alias, callback, data,
+		include_overwritable))
+	  return true;
+}
   return false;
 }
 
@@ -2229,21 +2228,20 @@ cgraph_for_node_and_aliases (struct cgraph_node *node,
 			 void *data,
 			 bool include_overwritable)
 {
-  int i;
-  struct ipa_ref *ref = NULL;
+  struct ipa_ref *ref;
 
   if (callback (node, data))
 return true;
-  for (i = 0; node->iterate_referring (i, ref); i++)
-if (ref->use == IPA_REF_ALIAS)
-  {
-	struct cgraph_node *alias = dyn_cast  (ref->referring);
-	if (include_overwritable
-	|| cgraph_function_body_availability (alias) > AVAIL_OVERWRITABLE)
-  if (cgraph_for_node_and_aliases (alias, callback, data,
-	   include_overwritable))
-	return true;
-  }
+
+  FOR_EACH_ALIAS (node, ref)
+{
+  struct cgraph_node *alias = dyn_cast  (ref->referring);
+  if (include_overwritable
+	  || cgraph_function_body_availability (alias) > AVAIL_OVERWRITABLE)
+	if (cgraph_for_node_and_aliases (alias, callback, data,
+	 include_overwritable))
+	  return true;
+}
   return false;
 }
 
diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index 0761e26..3ab0516 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -254,6 +254,9 @@ public:
   /* Iterates I-th referring item in the list, REF is also set.  */
   struct ipa_ref *iterate_referring (unsigned i, struct ipa_ref *&ref);
 
+  /* Iterates I-th referring alias item in the list, REF is also set.  */
+  struct ipa_ref *iterate_direct_aliases (unsigned i, struct ipa_ref *&ref);
+
   /* Vectors of referring and referenced entities.  */
   struct ipa_ref_list ref_list;
 
@@ -281,6 +284,10 @@ public:
   priority_type get_init_priority ();
 };
 
+/* Walk all aliases for NODE.  */
+#define FOR_EACH_ALIAS(node, alias) \
+   for (unsigned x_i = 0; node->iterate_direct_aliases (x_i, alias); x_i++)
+
 enum availability
 {
   /* Not yet set by cgraph_function_body_availability.  */
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index 76b2fda1..b0478cb 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1711,8 +1711,7 @@ static void
 assemble_thunks_and_aliases (struct cgraph_node *node)
 {
   struct cgraph_edge *e;
-  int i;
-  struct ipa_ref *ref = NULL;
+  struct ipa_ref *ref;
 
   for (e = node->callers; e;)
 if (e->caller->thunk.thunk_p)
@@ -1725,20 +1724,20 @@ assemble_thunks_and_aliases (struct cgraph_node *node)
   }
 else
   e = e->next_caller;
-  for (i = 0; node->iterate_referring (i, ref); i++)
-if (ref->use

[PATCH] Remove bswap STRICT_ALING target limitation

[Richard Biener]

The following patch enables bswap-from-load for STRICT_ALIGNMENT
targets when the load is aligned instead of unconditionally
(which probably was not intended).

(note to self: we should fully transition to use SLOW_UNALIGNED_ACCESS)

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

Richard.

2014-06-27  Richard Biener  

* tree-ssa-math-opts.c (bswap_replace): Fix
SLOW_UNALIGNED_ACCESS test to only apply to unaligned object.

Index: gcc/tree-ssa-math-opts.c
===
--- gcc/tree-ssa-math-opts.c(revision 212064)
+++ gcc/tree-ssa-math-opts.c(working copy)
@@ -2179,7 +2179,9 @@ bswap_replace (gimple cur_stmt, gimple_s
   unsigned align;
 
   align = get_object_alignment (src);
-  if (bswap && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
+  if (bswap
+ && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
+ && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
return false;
 
   gsi_move_before (&gsi, &gsi_ins);

Re: Don't use create_tmp_var for static vars

[Richard Biener]

On Fri, Jun 27, 2014 at 10:55 AM, Tobias Burnus
 wrote:
> Bernd Schmidt wrote:
>> I discovered that create_tmp_var is used in the gfortran frontend to
>> create static variables. IMO the function is not intended to do this,
>> and it causes problems for a modification I need to make to it which
>> assumes that it only creates local variables. So I've made a patch
>> to make fortran directly use build_decl instead in these cases.
>>
>> The following was bootstrapped and tested on x86_64-linux. Ok?
>
> I don't know whether create_tmp_var is/was supposed to also handle
> static variables. In any case, the modification looks fine to me.

No, it isn't supposed to be used for non-automatics.

Richard.

> Tobias
>
> PS: I am looking forward to the offloading support, including your PTX
> support.

Re: [PATCH] Fix undefined behavior in ira-build.c

[Jakub Jelinek]

On Fri, Jun 27, 2014 at 11:34:48AM +0200, Richard Biener wrote:
> On Fri, Jun 27, 2014 at 9:16 AM, Jakub Jelinek  wrote:
> > Hi!
> >
> > This fixes the most common source of the new runtime diagnostics
> > during bootstrap-ubsan, if num is 0, ira_object_id_map is often
> > 0 as well.
> >
> > Ok for trunk/4.9?
> 
> If it's also sometimes 1 then why not if (num > 1) - just as optimization...

Sure, if Vlad is ok with the patch, consider it changed to num > 1.

> > 2014-06-27  Jakub Jelinek  
> >
> > * ira-build.c (sort_conflict_id_map): Don't call
> > qsort if num is 0, as ira_object_id_map might be NULL.
> >
> > --- gcc/ira-build.c.jj  2014-05-30 10:51:16.0 +0200
> > +++ gcc/ira-build.c 2014-06-26 20:21:43.428987181 +0200
> > @@ -2821,8 +2821,9 @@ sort_conflict_id_map (void)
> >FOR_EACH_ALLOCNO_OBJECT (a, obj, oi)
> > ira_object_id_map[num++] = obj;
> >  }
> > -  qsort (ira_object_id_map, num, sizeof (ira_object_t),
> > -object_range_compare_func);
> > +  if (num)
> > +qsort (ira_object_id_map, num, sizeof (ira_object_t),
> > +  object_range_compare_func);
> >for (i = 0; i < num; i++)
> >  {
> >ira_object_t obj = ira_object_id_map[i];
> >
> > Jakub

Jakub

Re: [PATCH] Fix undefined behavior in ira-build.c

[Richard Biener]

On Fri, Jun 27, 2014 at 9:16 AM, Jakub Jelinek  wrote:
> Hi!
>
> This fixes the most common source of the new runtime diagnostics
> during bootstrap-ubsan, if num is 0, ira_object_id_map is often
> 0 as well.
>
> Ok for trunk/4.9?

If it's also sometimes 1 then why not if (num > 1) - just as optimization...

Richard.

> 2014-06-27  Jakub Jelinek  
>
> * ira-build.c (sort_conflict_id_map): Don't call
> qsort if num is 0, as ira_object_id_map might be NULL.
>
> --- gcc/ira-build.c.jj  2014-05-30 10:51:16.0 +0200
> +++ gcc/ira-build.c 2014-06-26 20:21:43.428987181 +0200
> @@ -2821,8 +2821,9 @@ sort_conflict_id_map (void)
>FOR_EACH_ALLOCNO_OBJECT (a, obj, oi)
> ira_object_id_map[num++] = obj;
>  }
> -  qsort (ira_object_id_map, num, sizeof (ira_object_t),
> -object_range_compare_func);
> +  if (num)
> +qsort (ira_object_id_map, num, sizeof (ira_object_t),
> +  object_range_compare_func);
>for (i = 0; i < num; i++)
>  {
>ira_object_t obj = ira_object_id_map[i];
>
> Jakub

Re: [PATCH] Devirtualization dump functions fix

[Martin Liška]

On 06/27/2014 10:38 AM, Richard Biener wrote:

On Thu, Jun 26, 2014 at 5:58 PM, Martin Liška  wrote:

On 06/26/2014 04:29 PM, Jakub Jelinek wrote:

On Thu, Jun 26, 2014 at 04:27:49PM +0200, Martin Liška wrote:

Well yes - it is of course similar broken in spirit but at least a lot
simpler ;)  I'd put a comment there why we do check g for NULL.

But it increases overhead, there are hundreds of gimple_location calls
and most of them will never pass NULL.  Can't you simply
do what you do in the inline here in the couple of spots where
the stmt might be NULL?

Sure, do you have any suggestion how should be called such function?
Suggestion: gimple_location_or_unknown ?

gimple_location_safe or gimple_safe_location?

 Jakub

Thanks, there's new patch.

Patch has been tested for Firefox with -flto -fdump-ipa-devirt.
Bootstrap and regression tests have been running.

Ready for trunk after regression tests?

Ok with s/gimple_safe_location/gimple_location_safe/ (I think that's
the more canonical naming - what's a "safe location" after all?)

Thanks,
Richard.

You are right, gimple_location_safe sounds better.
Patch has been just committed with your change.

Thanks,
Martin



ChangeLog:

2014-06-26  Martin Liska  

 * gimple.h (gimple_safe_location): New function introduced.
 * cgraphunit.c (walk_polymorphic_call_targets): Usage
 of gimple_safe_location replaces gimple_location.
 (gimple_fold_call): Likewise.
 * ipa-devirt.c (ipa_devirt): Likewise.
 * ipa-prop.c (ipa_make_edge_direct_to_target): Likewise.
 * ipa.c (walk_polymorphic_call_targets): Likewise.
 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Likewise.

Re: Fix finding reg-sets of call insn in collect_fn_hard_reg_usage

[Tom de Vries]

On 19-06-14 18:40, Richard Henderson wrote:

On 06/19/2014 09:07 AM, Tom de Vries wrote:


2014-06-19  Tom de Vries  

* final.c (collect_fn_hard_reg_usage): Add separate IOR_HARD_REG_SET for
get_call_reg_set_usage.


Ok, as far as it goes, but...

It seems like there should be quite a bit of overlap with regs_ever_live here.
  How much of that previous computation can we leverage?

It appears that regs_ever_live includes any register mentioned explicitly, and
thus the only registers it doesn't contain are those killed by the callees.
That should be an easier scan than the rtl, since we have those already
collected in the cgraph.

Sorry I wasn't paying much attention earlier when this was first posted, when
questions like this may have been answered.



Richard,

At the moment, collect_fn_hard_reg_usage is run in pass_final, after final (), 
that is, after the final splitting of insns. The idea is that we use the most 
final representation available, to be on the safe side.


AFAIU, the regs_ever_live information is computed using the df infrastructure, 
which requires the cfg, which is available only until pass_free_cfg for all 
targets (more details in this discussion: 
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01060.html ). I don't think 
regs_ever_live is guaranteed to be up to date afterwards.


So in order to known whether it's safe and optimal to use regs_ever_live 
instead, the question is whether the passes after pass_free_cfg (are allowed to) 
add or remove sets or clobbers of call_really_used_regs. I don't know the full 
answer there.


Eric, can you comment?

Thanks,
- Tom

[C++ Patch] PR 61614

[Paolo Carlini]

Hi,

r204228 represented just a small cleanup 
(https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02597.html) but 
apparently is causing this small regression present on the release 
branch too. Shall we simply revert it for now? At least on the branch? 
Tested x86_64-linux.


Thanks,
Paolo.

/
/cp
2014-06-27  Paolo Carlini  

PR c++/61614
* semantics.c (finish_compound_literal): Revert r204228.

/testsuite
2014-06-27  Paolo Carlini  

PR c++/61614
* g++.dg/ext/complit14.C: New.
Index: cp/semantics.c
===
--- cp/semantics.c  (revision 212064)
+++ cp/semantics.c  (working copy)
@@ -2607,7 +2607,6 @@ finish_compound_literal (tree type, tree compound_
   if ((!at_function_scope_p () || CP_TYPE_CONST_P (type))
   && TREE_CODE (type) == ARRAY_TYPE
   && !TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type)
-  && !cp_unevaluated_operand
   && initializer_constant_valid_p (compound_literal, type))
 {
   tree decl = create_temporary_var (type);
Index: testsuite/g++.dg/ext/complit14.C
===
--- testsuite/g++.dg/ext/complit14.C(revision 0)
+++ testsuite/g++.dg/ext/complit14.C(working copy)
@@ -0,0 +1,11 @@
+// PR c++/61614
+// { dg-options "" }
+
+int Fn (...);
+
+void
+Test ()
+{
+  int j = Fn ((const int[]) { 0 });// OK
+  unsigned long sz = sizeof Fn ((const int[]) { 0 });  // Error
+}

Re: Optimize type streaming

[Richard Biener]

On Fri, 27 Jun 2014, Jan Hubicka wrote:

> Hi,
> the most common types of tree nodes streamed are declarations (5.4M for
> Firefox) and types (4.2M for Firefox).  This patch makes representation of
> types smaller by avoiding saving redundent info about type and its variants.
> About 50% of types are variants and overall this saves about 6% of WPA stream:

This is mostly by avoiding the output of references to already written
items (as they are identical as you verify).

> -:  797:static void
>   4251251:  798:lto_input_ts_type_common_tree_pointers (struct 
> lto_input_block *ib,
> -:  799:struct data_in 
> *data_in, tree expr)
> -:  800:{
>   4251251:  801:  TYPE_MAIN_VARIANT (expr) = stream_read_tree (ib, data_in);
> -:  802:
> -:  803:  /* Variants share most the properties with the main 
> variant.  */
>   4251251:  804:  if (TYPE_MAIN_VARIANT (expr) == expr)
> -:  805:{
>   2511593:  806:  if (COMPLETE_TYPE_P (expr))
> -:  807:{
>   2419254:  808:  TYPE_SIZE (expr) = stream_read_tree (ib, data_in);
>   2419254:  809:  TYPE_SIZE_UNIT (expr) = stream_read_tree (ib, 
> data_in);
> -:  810:}
>   2511593:  811:  TYPE_ATTRIBUTES (expr) = stream_read_tree (ib, data_in);
> -:  812:}
>   4251251:  822:  TYPE_NAME (expr) = stream_read_tree (ib, data_in);
> 
> The patch also adds sanity checking that types actually match that uncovered
> at least one bug in the coverage code.
> 
> 
> Bootstrapped/regtested x86_64-linux and tested with Firefox build, I got 
> slightly faster
> WPA (94->89s) but it bit close to noise factor. OK?

Minor comments below, ok with those changes.

> Honza
> 
>   * tree-streamer-out.c (pack_ts_type_common_value_fields): Stream if type
>   is complete.
>   (write_ts_type_common_tree_pointers): Do not stream fields not set for 
> incomplete
>   types; do not stream duplicated fields for variants; sanity check that 
> variant
>   and type match.
>   (write_ts_type_non_common_tree_pointers): Likewise.
>   * tree-streamer-in.c (unpack_ts_type_common_value_fields): Mark in 
> TYPE_SIZE whether
>   type is complete.
>   (lto_input_ts_type_common_tree_pointers): Do same changes as in
>   write_ts_type_common_tree_pointers
>   (lto_input_ts_type_non_common_tree_pointers): Likewise.
> 
>   * lto.c (lto_fixup_prevailing_type): Copy fields shared in between type
>   and main variant.
>   (compare_tree_sccs_1): Do not compare fields shared in between type
>   and variant.
>   (lto_read_decls): Fixup types first before inserting into hash.
> Index: tree-streamer-out.c
> ===
> --- tree-streamer-out.c   (revision 212058)
> +++ tree-streamer-out.c   (working copy)
> @@ -313,6 +313,7 @@ pack_ts_type_common_value_fields (struct
>bp_pack_value (bp, TYPE_RESTRICT (expr), 1);
>bp_pack_value (bp, TYPE_USER_ALIGN (expr), 1);
>bp_pack_value (bp, TYPE_READONLY (expr), 1);
> +  bp_pack_value (bp, COMPLETE_TYPE_P (expr), 1);
>bp_pack_var_len_unsigned (bp, TYPE_PRECISION (expr));
>bp_pack_var_len_unsigned (bp, TYPE_ALIGN (expr));
>/* Make sure to preserve the fact whether the frontend would assign
> @@ -698,19 +699,34 @@ static void
>  write_ts_type_common_tree_pointers (struct output_block *ob, tree expr,
>   bool ref_p)
>  {
> -  stream_write_tree (ob, TYPE_SIZE (expr), ref_p);
> -  stream_write_tree (ob, TYPE_SIZE_UNIT (expr), ref_p);
> -  stream_write_tree (ob, TYPE_ATTRIBUTES (expr), ref_p);
> -  stream_write_tree (ob, TYPE_NAME (expr), ref_p);
> -  /* Do not stream TYPE_POINTER_TO or TYPE_REFERENCE_TO.  They will be
> - reconstructed during fixup.  */
>/* Do not stream TYPE_NEXT_VARIANT, we reconstruct the variant lists
>   during fixup.  */
>stream_write_tree (ob, TYPE_MAIN_VARIANT (expr), ref_p);
> +  if (TYPE_MAIN_VARIANT (expr) == expr)
> +{
> +  if (COMPLETE_TYPE_P (expr))
> + {
> +   stream_write_tree (ob, TYPE_SIZE (expr), ref_p);
> +   stream_write_tree (ob, TYPE_SIZE_UNIT (expr), ref_p);
> + }
> +  stream_write_tree (ob, TYPE_ATTRIBUTES (expr), ref_p);
> +}
> +  else
> +{
> +  if (COMPLETE_TYPE_P (expr))
> + {
> +   gcc_checking_assert (TYPE_SIZE (expr) == TYPE_SIZE (TYPE_MAIN_VARIANT 
> (expr)));
> +   gcc_checking_assert (TYPE_SIZE_UNIT (expr) == TYPE_SIZE_UNIT 
> (TYPE_MAIN_VARIANT (expr)));
> + }
> +  gcc_checking_assert (TYPE_ATTRIBUTES (expr) == TYPE_ATTRIBUTES 
> (TYPE_MAIN_VARIANT (expr)));
> +}
> +  stream_write_tree (ob, TYPE_NAME (expr), ref_p);
>stream_write_tree (ob, TYPE_CONTEXT (expr), ref_p);
> +  stream_write_tree (ob, TYPE_STUB_DECL (expr), ref_p);
> +  /* Do not stream TYPE_POINTER_TO or TYPE_REFERENCE_TO.  They will be
> + reconstructed during fixup.

Re: Don't use create_tmp_var for static vars

[Tobias Burnus]

Bernd Schmidt wrote:
> I discovered that create_tmp_var is used in the gfortran frontend to
> create static variables. IMO the function is not intended to do this,
> and it causes problems for a modification I need to make to it which
> assumes that it only creates local variables. So I've made a patch
> to make fortran directly use build_decl instead in these cases.
>
> The following was bootstrapped and tested on x86_64-linux. Ok?

I don't know whether create_tmp_var is/was supposed to also handle
static variables. In any case, the modification looks fine to me.

Tobias

PS: I am looking forward to the offloading support, including your PTX
support.

Re: [PATCH] Fix PR61306: improve handling of sign and cast in bswap

[Richard Biener]

On Fri, Jun 27, 2014 at 4:29 AM, Thomas Preud'homme
 wrote:
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>> Sent: Thursday, June 19, 2014 1:36 PM
>>
>> Richard, given this issue, I think we should wait a few more days before I
>> commit
>> A backported (and fixed of course) version to 4.8 and 4.9.
>
> No new issues were reported since then. Is it ok to commit the backport
> (with Jakub fix) now or should we wait more?

FIne with me now.

Richard.

> Best regards,
>
> Thomas
>
>

Don't use create_tmp_var for static vars

[Bernd Schmidt]

I discovered that create_tmp_var is used in the gfortran frontend to 
create static variables. IMO the function is not intended to do this, 
and it causes problems for a modification I need to make to it which 
assumes that it only creates local variables. So I've made a patch to 
make fortran directly use build_decl instead in these cases.


The following was bootstrapped and tested on x86_64-linux. Ok?


Bernd
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c	(revision 435407)
+++ gcc/fortran/trans-array.c	(working copy)
@@ -2046,11 +2046,15 @@ gfc_build_constant_array_constructor (gf
   TREE_CONSTANT (init) = 1;
   TREE_STATIC (init) = 1;
 
-  tmp = gfc_create_var (tmptype, "A");
+  tmp = build_decl (input_location, VAR_DECL, create_tmp_var_name ("A"),
+		tmptype);
+  DECL_ARTIFICIAL (tmp) = 1;
+  DECL_IGNORED_P (tmp) = 1;
   TREE_STATIC (tmp) = 1;
   TREE_CONSTANT (tmp) = 1;
   TREE_READONLY (tmp) = 1;
   DECL_INITIAL (tmp) = init;
+  pushdecl (tmp);
 
   return tmp;
 }
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c	(revision 435407)
+++ gcc/fortran/trans-decl.c	(working copy)
@@ -5345,11 +5345,16 @@ create_main_function (tree fndecl)
 TREE_STATIC (array) = 1;
 
 /* Create a static variable to hold the jump table.  */
-var = gfc_create_var (array_type, "options");
+var = build_decl (input_location, VAR_DECL,
+		  create_tmp_var_name ("options"),
+		  array_type);
+DECL_ARTIFICIAL (var) = 1;
+DECL_IGNORED_P (var) = 1;
 TREE_CONSTANT (var) = 1;
 TREE_STATIC (var) = 1;
 TREE_READONLY (var) = 1;
 DECL_INITIAL (var) = array;
+pushdecl (var);
 var = gfc_build_addr_expr (build_pointer_type (integer_type_node), var);
 
 tmp = build_call_expr_loc (input_location,

Re: [PATCH] Devirtualization dump functions fix

[Richard Biener]

On Thu, Jun 26, 2014 at 5:58 PM, Martin Liška  wrote:
>
> On 06/26/2014 04:29 PM, Jakub Jelinek wrote:
>>
>> On Thu, Jun 26, 2014 at 04:27:49PM +0200, Martin Liška wrote:
>
> Well yes - it is of course similar broken in spirit but at least a lot
> simpler ;)  I'd put a comment there why we do check g for NULL.

 But it increases overhead, there are hundreds of gimple_location calls
 and most of them will never pass NULL.  Can't you simply
 do what you do in the inline here in the couple of spots where
 the stmt might be NULL?
>>>
>>> Sure, do you have any suggestion how should be called such function?
>>> Suggestion: gimple_location_or_unknown ?
>>
>> gimple_location_safe or gimple_safe_location?
>>
>> Jakub
>
> Thanks, there's new patch.
>
> Patch has been tested for Firefox with -flto -fdump-ipa-devirt.
> Bootstrap and regression tests have been running.
>
> Ready for trunk after regression tests?

Ok with s/gimple_safe_location/gimple_location_safe/ (I think that's
the more canonical naming - what's a "safe location" after all?)

Thanks,
Richard.

>
> ChangeLog:
>
> 2014-06-26  Martin Liska  
>
> * gimple.h (gimple_safe_location): New function introduced.
> * cgraphunit.c (walk_polymorphic_call_targets): Usage
> of gimple_safe_location replaces gimple_location.
> (gimple_fold_call): Likewise.
> * ipa-devirt.c (ipa_devirt): Likewise.
> * ipa-prop.c (ipa_make_edge_direct_to_target): Likewise.
> * ipa.c (walk_polymorphic_call_targets): Likewise.
> * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Likewise.

[PATCH][sched-deps] Generalise usage of macro fusion to work on any two insns

[Kyrill Tkachov]

Hi all,

This patch generalises the TARGET_MACRO_FUSION_PAIR_P hook usage to work 
on more than just
compares and conditional branches for which it was initially designed 
for (for x86).


There are some instructions in arm and aarch64 that can be fused 
together when they're back to back in the instruction stream and I'd 
like to use this hook to keep them together.


I'll post an implementation of TARGET_MACRO_FUSION_PAIR_P for arm and 
aarch64 shortly...


Bootstrapped and tested on x86, aarch64-none-linux-gnu and 
arm-none-linux-gnueabihf.


Ok for trunk?

2014-06-27  Ramana Radhakrishnan 
Kyrylo Tkachov  

* sched-deps.c (try_group_insn): Generalise macro fusion hook usage
to any two insns.  Update comment.commit 1b096c837bf49dcfd9ff3e55168593d4a4aea48d
Author: Kyrylo Tkachov 
Date:   Fri Jun 13 11:41:41 2014 +0100

[sched-deps] Generalise macro fusion hook usage

diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c
index 7cafc8b..71e274d 100644
--- a/gcc/sched-deps.c
+++ b/gcc/sched-deps.c
@@ -2820,35 +2820,57 @@ sched_analyze_2 (struct deps_desc *deps, rtx x, rtx insn)
 sched_deps_info->finish_rhs ();
 }
 
-/* Try to group comparison and the following conditional jump INSN if
-   they're already adjacent. This is to prevent scheduler from scheduling
-   them apart.  */
+/* Try to group two fuseable insns together to prevent scheduler
+   from scheduling them apart.  */
 
 static void
 try_group_insn (rtx insn)
 {
-  unsigned int condreg1, condreg2;
-  rtx cc_reg_1;
   rtx prev;
 
-  if (!any_condjump_p (insn))
+  if (!targetm.sched.macro_fusion_pair_p)
 return;
 
-  targetm.fixed_condition_code_regs (&condreg1, &condreg2);
-  cc_reg_1 = gen_rtx_REG (CCmode, condreg1);
-  prev = prev_nonnote_nondebug_insn (insn);
-  if (!reg_referenced_p (cc_reg_1, PATTERN (insn))
-  || !prev
-  || !modified_in_p (cc_reg_1, prev))
-return;
+  if (any_condjump_p (insn))
+{
+  unsigned int condreg1, condreg2;
+  rtx cc_reg_1;
+  targetm.fixed_condition_code_regs (&condreg1, &condreg2);
+  cc_reg_1 = gen_rtx_REG (CCmode, condreg1);
+  prev = prev_nonnote_nondebug_insn (insn);
+  if (!reg_referenced_p (cc_reg_1, PATTERN (insn))
+	  || !prev
+	  || !modified_in_p (cc_reg_1, prev))
+	return;
+
+  goto succ;
 
+}
+  else
+{
+  rtx set_dest = single_set (insn);
+
+  prev = prev_nonnote_nondebug_insn (insn);
+  if (prev
+	  && set_dest
+	  && single_set (prev))
+	{
+	  set_dest = SET_DEST (set_dest);
+
+	  if (!modified_in_p (set_dest, prev))
+	return;
+
+	  goto succ;
+	}
+}
+
+  return;
+
+ succ:
   /* Different microarchitectures support macro fusions for different
  combinations of insn pairs.  */
-  if (!targetm.sched.macro_fusion_pair_p
-  || !targetm.sched.macro_fusion_pair_p (prev, insn))
-return;
-
-  SCHED_GROUP_P (insn) = 1;
+  if (prev && targetm.sched.macro_fusion_pair_p (prev, insn))
+SCHED_GROUP_P (insn) = 1;
 }
 
 /* Analyze an INSN with pattern X to find all dependencies.  */

Re: [PATCH ARM] Improve ARM memset inlining

[Ramana Radhakrishnan]

On Tue, May 6, 2014 at 5:59 AM, bin.cheng  wrote:
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of bin.cheng
>> Sent: Monday, May 05, 2014 3:21 PM
>> To: Richard Earnshaw
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: RE: [PATCH ARM] Improve ARM memset inlining
>>
>> Hi Richard,  Thanks for reviewing.  I embedded answers to your comments,
>> also updated the patch.
>>
>> > -Original Message-
>> > From: Richard Earnshaw
>> > Sent: Friday, May 02, 2014 10:00 PM
>> > To: Bin Cheng
>> > Cc: gcc-patches@gcc.gnu.org
>> > Subject: Re: [PATCH ARM] Improve ARM memset inlining
>> >
>> > On 30/04/14 03:52, bin.cheng wrote:
>> > > Hi,
>> > > This patch expands small memset calls into direct memory set
>> > > instructions by introducing "setmemsi" pattern.  For processors
>> > > without NEON support, it expands memset using general store
>> > > instruction.  For example, strd for 4-bytes aligned addresses.  For
>> > > processors with NEON support, it expands memset using neon
>> > > instructions like vstr and miscellaneous vst1.* instructions for
>> > > both
>> aligned
>> > and unaligned cases.
>> > >
>> > > This patch depends on
>> > > http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01923.html otherwise
>> > > vst1.64 will be generated for 32-bit aligned memory unit.
>> > >
>> > > There is also one leftover work of this patch:  Since vst1.*
>> > > instructions only support post-increment addressing mode, the
>> > > inlined memset for unaligned neon cases should be like:
>> > >   vmov.i32   q8, #...
>> > >   vst1.8 {q8}, [r3]!
>> > >   vst1.8 {q8}, [r3]!
>> > >   vst1.8 {q8}, [r3]!
>> > >   vst1.8 {q8}, [r3]
>> >
>> > Other than for zero, I'd expect the vmov to be vmov.i8 to move an
>> arbitrary
>> I just used vmov.i32 as an example.  The element size is actually
> calculated by
>> function neon_valid_immediate which works as expected I think.
>>
>> > byte value into all lanes in a vector.  After that, if the alignment
>> > is
>> known to
>> > be more than 8-bit, I'd expect the vst1 instructions (with the
>> > exception
>> of the
>> > last store if the length is not a multiple of the alignment) to use
>> >
>> > vst1. {reg}, [addr-reg :]!
>> >
>> > Hence, for 16-bit aligned data, we want
>> >
>> > vst1.16 {q8}, [r3:16]!
>> Did I miss something important?  It seems to me the explicit alignment
> notes
>> supported are 64/128/256.  So what do you mean by 16 bits alignment here?
>>
>> >
>> > > But for now, gcc can't do this and below code is generated:
>> > >   vmov.i32   q8, #...
>> > >   vst1.8 {q8}, [r3]
>> > >   addr2,   r3,  #16
>> > >   addr3,   r2,  #16
>> > >   vst1.8 {q8}, [r2]
>> > >   vst1.8 {q8}, [r3]
>> > >   addr2,   r3,  #16
>> > >   vst1.8 {q8}, [r2]
>> > >
>> > > I investigated this issue.  The root cause lies in rtx cost returned
>> > > by ARM backend.  Anyway, I think this is another issue and should be
>> > > fixed in separated patch.

Ok looks like Charles B from Linaro has run into the same thing and
has some fixes to suggest in costs.

>> > >
>> > > Bootstrap and reg-test on cortex-a15, with or without neon support.
>> > > Is it OK?
>> > >
>> >
>> > Some more comments inline.
>> >
>> > > Thanks,
>> > > bin
>> > >
>> > >
>> > > 2014-04-29  Bin Cheng  
>> > >
>> > >   PR target/55701
>> > >   * config/arm/arm.md (setmem): New pattern.
>> > >   * config/arm/arm-protos.h (struct tune_params): New field.
>> > >   (arm_gen_setmem): New prototype.
>> > >   * config/arm/arm.c (arm_slowmul_tune): Initialize new field.
>> > >   (arm_fastmul_tune, arm_strongarm_tune, arm_xscale_tune): Ditto.
>> > >   (arm_9e_tune, arm_v6t2_tune, arm_cortex_tune): Ditto.
>> > >   (arm_cortex_a8_tune, arm_cortex_a7_tune): Ditto.
>> > >   (arm_cortex_a15_tune, arm_cortex_a53_tune): Ditto.
>> > >   (arm_cortex_a57_tune, arm_cortex_a5_tune): Ditto.
>> > >   (arm_cortex_a9_tune, arm_cortex_a12_tune): Ditto.
>> > >   (arm_v7m_tune, arm_v6m_tune, arm_fa726te_tune): Ditto.
>> > >   (arm_const_inline_cost): New function.
>> > >   (arm_block_set_max_insns): New function.
>> > >   (arm_block_set_straight_profit_p): New function.
>> > >   (arm_block_set_vect_profit_p): New function.
>> > >   (arm_block_set_unaligned_vect): New function.
>> > >   (arm_block_set_aligned_vect): New function.
>> > >   (arm_block_set_unaligned_straight): New function.
>> > >   (arm_block_set_aligned_straight): New function.
>> > >   (arm_block_set_vect, arm_gen_setmem): New functions.
>> > >
>> > > gcc/testsuite/ChangeLog
>> > > 2014-04-29  Bin Cheng  
>> > >
>> > >   PR target/55701
>> > >   * gcc.target/arm/memset-inline-1.c: New test.
>> > >   * gcc.target/arm/memset-inline-2.c: New test.
>> > >   * gcc.target/arm/memset-inline-3.c: New test.
>> > >   * gcc.target/arm/memset-inline-4.c: New test.
>> > >   * gcc.target/arm/memset-inline-5.c: New test.
>> > >   * gcc.target/arm/memset-inline-6.c: New test.
>> > >   * g

Re: [RFC PATCH] -fsanitize=nonnull and -fsanitize=returns-nonnull support

[Richard Biener]

On Fri, 27 Jun 2014, Jakub Jelinek wrote:

> Hi!
> 
> This patch implements sanitization for nonnull and returns_nonnull
> attributes.
> Similarly to -fsanitize=null this option disables
> -fdelete-null-pointer-checks silently, and adds checks before calling
> functions with declared nonnull arguments if we don't pass NULL there,
> and before return in functions declared with returns_nonnull also inserts
> check whether the return value is not NULL.
> 
> As GCC 4.9.0+ now aggressively optimizes based on these attributes and we've
> seen several issues in real world apps, I think this is really needed.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux normally (yes,rtl
> checking) and c,c++,fortran release checking bootstrap-ubsan.
> 
> Will post bugs in gcc discovered by it later.
> 
> The patch adds two new (trivial handlers) to libubsan, as it is maintained
> in llvm's compiler-rt, will talk to them if they are interested in those
> and what exact wording and form (AFAIK clang also added the gcc
> {,returns_}nonnull attributes).  If they wouldn't be interested, guess
> we could add them in a separate, gcc owned, source file in ubsan (like we
> own Makefile*).

Looks good to me.

Thanks for adding this!

Richard.

> 2014-06-27  Jakub Jelinek  
> 
>   * flag-types.h (enum sanitize_code): Add SANITIZE_NONNULL and
>   SANITIZE_RETURNS_NONNULL, or them into SANITIZE_UNDEFINED.
>   * opts.c (common_handle_option): Handle SANITIZE_NONNULL and
>   SANITIZE_RETURNS_NONNULL and disable flag_delete_null_pointer_checks
>   for them.
>   * sanitizer.def (BUILT_IN_UBSAN_HANDLE_NONNULL_ARG,
>   BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT,
>   BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN,
>   BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN_ABORT): New.
>   * ubsan.c (instrument_bool_enum_load): Set *gsi back to
>   stmt's iterator.
>   (instrument_nonnull_arg, instrument_nonnull_return): New functions.
>   (pass_ubsan::gate): Return true even for SANITIZE_NONNULL
>   or SANITIZE_RETURNS_NONNULL.
>   (pass_ubsan::execute): Call instrument_nonnull_{arg,return}.
> 
>   * c-c++-common/ubsan/nonnull-1.c: New test.
>   * c-c++-common/ubsan/nonnull-2.c: New test.
>   * c-c++-common/ubsan/nonnull-3.c: New test.
>   * c-c++-common/ubsan/nonnull-4.c: New test.
>   * c-c++-common/ubsan/nonnull-5.c: New test.
> 
> --- gcc/flag-types.h.jj   2014-06-20 23:26:24.0 +0200
> +++ gcc/flag-types.h  2014-06-26 14:39:44.133970103 +0200
> @@ -231,10 +231,13 @@ enum sanitize_code {
>SANITIZE_FLOAT_DIVIDE = 1 << 12,
>SANITIZE_FLOAT_CAST = 1 << 13,
>SANITIZE_BOUNDS = 1 << 14,
> +  SANITIZE_NONNULL = 1 << 15,
> +  SANITIZE_RETURNS_NONNULL = 1 << 16,
>SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | 
> SANITIZE_UNREACHABLE
>  | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
>  | SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
> -| SANITIZE_BOUNDS,
> +| SANITIZE_BOUNDS | SANITIZE_NONNULL
> +| SANITIZE_RETURNS_NONNULL,
>SANITIZE_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
>  };
>  
> --- gcc/opts.c.jj 2014-06-20 23:26:23.0 +0200
> +++ gcc/opts.c2014-06-26 14:43:51.620652007 +0200
> @@ -1468,6 +1468,9 @@ common_handle_option (struct gcc_options
> { "float-cast-overflow", SANITIZE_FLOAT_CAST,
>   sizeof "float-cast-overflow" - 1 },
> { "bounds", SANITIZE_BOUNDS, sizeof "bounds" - 1 },
> +   { "nonnull", SANITIZE_NONNULL, sizeof "nonnull" - 1 },
> +   { "returns-nonnull", SANITIZE_RETURNS_NONNULL,
> + sizeof "returns-nonnull" - 1 },
> { NULL, 0, 0 }
>   };
>   const char *comma;
> @@ -1511,7 +1514,8 @@ common_handle_option (struct gcc_options
>  
>   /* When instrumenting the pointers, we don't want to remove
>  the null pointer checks.  */
> - if (flag_sanitize & SANITIZE_NULL)
> + if (flag_sanitize & (SANITIZE_NULL | SANITIZE_NONNULL
> +  | SANITIZE_RETURNS_NONNULL))
> opts->x_flag_delete_null_pointer_checks = 0;
>   break;
>}
> --- gcc/sanitizer.def.jj  2014-06-20 23:26:23.0 +0200
> +++ gcc/sanitizer.def 2014-06-26 16:52:34.644801331 +0200
> @@ -417,3 +417,19 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
> "__ubsan_handle_out_of_bounds_abort",
> BT_FN_VOID_PTR_PTR,
> ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_ARG,
> +   "__ubsan_handle_nonnull_arg",
> +   BT_FN_VOID_PTR_PTRMODE,
> +   ATTR_COLD_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT,
> +   "__ubsan_handle_nonnull_arg_abort",
> +   BT_FN_VOID_PTR_PTRMODE,
> +  

Re: [PATCH, Pointer Bounds Checker 9/x] Cgraph extension

[Ilya Enkovich]

Ping

2014-05-06 16:13 GMT+04:00 Ilya Enkovich :
> Ping
>
> 2014-04-16 18:03 GMT+04:00 Ilya Enkovich :
>> Hi,
>>
>> This patch introduces changes in call graph for Pointer Bounds Checker.
>>
>> New fields instrumented_version, instrumentation_clone and orig_decl are 
>> added for cgraph_node:
>>  - instrumentation_clone field is 1 for nodes created for instrumented 
>> version of functions
>>  - instrumented_version points to instrumented/original node
>>  - orig_decl holds original function declaration for instrumented nodes in 
>> case original node is removed
>>
>> IPA_REF_CHKP reference type is introduced for nodes to reference 
>> instrumented function versions from originals.  It is used to have proper 
>> reachability analysis.
>>
>> When original function bodies are not needed anymore, functions are 
>> transformed into thunks having call edge to the instrumented function.  
>> Therefore new field appeared in cgraph_thunk_info to mark such thunks.
>>
>> Does it look OK?
>>
>> Bootstrapped and tested on linux-x86_64.
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-04-16  Ilya Enkovich  
>>
>> * cgraph.h (cgraph_thunk_info): Add add_pointer_bounds_args
>> field.
>> (cgraph_node): Add instrumented_version, orig_decl and
>> instrumentation_clone fields.
>> (symtab_alias_target): Allow IPA_REF_CHKP reference.
>> * cgraph.c (cgraph_remove_node): Fix instrumented_version
>> of the referenced node if any.
>> (dump_cgraph_node): Dump instrumentation_clone and
>> instrumented_version fields.
>> (verify_cgraph_node): Check correctness of IPA_REF_CHKP
>> references and instrumentation thunks.
>> * cgraphbuild.c (rebuild_cgraph_edges): Rebuild IPA_REF_CHKP
>> reference.
>> (cgraph_rebuild_references): Likewise.
>> * cgraphunit.c (assemble_thunks_and_aliases): Skip thunks
>> calling instrumneted function version.
>> * ipa-ref.h (ipa_ref_use): Add IPA_REF_CHKP.
>> (ipa_ref): increase size of use field.
>> * ipa-ref.c (ipa_ref_use_name): Add element for IPA_REF_CHKP.
>> * lto-cgraph.c (lto_output_node): Output instrumentation_clone,
>> thunk.add_pointer_bounds_args and orig_decl field.
>> (lto_output_ref): Adjust to new ipa_ref::use field size.
>> (input_overwrite_node): Read instrumentation_clone field.
>> (input_node): Read thunk.add_pointer_bounds_args and orig_decl
>> fields.
>> (input_ref): Adjust to new ipa_ref::use field size.
>> (input_cgraph_1): Compute instrumented_version fields and restore
>> IDENTIFIER_TRANSPARENT_ALIAS chains.
>> * lto-streamer.h (LTO_minor_version): Change minor version from
>> 0 to 1.
>> * ipa.c (symtab_remove_unreachable_nodes): Consider instrumented
>> clone as address taken if the original one is address taken.
>> (cgraph_externally_visible_p): Mark instrumented 'main' as
>> externally visible.
>> (function_and_variable_visibility): Filter instrumentation
>> thunks.
>>
>>
>> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
>> index be3661a..6210c68 100644
>> --- a/gcc/cgraph.c
>> +++ b/gcc/cgraph.c
>> @@ -1828,6 +1828,12 @@ cgraph_remove_node (struct cgraph_node *node)
>>  }
>>cgraph_n_nodes--;
>>
>> +  if (node->instrumented_version)
>> +{
>> +  node->instrumented_version->instrumented_version = NULL;
>> +  node->instrumented_version = NULL;
>> +}
>> +
>>/* Clear out the node to NULL all pointers and add the node to the free
>>   list.  */
>>memset (node, 0, sizeof (*node));
>> @@ -2070,6 +2076,11 @@ dump_cgraph_node (FILE *f, struct cgraph_node *node)
>>if (indirect_calls_count)
>>  fprintf (f, "  Has %i outgoing edges for indirect calls.\n",
>>  indirect_calls_count);
>> +
>> +  if (node->instrumentation_clone)
>> +fprintf (f, "  Is instrumented version.\n");
>> +  else if (node->instrumented_version)
>> +fprintf (f, "  Has instrumented version.\n");
>>  }
>>
>>
>> @@ -2850,7 +2861,9 @@ verify_cgraph_node (struct cgraph_node *node)
>> }
>>for (i = 0; ipa_ref_list_reference_iterate (&node->ref_list,
>>   i, ref); i++)
>> -   if (ref->use != IPA_REF_ALIAS)
>> +   if (ref->use == IPA_REF_CHKP)
>> + ;
>> +   else if (ref->use != IPA_REF_ALIAS)
>>   {
>> error ("Alias has non-alias reference");
>> error_found = true;
>> @@ -2868,6 +2881,35 @@ verify_cgraph_node (struct cgraph_node *node)
>> error_found = true;
>>   }
>>  }
>> +
>> +  /* Check all nodes reference their instrumented versions.  */
>> +  if (node->analyzed
>> +  && node->instrumented_version
>> +  && !node->instrumentation_clone)
>> +{
>> +  bool ref_found = false;
>> +  int i;
>> +  struct ipa_ref *ref;
>> +
>> +  f

Re: [PATCH, Pointer Bounds Checker 4/x] Built-in functions

[Ilya Enkovich]

Ping

2014-05-06 16:11 GMT+04:00 Ilya Enkovich :
> PING
>
> 2014-04-16 16:19 GMT+04:00 Ilya Enkovich :
>> Hi,
>>
>> This patch introduces built-in functions used by Pointer Bounds Checker.  It 
>> is mostly similar to what was reverted from 4.9, I just added types and 
>> attributes to builtins.  This patch also introduces pointer_bounds_type_node 
>> to be used in built-in function type declarations.
>>
>> Bootstrapped and tested on linux-x86_64.
>>
>> OK for trunk?
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-04-16  Ilya Enkovich  
>>
>> * tree-core.h (tree_index): Add TI_POINTER_BOUNDS_TYPE.
>> * tree.h (pointer_bounds_type_node): New.
>> * tree.c (build_common_tree_nodes): Initialize
>> pointer_bounds_type_node.
>> * builtin-types.def (BT_BND): New.
>> (BT_FN_PTR_CONST_PTR): New.
>> (BT_FN_CONST_PTR_CONST_PTR): New.
>> (BT_FN_BND_CONST_PTR): New.
>> (BT_FN_CONST_PTR_BND): New.
>> (BT_FN_PTR_CONST_PTR_SIZE): New.
>> (BT_FN_PTR_CONST_PTR_CONST_PTR): New.
>> (BT_FN_VOID_PTRPTR_CONST_PTR): New.
>> (BT_FN_VOID_CONST_PTR_SIZE): New.
>> (BT_FN_VOID_PTR_BND): New.
>> (BT_FN_CONST_PTR_CONST_PTR_CONST_PTR): New.
>> (BT_FN_BND_CONST_PTR_SIZE): New.
>> (BT_FN_PTR_CONST_PTR_CONST_PTR_SIZE): New.
>> (BT_FN_VOID_CONST_PTR_BND_CONST_PTR): New.
>> * chkp-builtins.def: New.
>> * builtins.def: include chkp-builtins.def.
>> (DEF_CHKP_BUILTIN): New.
>> * builtins.c (expand_builtin): Support BUILT_IN_CHKP_INIT_PTR_BOUNDS,
>> BUILT_IN_CHKP_NULL_PTR_BOUNDS, BUILT_IN_CHKP_COPY_PTR_BOUNDS,
>> BUILT_IN_CHKP_CHECK_PTR_LBOUNDS, BUILT_IN_CHKP_CHECK_PTR_UBOUNDS,
>> BUILT_IN_CHKP_CHECK_PTR_BOUNDS, BUILT_IN_CHKP_SET_PTR_BOUNDS,
>> BUILT_IN_CHKP_NARROW_PTR_BOUNDS, BUILT_IN_CHKP_STORE_PTR_BOUNDS,
>> BUILT_IN_CHKP_GET_PTR_LBOUND, BUILT_IN_CHKP_GET_PTR_UBOUND,
>> BUILT_IN_CHKP_BNDMK, BUILT_IN_CHKP_BNDSTX, BUILT_IN_CHKP_BNDCL,
>> BUILT_IN_CHKP_BNDCU, BUILT_IN_CHKP_BNDLDX, BUILT_IN_CHKP_BNDRET,
>> BUILT_IN_CHKP_INTERSECT, BUILT_IN_CHKP_NARROW,
>> BUILT_IN_CHKP_EXTRACT_LOWER, BUILT_IN_CHKP_EXTRACT_UPPER.
>> * c-family/c.opt (fcheck-pointer-bounds): New.
>> * toplev.c (process_options): Check Pointer Bounds Checker is 
>> supported.
>> * doc/extend.texi: Document Pointer Bounds Checker built-in 
>> functions.
>>
>>
>> diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
>> index fba9c7d..2e5f361 100644
>> --- a/gcc/builtin-types.def
>> +++ b/gcc/builtin-types.def
>> @@ -133,6 +133,8 @@ DEF_PRIMITIVE_TYPE (BT_I4, builtin_type_for_size 
>> (BITS_PER_UNIT*4, 1))
>>  DEF_PRIMITIVE_TYPE (BT_I8, builtin_type_for_size (BITS_PER_UNIT*8, 1))
>>  DEF_PRIMITIVE_TYPE (BT_I16, builtin_type_for_size (BITS_PER_UNIT*16, 1))
>>
>> +DEF_PRIMITIVE_TYPE (BT_BND, pointer_bounds_type_node)
>> +
>>  DEF_POINTER_TYPE (BT_PTR_CONST_STRING, BT_CONST_STRING)
>>  DEF_POINTER_TYPE (BT_PTR_LONG, BT_LONG)
>>  DEF_POINTER_TYPE (BT_PTR_ULONGLONG, BT_ULONGLONG)
>> @@ -234,6 +236,10 @@ DEF_FUNCTION_TYPE_1 (BT_FN_UINT16_UINT16, BT_UINT16, 
>> BT_UINT16)
>>  DEF_FUNCTION_TYPE_1 (BT_FN_UINT32_UINT32, BT_UINT32, BT_UINT32)
>>  DEF_FUNCTION_TYPE_1 (BT_FN_UINT64_UINT64, BT_UINT64, BT_UINT64)
>>  DEF_FUNCTION_TYPE_1 (BT_FN_BOOL_INT, BT_BOOL, BT_INT)
>> +DEF_FUNCTION_TYPE_1 (BT_FN_PTR_CONST_PTR, BT_PTR, BT_CONST_PTR)
>> +DEF_FUNCTION_TYPE_1 (BT_FN_CONST_PTR_CONST_PTR, BT_CONST_PTR, BT_CONST_PTR)
>> +DEF_FUNCTION_TYPE_1 (BT_FN_BND_CONST_PTR, BT_BND, BT_CONST_PTR)
>> +DEF_FUNCTION_TYPE_1 (BT_FN_CONST_PTR_BND, BT_CONST_PTR, BT_BND)
>>
>>  DEF_POINTER_TYPE (BT_PTR_FN_VOID_PTR, BT_FN_VOID_PTR)
>>
>> @@ -347,6 +353,13 @@ DEF_FUNCTION_TYPE_2 (BT_FN_BOOL_SIZE_CONST_VPTR, 
>> BT_BOOL, BT_SIZE,
>>  BT_CONST_VOLATILE_PTR)
>>  DEF_FUNCTION_TYPE_2 (BT_FN_BOOL_INT_BOOL, BT_BOOL, BT_INT, BT_BOOL)
>>  DEF_FUNCTION_TYPE_2 (BT_FN_VOID_UINT_UINT, BT_VOID, BT_UINT, BT_UINT)
>> +DEF_FUNCTION_TYPE_2 (BT_FN_PTR_CONST_PTR_SIZE, BT_PTR, BT_CONST_PTR, 
>> BT_SIZE)
>> +DEF_FUNCTION_TYPE_2 (BT_FN_PTR_CONST_PTR_CONST_PTR, BT_PTR, BT_CONST_PTR, 
>> BT_CONST_PTR)
>> +DEF_FUNCTION_TYPE_2 (BT_FN_VOID_PTRPTR_CONST_PTR, BT_VOID, BT_PTR_PTR, 
>> BT_CONST_PTR)
>> +DEF_FUNCTION_TYPE_2 (BT_FN_VOID_CONST_PTR_SIZE, BT_VOID, BT_CONST_PTR, 
>> BT_SIZE)
>> +DEF_FUNCTION_TYPE_2 (BT_FN_VOID_PTR_BND, BT_VOID, BT_PTR, BT_BND)
>> +DEF_FUNCTION_TYPE_2 (BT_FN_CONST_PTR_CONST_PTR_CONST_PTR, BT_CONST_PTR, 
>> BT_CONST_PTR, BT_CONST_PTR)
>> +DEF_FUNCTION_TYPE_2 (BT_FN_BND_CONST_PTR_SIZE, BT_BND, BT_CONST_PTR, 
>> BT_SIZE)
>>
>>  DEF_POINTER_TYPE (BT_PTR_FN_VOID_PTR_PTR, BT_FN_VOID_PTR_PTR)
>>
>> @@ -430,6 +443,8 @@ DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I4_INT, BT_VOID, 
>> BT_VOLATILE_PTR, BT_I4, BT
>>  DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I8_INT, BT_VOID, BT_VOLATILE_PTR, 
>> BT_I8, BT_INT)
>>  DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I16_INT, BT_

Re: [PATCH, Pointer Bounds Checker 3/x] Target hooks for Pointer Bounds Checker

[Ilya Enkovich]

Ping

2014-05-06 16:11 GMT+04:00 Ilya Enkovich :
> PING
>
> 2014-04-16 15:52 GMT+04:00 Ilya Enkovich :
>> Hi,
>>
>> This patch introduces target hooks to be used by Pointer Bounds Checker.  
>> Hooks set is different from what was approved for 4.9 (and later reverted).  
>> I added hooks to work with returned bounds and to prepare incoming bounds 
>> for vararg functions.  It allowed to remove some target assumptions from 
>> expand code.
>>
>> Bootstrapped and tested on linux-x86_64.
>>
>> OK for trunk?
>>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2014-04-16  Ilya Enkovich  
>>
>> * target.def (builtin_chkp_function): New.
>> (chkp_bound_type): New.
>> (chkp_bound_mode): New.
>> (chkp_make_bounds_constant): New.
>> (chkp_initialize_bounds): New.
>> (fn_abi_va_list_bounds_size): New.
>> (load_bounds_for_arg): New.
>> (store_bounds_for_arg): New.
>> (load_returned_bounds): New.
>> (store_returned_bounds): New.
>> (chkp_function_value_bounds): New.
>> (setup_incoming_vararg_bounds): New.
>> * targhooks.h (default_load_bounds_for_arg): New.
>> (default_store_bounds_for_arg): New.
>> (default_load_returned_bounds): New.
>> (default_store_returned_bounds): New.
>> (default_fn_abi_va_list_bounds_size): New.
>> (default_chkp_bound_type): New.
>> (default_chkp_bound_mode): New.
>> (default_builtin_chkp_function): New.
>> (default_chkp_function_value_bounds): New.
>> (default_chkp_make_bounds_constant): New.
>> (default_chkp_initialize_bounds): New.
>> (default_setup_incoming_vararg_bounds): New.
>> * targhooks.c (default_load_bounds_for_arg): New.
>> (default_store_bounds_for_arg): New.
>> (default_load_returned_bounds): New.
>> (default_store_returned_bounds): New.
>> (default_fn_abi_va_list_bounds_size): New.
>> (default_chkp_bound_type): New.
>> (default_chkp_bound_mode); New.
>> (default_builtin_chkp_function): New.
>> (default_chkp_function_value_bounds): New.
>> (default_chkp_make_bounds_constant): New.
>> (default_chkp_initialize_bounds): New.
>> (default_setup_incoming_vararg_bounds): New.
>> * doc/tm.texi.in (TARGET_FN_ABI_VA_LIST_BOUNDS_SIZE): New.
>> (TARGET_LOAD_BOUNDS_FOR_ARG): New.
>> (TARGET_STORE_BOUNDS_FOR_ARG): New.
>> (TARGET_LOAD_RETURNED_BOUNDS): New.
>> (TARGET_STORE_RETURNED_BOUNDS): New.
>> (TARGET_CHKP_FUNCTION_VALUE_BOUNDS): New.
>> (TARGET_SETUP_INCOMING_VARARG_BOUNDS): New.
>> (TARGET_BUILTIN_CHKP_FUNCTION): New.
>> (TARGET_CHKP_BOUND_TYPE): New.
>> (TARGET_CHKP_BOUND_MODE): New.
>> (TARGET_CHKP_MAKE_BOUNDS_CONSTANT): New.
>> (TARGET_CHKP_INITIALIZE_BOUNDS): New.
>> * doc/tm.texi: Regenerated.
>>
>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
>> index b8ca17e..d868129 100644
>> --- a/gcc/doc/tm.texi
>> +++ b/gcc/doc/tm.texi
>> @@ -4333,6 +4333,13 @@ This hook returns the va_list type of the calling 
>> convention specified by
>>  The default version of this hook returns @code{va_list_type_node}.
>>  @end deftypefn
>>
>> +@deftypefn {Target Hook} tree TARGET_FN_ABI_VA_LIST_BOUNDS_SIZE (tree 
>> @var{fndecl})
>> +This hook returns size for @code{va_list} object in function specified
>> +by @var{fndecl}.  This hook is used by Pointer Bounds Checker to build 
>> bounds
>> +for @code{va_list} object.  Return @code{integer_zero_node} if no bounds
>> +should be used (e.g. @code{va_list} is a scalar pointer to the stack).
>> +@end deftypefn
>> +
>>  @deftypefn {Target Hook} tree TARGET_CANONICAL_VA_LIST_TYPE (tree 
>> @var{type})
>>  This hook returns the va_list type of the calling convention specified by 
>> the
>>  type of @var{type}. If @var{type} is not a valid va_list type, it returns
>> @@ -5150,6 +5157,49 @@ defined, then define this hook to return @code{true} 
>> if
>>  Otherwise, you should not define this hook.
>>  @end deftypefn
>>
>> +@deftypefn {Target Hook} rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx @var{slot}, 
>> rtx @var{arg}, rtx @var{slot_no})
>> +This hook is used by expand pass to emit insn to load bounds of
>> +@var{arg} passed in @var{slot}.  Expand pass uses this hook in case
>> +bounds of @var{arg} are not passed in register.  If @var{slot} is a
>> +memory, then bounds are loaded as for regular pointer loaded from
>> +memory.  If @var{slot} is not a memory then @var{slot_no} is an integer
>> +constant holding number of the target dependent special slot which
>> +should be used to obtain bounds.  Hook returns RTX holding loaded bounds.
>> +@end deftypefn
>> +
>> +@deftypefn {Target Hook} void TARGET_STORE_BOUNDS_FOR_ARG (rtx @var{arg}, 
>> rtx @var{slot}, rtx @var{bounds}, rtx @var{slot_no})
>> +This hook is used by expand pass to emit insns to store @var{bounds} of
>> +@var{arg} passed in @v

Re: [Patch ARM/testsuite 01/22] Neon intrinsics execution tests initial framework.

[Ramana Radhakrishnan]

On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
 wrote:
> * documentation (README)
> * dejanu driver (neon-intrinsics.exp)
> * support macros (arm-neon-ref.h, compute-ref-data.h)
> * Tests for 2 intrinsics: vaba, vld1
>
> diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/README 
> b/gcc/testsuite/gcc.target/arm/neon-intrinsics/README
> new file mode 100644
> index 000..795c870
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/neon-intrinsics/README
> @@ -0,0 +1,131 @@
> +This directory contains executable tests for ARM/AArch64 Neon intrinsics.

Specifically for AArch64 the intrinsics that are common with the
original ARM Neon intrinsics. AArch64 intrinsics that are a superset
of this can be added separately. If we were to extend this for the
remaining AArch64 intrinsics it should be possible to share these
between the 2 testsuites.

> +
> +The general framework is composed as follows:
> +- neon-intrinsics.exp: main dejagnu driver
> +- *.c: actual tests, generally one per intrinsinc family
> +- arm-neon-ref.h: contains macro definitions to save typing in actual
> +  test files
> +- compute-ref-data.h: contains input vectors definitions
> +- *.inc: generic tests, shared by several families of intrinsics. For
> +   instance, unary or binary operators
> +
> +

Extra newline.

> +A typical .c test file starts with the following contents (look at
> +vld1.c and vaba.c for sample cases):
> +#include 
> +#include "arm-neon-ref.h"
> +#include "compute-ref-data.h"
> +
> +

Extra newline.

> +Then, definitions of expected results, based on common input values,
> +as defined in compute-ref-data.h.
> +For example:
> +VECT_VAR_DECL(expected,int,16,4) [] = { 0x16, 0x17, 0x18, 0x19 };
> +defines the expected results of an operator generating int16x4 values.
> +
> +The common input values defined in compute-ref-data.h have been chosen
> +to avoid corner-case values for most operators, yet exposing negative
> +values for signed operators. For this reason, their range is also
> +limited. For instance, the initialization of buffer_int16x4 will be
> +{ -16, -15, -14, -13 }.
> +

Thanks for calling this out.

In some cases actually putting in the corner case values might help. A
follow-up might be to add these specific cases somewhere for specific
intrinsics especially if we were planning on cleaning this whole area
up properly. Or to remember this in terms of testsuite coverage for
the intrinsics.

> +The initialization of floating-point values is done via hex notation,
> +to avoid potential rounding problems.
> +
> +To test special values and corner cases, specific initialization
> +values should be used in dedicated tests, to ensure proper coverage.
> +
> +When a variant of an intrinsic is not available, its expected result
> +should be defined to the value of CLEAN_PATTERN_8 as defined in
> +arm-neon-ref.h. For example:
> +VECT_VAR_DECL(expected,int,64,1) [] = { 0x };
> +if the given intrinsic has no variant producing an int64x1 result.
> +

For e.g. the vcmp intrinsics if the memory serves me right. I think it
would be good to point to an explicit example of an intrinsic where
this is used rather than letting the user search for a needle in a
haystack :)

> +

Extra newline.

> +This is because the helper function (check_results(), defined in
> +arm-neon-ref.h), iterates over all the possible variants, to save
> +typing in each individual test file. Alternatively, one can directly
> +call the CHECK/CHECK_FP macros to check only a few expected results
> +(see vabs.c for an example).
> +
> +

Extra newline.

> +Then, define the TEST_MSG string, which will be used when reporting errors.
> +
> +

Extra newline

> +Next, define the function performing the actual tests, in general
> +relying on the helpers provided by arm-neon-ref.h, which means:
> +
> +* declare necessary vectors of suitable types: using
> +  DECL_VARIABLE_ALL_VARIANTS when all variants are supported, or the
> +  relevant of subset calls to DECL_VARIABLE.
> +
> +* call clean_results() to initialize the 'results' buffers.
> +
> +* initialize the input vectors, using VLOAD, VDUP or VSET_LANE (vld*
> +  tests do not need this step, since their actual purpose is to
> +  initialize vectors).
> +
> +* execute the intrinsic on relevant variants, for instance using
> +  TEST_MACRO_ALL_VARIANTS_2_5.
> +
> +* call check_results() to check that the results match the expected
> +  values.
> +
> +A template test file could be:
> +=
> +#include 
> +#include "arm-neon-ref.h"
> +#include "compute-ref-data.h"
> +
> +/* Expected results.  */
> +VECT_VAR_DECL(expected,int,8,8) [] = { 0xf6, 0xf7, 0xf8, 0xf9,
> +  0xfa, 0xfb, 0xfc, 0xfd };
> +/* and as many others as necessary.  */
> +
> +#define TEST_MSG "VMYINTRINSIC"
> +void exec_myintrinsic (void)
> +{
> +  /* my test: v4=vmyintrinsic(v1,v2,v3), then store the result.  */
> +#define TEST_VMYINTR(Q, 

Re: [PATCH] remove broken and redundant diagnostic in i386_pe_section_type_flags

[Kai Tietz]

Hi Trev,

2014-06-27 1:55 GMT+02:00  :
> From: Trevor Saunders 
>
> Hi,
>
> While fixing up the hash_table patch's bustedness here I noticed the code
> doesn't make any sense.  What it inserts into the hash table will never match
> what we try and look up in it.  If you want to use hash_table or htab as a map
> you need to deal with the keys yourself, it doesn't do it for you.
>
> varasm.c is the only caller of this target hook, and it correctly uses a
> htab to check if the flags returned by the hook are the same as the
> flags it has for the section, and emit an error if not.  Therefore if we fixed
> this machinary it would only ever emit redundant errors, so it would seem to
> make sense to get rid of it.

Agreed.

>  I don't have a setup to test windows targets at hand, but I checked I can
> buildd a compiler targeting x86_64-cygwin with this patch.  Ok if someone can
> really test it and it passes?

I've tested your patch on mingw.  So patch is Ok.  Please apply.

Thanks,
Kai

> Trev
>
> gccc/
>
> * config/i386/winnt.c (i386_pe_section_type_flags): Remove
> redundant diagnostic machinary.

Re: [c++-concepts] Change constraint equivalence

[Marek Polacek]

On Fri, Jun 27, 2014 at 03:41:36AM -0400, Braden Obrzut wrote:
> On 06/27/2014 03:27 AM, Marek Polacek wrote:
> >Two spaces after you name.
> I'm not sure what happened to the second space.  It's there in the source I
> copied.  I'll have to be sure to double check the paste next time.
> >Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
> >cp/ChangeLog, the latter to testsuite/ChangeLog).
> >
> > Marek
> Are you sure about this?  Andrew has been putting everything in
> ChangeLog.concepts in the root.

Ah, sorry, for concepts you indeed might be using ChangeLog.concepts.

Marek

Re: [c++-concepts] Change constraint equivalence

[Paolo Carlini]

Hi,

On 06/27/2014 09:41 AM, Braden Obrzut wrote:
Are you sure about this?  Andrew has been putting everything in 
ChangeLog.concepts in the root.
In terms of general GCC rules, Marek is certainly right. Whether Andrew 
has (very) special reasons for doing that I don't know, meant to ask for 
some time, actually.


Paolo.

Re: [c++-concepts] Change constraint equivalence

[Braden Obrzut]

On 06/27/2014 03:27 AM, Marek Polacek wrote:

Two spaces after you name.
I'm not sure what happened to the second space.  It's there in the 
source I copied.  I'll have to be sure to double check the paste next time.

Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
cp/ChangeLog, the latter to testsuite/ChangeLog).

Marek
Are you sure about this?  Andrew has been putting everything in 
ChangeLog.concepts in the root.


- Braden Obrzut

Re: [Patch, PR 61061] Add state limit for regex NFA

[Paolo Carlini]

Hi,

On 06/27/2014 05:56 AM, Tim Shen wrote:

The limit can be customized by defining a macro
_GLIBCXX_REGEX_STATE_LIMIT. The default value is 10.

The testcase can be handled if we optimize consecutive quantifiers
(collapse them to one). But cases like "(a{100}b){100}" can't be
handled still.

We implement range quantifier "(foo){n}" by copying state sequence
(foo) n-1 times. That consumes more space. We may reimplement it (by
adding a new _S_op*) someday.

Bootstrapped and tested.

The actual patch is missing.. ;)

Paolo.

PS: sorry for being distracted by other issues: what happened to the 
other regex issue? I think we are simply going to apply, when ready, 
your more complete fix, right?

Re: Instructions vs Expressions in the backend (was Re: RFA: Rework FOR_BB_INSNS iterators)

[Oleg Endo]

On Wed, 2014-06-25 at 10:36 +0100, Richard Sandiford wrote:
> Oleg Endo  writes:
> > Personally, I'd like to see usage of standard STL-like iterator usage.
> > I've proposed something for edge_iterator a while ago, but people don't
> > seem very fond of it.  See also
> > https://gcc.gnu.org/ml/gcc-patches/2013-12/msg01129.html
> >
> > Have you also considered passing the new rtx_* types by value or
> > reference instead of pointer?  A long time ago I've quickly put together
> > a class 'rtxx' which was just a pointer wrapper for the rtx_def*
> > (basically the same as I proposed for edge_iterator).
> > I've converted the SH backend code to use it just to see what it would
> > look like.  The conversion itself was pretty straight forward -- just
> > replace 'rtx' with 'rtxx'.  Appropriate conversion
> > operators/constructors in 'class rtxx' made both interchangeable and
> > allowed co-existence of both and thus step-by-step conversion of the
> > code base.
> > Another advantage of passing around by value/ref is that it allows
> > operator overloading.  One use case could be instead of:
> >
> > if (MEM_P (XEXP (x, 0)))
> >   *total = address_cost (XEXP (XEXP (x, 0), 0),
> >  GET_MODE (XEXP (x, 0)),
> >  MEM_ADDR_SPACE (XEXP (x, 0)), true);
> >
> >
> > something like that (overloading operator[]):
> > if (x[0] == rtx_mem::type)
> >   *total = address_cost (x[0][0], x[0].mode (),
> >  x[0].mem_addr_space (), true);
> >
> > ... where rtx_mem::type would be some type for which 'rtxx' (or whatever
> > the name of the base class is) would provide the according operator
> > ==, != overloads.
> 
> I think this is an example of another problem with gcc coding style:
> that we're far too afraid of temporary variables.  In David's scheme
> I think this would be:
> 
>   if (rtx_mem *mem = as_a  (XEXP (x, 0)))
> *total = address_cost (XEXP (mem, 0), GET_MODE (mem),
>MEM_ADDR_SPACE (mem), true);
> 
> which with members would become:
> 
>   if (rtx_mem *mem = as_a  (...))
> *total = address_cost (mem->address (), mem->mode (), mem->address_space 
> (),
>true);
> 
> (although if we go down that route, I hope we can add an exception to the
> formatting rule so that no space should be used before "()".)

If such an exception is introduced, I can imagine it'd be difficult to
judge on a case by case whether to apply the exceptional rule or not,
since those are just function calls.
But in the end it doesn't matter.  It's just a matter of habbit :)

> 
> I suppose with the magic values it would be:
> 
>   if (rtx_mem mem = as_a  (x[0]))
> *total = address_cost (mem[0], mem.mode (), mem.address_space (), true);
> 
> but I'm not sure that that would really be more readable.

No, essentially it's the same.  Whether the current XEXP (x, n) is done
by operator [] or a member function 'xexp (n)' doesn't matter.  The
biggest (optical) change is for nested XEXP...
XEXP (XEXP (XEXP (x, a), b), c)
becomes
x.exp (a).exp (b).exp (c)

> FWIW I also did an experiment locally with replacing "rtx *" (rather than
> "rtx") with a "smart" pointer so that we could have four allocation
> areas: permanent, gty, function and temporary, with the pointer
> automatically promoting rtxes to the right allocation area for the
> containing object.
> 
> Having a smart pointer made it suprisingly uninvasive but there was
> probably too much C++ magic involved in the handling of XEXP, etc.,
> for the patch to be acceptable.  Still, it did noticeably reduce max RSS
> and was a significant compile-time saving for extreme compiles like
> insn-recog.ii.  Hope to return to it sometime...

Yep, passing the new rtx classes by value instead by pointer opens other
doors, such as implementing smart pointers internally and what not. 

> 
> > Another thing is rtx construction in C++ code, which could look like:
> >
> > emit_insn (rtx_insn (rtx_set (rtx_reg (0),
> >   rtx_plus (rtx_reg (1), rtx_reg (2);
> > emit_insn (rtx_barrier ());
> >
> > Although I'm not sure how often this is needed in current practice,
> > since most of the time rtx instances are created from the .md patterns.
> > Maybe it could be useful for implementing some kind of ad-hoc rtx
> > matching, as it's found in cost calculations, predicates, constrants,
> > e.g.
> >
> > if ((GET_CODE (XEXP (x, 0)) == SMAX || GET_CODE (XEXP (x, 0)) == SMIN)
> > && CONST_INT_P (XEXP (XEXP (x, 0), 1))
> > && REG_P (XEXP (XEXP (x, 0), 0))
> > && CONST_INT_P (XEXP (x, 1)))
> >
> > could become:
> > if (matches (x, rtx_smax (reg_rtx (), const_int (), const_int ()))
> > || matches (x, rtx_smin (reg_rtx (), const_int (), const_int ()))
> >
> > somehow I find that easier to read and write.
> 
> It sounds like this would be creating temporary rtxes though, which would
> be too expensive for matching.

Yeah, as I wrote it up there, proba

Re: [PATCH AARCH64] fix and enable non-const shuffle for bigendian using TBL instruction

[Marcus Shawcroft]

On 25 June 2014 10:21, Alan Lawrence  wrote:
> This one seems to have slipped under the radar. I've just rebased and run
> the regression tests on aarch64_be-none-elf, with no issues; ping?
>
> (patch applied straightforwardly, but rebased version below)

OK /Marcus

Re: Fwd: [RFC][gomp4] Offloading patches (2/3): Add tables generation

[Bernd Schmidt]

On 06/19/2014 12:19 PM, Ilya Verbin wrote:

On 18 Jun 16:22, Bernd Schmidt wrote:

What I think you need to do is
For the first compiler:
--enable-as-accelerator-for=x86_64-pc-linux-gnu
--target=x86_64-intelmic-linux-gnu --prefix=/somewhere

No --enable-accelerator options at all. This should work, if it
doesn't let me know what you find in /somewhere after installation
for both compilers.


It doesn't work without --enable-accelerator:

--enable-as-accelerator-for requires --enable-accelerator
make[1]: *** [configure-gcc] Error 1


Sorry for the delayed reply, I was travelling. There seem to be some 
thinkos in the configure script and Makefile; can you try the following 
(don't forget to regenerate configure)? It seems to work for ptx (with 
some additional changes to allow ptx builds without --enable-accelerator).



Bernd

Index: configure.ac
===
--- configure.ac	(revision 435407)
+++ configure.ac	(working copy)
@@ -905,15 +905,12 @@ AC_SUBST(enable_accelerator)
 AC_ARG_ENABLE(as-accelerator-for,
 [AS_HELP_STRING([--enable-as-accelerator-for], [build compiler as accelerator target for given host])],
 [
-  if test $enable_accelerator = no; then
-echo "--enable-as-accelerator-for requires --enable-accelerator"
-exit 1;
-  fi
   AC_DEFINE(ACCEL_COMPILER, 1,
[Define if this compiler should be built and used as the target
 device compiler for OpenACC.])
   enable_as_accelerator=yes
-  tool_prefix=${enable_as_accelerator_for}-accel-${enable_accelerator}
+  sedscript="s#${target_noncanonical}#${enable_as_accelerator_for}-accel-${target_noncanonical}#"
+  program_transform_name=`echo $program_transform_name | sed $sedscript`
   accel_dir_suffix=/accel/${target_noncanonical}
   real_target_noncanonical=${enable_as_accelerator_for}
   ALL_ACCEL=all-accel
Index: Makefile.in
===
--- Makefile.in	(revision 435407)
+++ Makefile.in	(working copy)
@@ -69,7 +69,6 @@ program_transform_name := @program_trans
 
 # Normally identical to target_noncanonical, except for compilers built
 # as accelerator targets.
-tool_prefix = @tool_prefix@
 accel_dir_suffix = @accel_dir_suffix@
 
 # Directory where sources are, from where we are.
@@ -777,7 +776,7 @@ BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir)
 
 # Actual name to use when installing a native compiler.
 GCC_INSTALL_NAME := $(shell echo gcc|sed '$(program_transform_name)')
-GCC_TARGET_INSTALL_NAME := $(tool_prefix)-$(shell echo gcc|sed '$(program_transform_name)')
+GCC_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo gcc|sed '$(program_transform_name)')
 CPP_INSTALL_NAME := $(shell echo cpp|sed '$(program_transform_name)')
 GCOV_INSTALL_NAME := $(shell echo gcov|sed '$(program_transform_name)')
 
@@ -3247,25 +3246,21 @@ install-common: native lang.install-comm
 # Install the driver program as $(target_noncanonical)-gcc,
 # $(target_noncanonical)-gcc-$(version), and also as gcc if native.
 install-driver: installdirs xgcc$(exeext)
-	-install_name=$(GCC_INSTALL_NAME); \
-	if test "@enable_as_accelerator@" = "yes" ; then \
-	  install_name=$(GCC_TARGET_INSTALL_NAME); \
-	fi; \
-	rm -f $(DESTDIR)$(bindir)/$${install_name}$(exeext); \
-	$(INSTALL_PROGRAM) xgcc$(exeext) $(DESTDIR)$(bindir)/$${install_name}$(exeext)
+	-rm -f $(DESTDIR)$(bindir)/$(GCC_INSTALL_NAME)$(exeext)
+	-$(INSTALL_PROGRAM) xgcc$(exeext) $(DESTDIR)$(bindir)/$(GCC_INSTALL_NAME)$(exeext)
 	-if test "@enable_as_accelerator@" != "yes" ; then \
-	  if [ "$(GCC_INSTALL_NAME)" != "$(tool_prefix)-gcc-$(version)" ]; then \
-	rm -f $(DESTDIR)$(bindir)/$(tool_prefix)-gcc-$(version)$(exeext); \
-	( cd $(DESTDIR)$(bindir) && \
-	  $(LN) $(GCC_INSTALL_NAME)$(exeext) $(tool_prefix)-gcc-$(version)$(exeext) ); \
-	  fi; \
-	  if [ ! -f gcc-cross$(exeext) ] \
-	 && [ "$(GCC_INSTALL_NAME)" != "$(GCC_TARGET_INSTALL_NAME)" ]; then \
-	rm -f $(DESTDIR)$(bindir)/$(tool_prefix)-gcc-tmp$(exeext); \
-	( cd $(DESTDIR)$(bindir) && \
-	  $(LN) $(GCC_INSTALL_NAME)$(exeext) $(tool_prefix)-gcc-tmp$(exeext) && \
-	  mv -f $(tool_prefix)-gcc-tmp$(exeext) $(GCC_TARGET_INSTALL_NAME)$(exeext) ); \
-	  fi; \
+	if [ "$(GCC_INSTALL_NAME)" != "$(target_noncanonical)-gcc-$(version)" ]; then \
+	  rm -f $(DESTDIR)$(bindir)/$(target_noncanonical)-gcc-$(version)$(exeext); \
+	  ( cd $(DESTDIR)$(bindir) && \
+	$(LN) $(GCC_INSTALL_NAME)$(exeext) $(target_noncanonical)-gcc-$(version)$(exeext) ); \
+	fi; \
+	if [ ! -f gcc-cross$(exeext) ] \
+	&& [ "$(GCC_INSTALL_NAME)" != "$(GCC_TARGET_INSTALL_NAME)" ]; then \
+	  rm -f $(DESTDIR)$(bindir)/$(target_noncanonical)-gcc-tmp$(exeext); \
+	  ( cd $(DESTDIR)$(bindir) && \
+	$(LN) $(GCC_INSTALL_NAME)$(exeext) $(target_noncanonical)-gcc-tmp$(exeext) && \
+	mv -f $(target_noncanonical)-gcc-tmp$(exeext) $(GCC_TARGET_INSTALL_NAME)$(exeext) ); \
+	fi; \
 	fi
 
 # Install the info files.

Re: testsuite allocators patch

[Paolo Carlini]

Hi,

On 06/27/2014 12:38 AM, Jonathan Wakely wrote:

On 26/06/14 23:21 +0200, Paolo Carlini wrote:

Hi,

I'm afraid something went badly wrong with this commit, I'm seeing 
tens of fails. See eg:


   https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg02439.html


It seems that uneq_allocator is no longer copy constructible.
Can you spot a quick fix, like a thinko, or do you think Francois has to 
look into it? I'm inclined to revert it for now, the noise is quite 
annoying...


Thanks,
Paolo.

Re: [c++-concepts] Change constraint equivalence

[Marek Polacek]

On Fri, Jun 27, 2014 at 03:22:39AM -0400, Braden Obrzut wrote:
> To bring the implementation in line with changes going into the concepts
> draft, use syntactical equivalence in place of logical equivalence when
> matching declarations.
> 
> 2014-06-27  Braden Obrzut 

Two spaces after you name.

> * gcc/cp/constraint.c (equivalent_constraints): Compare the trees
> directly
> instead of logically to bring implementation in line with standard
> changes.
> * gcc/cp/tree.c (cp_tree_equal): Handle comparison of constraints.
> * gcc/testsuite/g++.dg/concepts/equiv.C: New test.
> * gcc/testsuite/g++.dg/concepts/equiv-err.C: New test.

Please drop gcc/ and gcc/testsuite/ prefixes (the former goes to
cp/ChangeLog, the latter to testsuite/ChangeLog).

Marek

[PATCH] PR preprocessor/60723 - missing system-ness marks for macro

[Dodji Seketeli]

Hello,

When a system macro is expanded in a non-system file during
out-of-line preprocessing, it can happen that the preprocessor forgets
to emit line markers to express the system-ness status of tokens that
come after the expansion of the macro.

That can lead to situations where the entire non-system file can be
considered as being a system file and thus have its warnings be
discarded during the compilation of the resulting preprocessed file.

My understanding is that this is due to the preprocessor not
systematically detecting (and reporting) the change in system-ness of
tokens.

And this is what this patch does.  Each time the system-ness of a
given token is different from the previous token that was emitted by
the preprocessor, it emits a line marker for the sole purpose of
marking the new system-ness of the subsequent tokens to come.

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

gcc/c-family/ChangeLog:
* c-ppoutput.c (struct print::prev_was_system_token): New data
member.
(init_pp_output): Initialize it.
(maybe_print_line_1, maybe_print_line, print_line_1, print_line)
(do_line_change): Return a flag saying if a line marker was
emitted or not.
(scan_translation_unit): Detect if the system-ness of the token we
are about to emit is different from the one of the previously
emitted token.  If so, emit a line marker.  Avoid emitting
useless adjacent line markers.
(scan_translation_unit_directives_only): Adjust.

gcc/testsuite/ChangeLog:
* gcc.dg/cpp/syshdr{4,5}.{c,h}: New test files.

Signed-off-by: Dodji Seketeli 
---
 gcc/c-family/c-ppoutput.c  | 76 ++
 gcc/testsuite/gcc.dg/cpp/syshdr4.c | 24 
 gcc/testsuite/gcc.dg/cpp/syshdr4.h |  8 
 gcc/testsuite/gcc.dg/cpp/syshdr5.c | 14 +++
 gcc/testsuite/gcc.dg/cpp/syshdr5.h |  6 +++
 5 files changed, 104 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/cpp/syshdr4.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/syshdr4.h
 create mode 100644 gcc/testsuite/gcc.dg/cpp/syshdr5.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/syshdr5.h

diff --git a/gcc/c-family/c-ppoutput.c b/gcc/c-family/c-ppoutput.c
index f3b5fa4..be4b674 100644
--- a/gcc/c-family/c-ppoutput.c
+++ b/gcc/c-family/c-ppoutput.c
@@ -36,6 +36,8 @@ static struct
   unsigned char printed;   /* Nonzero if something output at line.  */
   bool first_time; /* pp_file_change hasn't been called yet.  */
   const char *src_file;/* Current source file.  */
+  bool prev_was_system_token;  /* True if the previous token was a
+  system token.*/
 } print;
 
 /* Defined and undefined macros being queued for output with -dU at
@@ -58,11 +60,11 @@ static void account_for_newlines (const unsigned char *, 
size_t);
 static int dump_macro (cpp_reader *, cpp_hashnode *, void *);
 static void dump_queued_macros (cpp_reader *);
 
-static void print_line_1 (source_location, const char*, FILE *);
-static void print_line (source_location, const char *);
-static void maybe_print_line_1 (source_location, FILE *);
-static void maybe_print_line (source_location);
-static void do_line_change (cpp_reader *, const cpp_token *,
+static bool print_line_1 (source_location, const char*, FILE *);
+static bool print_line (source_location, const char *);
+static bool maybe_print_line_1 (source_location, FILE *);
+static bool maybe_print_line (source_location);
+static bool do_line_change (cpp_reader *, const cpp_token *,
source_location, int);
 
 /* Callback routines for the parser.   Most of these are active only
@@ -156,6 +158,7 @@ init_pp_output (FILE *out_stream)
   print.outf = out_stream;
   print.first_time = 1;
   print.src_file = "";
+  print.prev_was_system_token = false;
 }
 
 /* Writes out the preprocessed file, handling spacing and paste
@@ -168,6 +171,7 @@ scan_translation_unit (cpp_reader *pfile)
 = cpp_get_options (parse_in)->lang != CLK_ASM
   && !flag_no_line_commands;
   bool in_pragma = false;
+  bool line_marker_emitted = false;
 
   print.source = NULL;
   for (;;)
@@ -200,7 +204,7 @@ scan_translation_unit (cpp_reader *pfile)
  && do_line_adjustments
  && !in_pragma)
{
- do_line_change (pfile, token, loc, false);
+ line_marker_emitted = do_line_change (pfile, token, loc, false);
  putc (' ', print.outf);
}
  else if (print.source->flags & PREV_WHITE
@@ -216,7 +220,7 @@ scan_translation_unit (cpp_reader *pfile)
  if (src_line != print.src_line
  && do_line_adjustments
  && !in_pragma)
-   do_line_change (pfile, token, loc, false);
+   line_marker_emitted = do_line_change (pfile, token, loc, false);
  putc (' ', print.outf);
}
 
@@ -228,7 +232,7 @@ scan_translation_unit (

[c++-concepts] Change constraint equivalence

[Braden Obrzut]

To bring the implementation in line with changes going into the concepts 
draft, use syntactical equivalence in place of logical equivalence when 
matching declarations.


2014-06-27  Braden Obrzut 
* gcc/cp/constraint.c (equivalent_constraints): Compare the trees 
directly
instead of logically to bring implementation in line with standard 
changes.

* gcc/cp/tree.c (cp_tree_equal): Handle comparison of constraints.
* gcc/testsuite/g++.dg/concepts/equiv.C: New test.
* gcc/testsuite/g++.dg/concepts/equiv-err.C: New test.

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 01e83ba..5a3cf4d 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1199,7 +1199,7 @@ equivalent_constraints (tree a, tree b)
   if (a == b)
 return true;
   else
-return subsumes (a, b) && subsumes (b, a);
+return cp_tree_equal (a, b);
 }
 
 // Returns true if the template declarations A and B have equivalent
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 5d88806..f1d8545 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -2775,6 +2775,10 @@ cp_tree_equal (tree t1, tree t2)
 	  && same_type_p (TREE_TYPE (TEMPLATE_PARM_DECL (t1)),
 			  TREE_TYPE (TEMPLATE_PARM_DECL (t2;
 
+case CONSTRAINT_INFO:
+  return cp_tree_equal (CI_SPELLING (t1), CI_SPELLING (t2));
+
+case REQUIRES_EXPR:
 case TEMPLATE_ID_EXPR:
   return (cp_tree_equal (TREE_OPERAND (t1, 0), TREE_OPERAND (t2, 0))
 	  && cp_tree_equal (TREE_OPERAND (t1, 1), TREE_OPERAND (t2, 1)));
diff --git a/gcc/testsuite/g++.dg/concepts/equiv-err.C b/gcc/testsuite/g++.dg/concepts/equiv-err.C
new file mode 100644
index 000..7dc8b10
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/equiv-err.C
@@ -0,0 +1,108 @@
+// { dg-options "-std=c++1y" }
+
+// Test case for determining syntactical equivalence in constraints.
+// Tests for compile time errors
+
+#include 
+
+int called;
+
+template
+  concept bool C() { return __is_class(T); }
+
+template
+  concept bool D() { return requires (T a) { { a + a } -> T }; }
+
+template
+  concept bool CD()
+  {
+return __is_class(T)
+   && requires (T a) { { a + a } -> T };
+  }
+
+template
+  requires CD()
+  void f1(T);
+
+struct S1
+{
+	void f2(CD); // { dg-error "candidate" }
+
+	static void f3(CD, CD); // { dg-error "candidate" }
+};
+
+struct S2
+{
+	S2 operator+ (const S2 &other) { return S2(); }
+};
+
+template
+struct S3
+{
+	void f4(T);
+
+	static void f5(T);
+};
+
+template
+struct S3
+{
+	void f4(T);
+
+	static void f5(T);
+};
+
+int main()
+{
+	S1 s;
+	S2 v;
+	S3 v2;
+	S3 v3;
+
+	f1(v); assert (called == 1);
+
+	s.f2(v); assert (called == 1);
+
+	S1::f3(v, v); assert (called == 1);
+
+	v2.f4(v); assert (called == 1);
+
+	S3::f5(v); assert (called == 1);
+	return 0;
+}
+
+// This template has the same atomic constraints in the same order, but is
+// not considered equivalent, so this should never get called.
+template
+  requires C() && D()
+  void f1(T)
+  {
+called = 3;
+  }
+
+template
+  requires C() && D()
+  void S1::f2(T) // { dg-error "match any" }
+  {
+called = 1;
+  }
+
+template
+  requires D()
+  void S1::f3(T, T) // { dg-error "match any" }
+  {
+called = 1;
+  }
+
+template
+  requires C()
+  void S3::f4(T)
+  {
+called = 1;
+  }
+
+template
+  void S3::f5(T)
+  {
+called = 1;
+  }
diff --git a/gcc/testsuite/g++.dg/concepts/equiv.C b/gcc/testsuite/g++.dg/concepts/equiv.C
new file mode 100644
index 000..e97d4db
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/equiv.C
@@ -0,0 +1,144 @@
+// { dg-do run }
+// { dg-options "-std=c++1y" }
+
+// Test case for determining syntactical equivalence in constraints.
+
+#include 
+
+int called;
+
+template
+  concept bool C() { return __is_class(T); }
+
+template
+  concept bool D() { return requires (T a) { { a + a } -> T }; }
+
+template
+  concept bool CD()
+  {
+return __is_class(T)
+   && requires (T a) { { a + a } -> T };
+  }
+
+template
+  requires CD()
+  void f1(T);
+void f1(auto) { called = 2; }
+
+struct S1
+{
+	void f2(C);
+	void f2(CD);
+
+	template
+	  static void f3(T, T);
+	static void f3(CD, CD);
+};
+
+struct S2
+{
+	S2 operator+ (const S2 &other) { return S2(); }
+};
+
+template
+struct S3
+{
+	void f4(T);
+
+	static void f5(T);
+};
+
+template
+struct S3
+{
+	void f4(T);
+
+	static void f5(T);
+};
+
+int main()
+{
+	S1 s;
+	S2 v;
+	S3 v2;
+	S3 v3;
+
+	f1(v); assert (called == 1);
+	f1(123); assert (called == 2);
+
+	s.f2(v); assert (called == 1);
+	s.f2(s); assert (called == 2);
+
+	S1::f3(12, 34); assert (called == 2);
+	S1::f3(v, v); assert (called == 1);
+
+	v2.f4(v); assert (called == 1);
+	v3.f4(123); assert (called == 2);
+
+	S3::f5(v); assert (called == 1);
+	S3::f5(123); assert (called == 2);
+	return 0;
+}
+
+// This template has the same atomic constraints in the same order, but is
+// not considered equivalent, so this should never get called.
+template
+  requires C() && D()
+  void f1(T)
+  {
+called = 3;
+  }
+
+void f

[PATCH] Fix undefined behavior in ira-build.c

[Jakub Jelinek]

Hi!

This fixes the most common source of the new runtime diagnostics
during bootstrap-ubsan, if num is 0, ira_object_id_map is often
0 as well.

Ok for trunk/4.9?

2014-06-27  Jakub Jelinek  

* ira-build.c (sort_conflict_id_map): Don't call
qsort if num is 0, as ira_object_id_map might be NULL.

--- gcc/ira-build.c.jj  2014-05-30 10:51:16.0 +0200
+++ gcc/ira-build.c 2014-06-26 20:21:43.428987181 +0200
@@ -2821,8 +2821,9 @@ sort_conflict_id_map (void)
   FOR_EACH_ALLOCNO_OBJECT (a, obj, oi)
ira_object_id_map[num++] = obj;
 }
-  qsort (ira_object_id_map, num, sizeof (ira_object_t),
-object_range_compare_func);
+  if (num)
+qsort (ira_object_id_map, num, sizeof (ira_object_t),
+  object_range_compare_func);
   for (i = 0; i < num; i++)
 {
   ira_object_t obj = ira_object_id_map[i];

Jakub

[RFC PATCH] -fsanitize=nonnull and -fsanitize=returns-nonnull support

[Jakub Jelinek]

Hi!

This patch implements sanitization for nonnull and returns_nonnull
attributes.
Similarly to -fsanitize=null this option disables
-fdelete-null-pointer-checks silently, and adds checks before calling
functions with declared nonnull arguments if we don't pass NULL there,
and before return in functions declared with returns_nonnull also inserts
check whether the return value is not NULL.

As GCC 4.9.0+ now aggressively optimizes based on these attributes and we've
seen several issues in real world apps, I think this is really needed.

Bootstrapped/regtested on x86_64-linux and i686-linux normally (yes,rtl
checking) and c,c++,fortran release checking bootstrap-ubsan.

Will post bugs in gcc discovered by it later.

The patch adds two new (trivial handlers) to libubsan, as it is maintained
in llvm's compiler-rt, will talk to them if they are interested in those
and what exact wording and form (AFAIK clang also added the gcc
{,returns_}nonnull attributes).  If they wouldn't be interested, guess
we could add them in a separate, gcc owned, source file in ubsan (like we
own Makefile*).

2014-06-27  Jakub Jelinek  

* flag-types.h (enum sanitize_code): Add SANITIZE_NONNULL and
SANITIZE_RETURNS_NONNULL, or them into SANITIZE_UNDEFINED.
* opts.c (common_handle_option): Handle SANITIZE_NONNULL and
SANITIZE_RETURNS_NONNULL and disable flag_delete_null_pointer_checks
for them.
* sanitizer.def (BUILT_IN_UBSAN_HANDLE_NONNULL_ARG,
BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT,
BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN,
BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN_ABORT): New.
* ubsan.c (instrument_bool_enum_load): Set *gsi back to
stmt's iterator.
(instrument_nonnull_arg, instrument_nonnull_return): New functions.
(pass_ubsan::gate): Return true even for SANITIZE_NONNULL
or SANITIZE_RETURNS_NONNULL.
(pass_ubsan::execute): Call instrument_nonnull_{arg,return}.

* c-c++-common/ubsan/nonnull-1.c: New test.
* c-c++-common/ubsan/nonnull-2.c: New test.
* c-c++-common/ubsan/nonnull-3.c: New test.
* c-c++-common/ubsan/nonnull-4.c: New test.
* c-c++-common/ubsan/nonnull-5.c: New test.

--- gcc/flag-types.h.jj 2014-06-20 23:26:24.0 +0200
+++ gcc/flag-types.h2014-06-26 14:39:44.133970103 +0200
@@ -231,10 +231,13 @@ enum sanitize_code {
   SANITIZE_FLOAT_DIVIDE = 1 << 12,
   SANITIZE_FLOAT_CAST = 1 << 13,
   SANITIZE_BOUNDS = 1 << 14,
+  SANITIZE_NONNULL = 1 << 15,
+  SANITIZE_RETURNS_NONNULL = 1 << 16,
   SANITIZE_UNDEFINED = SANITIZE_SHIFT | SANITIZE_DIVIDE | SANITIZE_UNREACHABLE
   | SANITIZE_VLA | SANITIZE_NULL | SANITIZE_RETURN
   | SANITIZE_SI_OVERFLOW | SANITIZE_BOOL | SANITIZE_ENUM
-  | SANITIZE_BOUNDS,
+  | SANITIZE_BOUNDS | SANITIZE_NONNULL
+  | SANITIZE_RETURNS_NONNULL,
   SANITIZE_NONDEFAULT = SANITIZE_FLOAT_DIVIDE | SANITIZE_FLOAT_CAST
 };
 
--- gcc/opts.c.jj   2014-06-20 23:26:23.0 +0200
+++ gcc/opts.c  2014-06-26 14:43:51.620652007 +0200
@@ -1468,6 +1468,9 @@ common_handle_option (struct gcc_options
  { "float-cast-overflow", SANITIZE_FLOAT_CAST,
sizeof "float-cast-overflow" - 1 },
  { "bounds", SANITIZE_BOUNDS, sizeof "bounds" - 1 },
+ { "nonnull", SANITIZE_NONNULL, sizeof "nonnull" - 1 },
+ { "returns-nonnull", SANITIZE_RETURNS_NONNULL,
+   sizeof "returns-nonnull" - 1 },
  { NULL, 0, 0 }
};
const char *comma;
@@ -1511,7 +1514,8 @@ common_handle_option (struct gcc_options
 
/* When instrumenting the pointers, we don't want to remove
   the null pointer checks.  */
-   if (flag_sanitize & SANITIZE_NULL)
+   if (flag_sanitize & (SANITIZE_NULL | SANITIZE_NONNULL
+| SANITIZE_RETURNS_NONNULL))
  opts->x_flag_delete_null_pointer_checks = 0;
break;
   }
--- gcc/sanitizer.def.jj2014-06-20 23:26:23.0 +0200
+++ gcc/sanitizer.def   2014-06-26 16:52:34.644801331 +0200
@@ -417,3 +417,19 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HAN
  "__ubsan_handle_out_of_bounds_abort",
  BT_FN_VOID_PTR_PTR,
  ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_ARG,
+ "__ubsan_handle_nonnull_arg",
+ BT_FN_VOID_PTR_PTRMODE,
+ ATTR_COLD_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_ARG_ABORT,
+ "__ubsan_handle_nonnull_arg_abort",
+ BT_FN_VOID_PTR_PTRMODE,
+ ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_NONNULL_RETURN,
+ "__ubsan_handle_nonnull_return",
+ BT_FN_VOID_PTR,
+