Re: Fix PR ipa/64693

[Martin Liška]

On 01/23/2015 10:26 PM, Jan Hubicka wrote:

Hello.

Following patch is a fix for PR ipa/64693, where ICF merges a pair of functions
that somehow take a references to a different functions. Unfortunately, such 
function
pointer can be used for function comparison that can break an executable.

Tested on x86_64-linux-pc and no regression is added.
Apart from that, I'm able to run tests on LTO bootstraped compiler.

Ready for trunk?
Thanks,
Martin



>From ff65c1bb4ba1593ea42aec5d6cbedf2330d8a866 Mon Sep 17 00:00:00 2001
From: mliska 
Date: Fri, 23 Jan 2015 14:58:36 +0100
Subject: [PATCH] Fix PR ipa/64693.

gcc/ChangeLog:

2015-01-23  Martin Liska  

PR ipa/64693
* ipa-icf.c (sem_function::equals_private): Handle references
for a pair of compared functions.


I think you can copy a logic whether given function needs thunk - in particular
you can still merge if functions are DECL_VIRTUAL.
I also think you have same problem with variable initializers - if you merge two
variables pointing to equivalent functions that however need different 
addresses, you
still need to prevent merging.

Honza


Hello.

If I understand correctly, the right way would be to identify all function 
merge candidates
that have address taken and create a thunk. With that restriction all function 
comparison will
be safe.

Thanks,
Martin



gcc/testsuite/ChangeLog:

2015-01-23  Martin Liska  

* gcc.dg/ipa/ipa-icf-26.c: Fix expected results.
* gcc.dg/ipa/ipa-icf-33.c: Remove reduced line.
* gcc.dg/ipa/ipa-icf-34.c: New test.
---
  gcc/ipa-icf.c | 27 +-
  gcc/testsuite/gcc.dg/ipa/ipa-icf-26.c |  3 +--
  gcc/testsuite/gcc.dg/ipa/ipa-icf-33.c |  1 -
  gcc/testsuite/gcc.dg/ipa/ipa-icf-34.c | 43 +++
  4 files changed, 70 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/ipa/ipa-icf-34.c

diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index afb5be5..4bea08d 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -525,13 +525,38 @@ sem_function::equals_private (sem_item *item,
if (decl1 != decl2)
  return return_false();

-
for (arg1 = DECL_ARGUMENTS (decl),
 arg2 = DECL_ARGUMENTS (m_compared_func->decl);
 arg1; arg1 = DECL_CHAIN (arg1), arg2 = DECL_CHAIN (arg2))
  if (!m_checker->compare_decl (arg1, arg2))
return return_false ();

+  /* Compare if this function contains any function references
+ and compare them.  */
+  cgraph_node *source_node = get_node ();
+  cgraph_node *target_node = m_compared_func->get_node ();
+  if (source_node->num_references () != target_node->num_references ())
+return return_false_with_msg ("different number of references");
+
+  ipa_ref *r1 = NULL, *r2 = NULL;
+
+  for (unsigned i = 0; i < source_node->num_references (); i++)
+{
+  symtab_node *ref1 = source_node->iterate_reference (i, r1)->referred;
+  symtab_node *ref2 = target_node->iterate_reference (i, r2)->referred;
+
+  bool is_cgraph1 = is_a (ref1);
+  bool is_cgraph2 = is_a (ref2);
+
+  if (!is_cgraph1 && !is_cgraph2)
+   continue;
+
+  if ((is_cgraph1 && is_cgraph2 && ref1 != ref2)
+ || (!is_cgraph1 && is_cgraph2)
+ || (is_cgraph1 && !is_cgraph2))
+   return return_false_with_msg ("different target of a reference");
+}
+
/* Fill-up label dictionary.  */
for (unsigned i = 0; i < bb_sorted.length (); ++i)
  {
diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-26.c 
b/gcc/testsuite/gcc.dg/ipa/ipa-icf-26.c
index 0c5a5a6..f48c040 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipa-icf-26.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-26.c
@@ -38,7 +38,6 @@ int main()
return 0;
  }

-/* { dg-final { scan-ipa-dump "Semantic equality hit:bar->foo" "icf"  } } */
  /* { dg-final { scan-ipa-dump "Semantic equality hit:remove->destroy" "icf"  
} } */
-/* { dg-final { scan-ipa-dump "Equal symbols: 2" "icf"  } } */
+/* { dg-final { scan-ipa-dump "Equal symbols: 1" "icf"  } } */
  /* { dg-final { cleanup-ipa-dump "icf" } } */
diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-33.c 
b/gcc/testsuite/gcc.dg/ipa/ipa-icf-33.c
index d7e814d..7b6a8ae 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipa-icf-33.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-33.c
@@ -23,5 +23,4 @@ int main()
  }

  /* { dg-final { scan-ipa-dump "Equal symbols: 1" "icf"  } } */
-/* { dg-final { scan-ipa-dump "Equal symbols: 1" "icf"  } } */
  /* { dg-final { cleanup-ipa-dump "icf" } } */
diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-icf-34.c 
b/gcc/testsuite/gcc.dg/ipa/ipa-icf-34.c
new file mode 100644
index 000..c8507c7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/ipa-icf-34.c
@@ -0,0 +1,43 @@
+/* { dg-do compile } */
+/* { dg-options "-O0 -fipa-icf -fdump-ipa-icf-details"  } */
+
+#include 
+#include 
+
+int callback1(int a)
+{
+  return a * a;
+}
+
+int callback2(int a)
+{
+  return a * a;
+}
+
+static int test(int (*callback) (int))
+{
+  if (callback == callback1)
+return 1;
+

[PATCHv2][wwwdocs] Mention -freport-bug in release notes

[Yury Gribov]

> On 01/16/2015 12:18 PM, Yury Gribov wrote:

This is a wwwdocs patch to changes.html to announce -freport-bug flag.

Ok to commit?


Hi all,

Second version of patch with updates from Gerald Pfeifer.

Ok to commit?

-Y
? the
Index: htdocs/gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.72
diff -u -r1.72 changes.html
--- htdocs/gcc-5/changes.html	25 Jan 2015 23:47:32 -	1.72
+++ htdocs/gcc-5/changes.html	26 Jan 2015 08:01:01 -
@@ -599,5 +599,11 @@
 The gcc-ar, gcc-nm, gcc-ranlib wrappers now
 	understand a -B option to set the compiler to use.
   
+  
+  
+When the new command-line option -freport-bug is
+  used, GCC automatically generates a developer-friendly reproducer
+  whenever an internal compiler error is encountered.
+  
 
 

RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Thu, 22 Jan 2015, Matthew Fortune wrote:

> > This is a follow-up to a change [1] in glibc. It fixes the issue [2]
> > when jal can not reach a target in different region.

 Is it not a problem that can be solved with rearranging the order of
sections in output?

> > It has been tested with DejaGnu for mips32/o32, mips64/n32 and
> > mips64/n64.

 You forgot a ChangeLog entry, the lack of which made me chase the bits 
you intend to change. :(

> > Let me know what you think.

 You need to use DLA rather than LA for n64.  This should have been caught 
in testing as a combination of the GAS warning and -Werror should have 
caused the compilation to bail out.  But perhaps this isn't covered for 
some reason.

> Otherwise for PIC the issue is dealt with by the assembler with the
> JAL  being expanded to a load from the got and indirect call through
> t9. Previously t9 would not have been set up for the callee if the code
> was built non-pic (as it would just use a JAL). That would have made
> the setup of gp somewhat pointless in the CRT_CALL_STATIC_FUNCTION
> code. I am therefore a little confused by the existing code that sets
> up GP but then it seemingly is not used unless built for PIC.

 Bear in mind MIPS used to be PIC for everything except bare iron, so you 
had to set up $gp even in executables.  Support for non-PIC abicalls is a 
relatively recent addition, so it looks to me nobody bothered to optimise 
these chunks as only executed once each and not really critical for 
performance.

 This code dates back to:

2003-01-15  Alexandre Oliva  

* config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Define so as
to set $gp before the call.

and as I have suspected it was made with multi-GOT support in mind or 
otherwise $gp could have been set up the usual way.  See the original 
submission here:

http://gcc.gnu.org/ml/gcc-patches/2003-01/msg00919.html

All this predates non-PIC abicalls by over 5 years and has only changed a 
little since the original addition.

  Maciej

Re: [ARM] Wire up the new scheduler description for the ARM Cortex-A57 processor

[Ramana Radhakrishnan]

On Mon, Jan 19, 2015 at 5:44 PM, James Greenhalgh
 wrote:
>
> On Fri, Jan 16, 2015 at 11:14:42AM +, Ramana Radhakrishnan wrote:
>>
>>
>> On 16/01/15 10:20, Marcus Shawcroft wrote:
>> > On 15 January 2015 at 09:50, James Greenhalgh  
>> > wrote:
>> >
>> >> 2015-01-15  James Greenhalgh  
>> >>
>> >>  * config/arm/cortex-a57.md: New.
>> >>  * config/aarch64/aarch64.md: Include it.
>> >>  * config/aarch64/aarch64-cores.def (cortex-a57): Tune for it.
>> >>  * config/aarch64/aarch64-tune.md: Regenerate.
>> >
>> > This is low risk and only affects aarch64 backend. I think we should
>> > take this for gcc 5, so OK.
>> >
>> > Ramana do you want this wired up for aarch32 in a followup?
>>
>> Yes please. I think as long as it works, let's just take it for 5.0. I'd
>> rather not have divergence between the backends as this just creates
>> problems for us elsewhere.
>
> Hi,
>
> OK, that patch looks like this. I know I've missed the stage 3 deadline,
> but I agree that the two back ends should not diverge too much - and
> this patch is small and gives a nice little boost to performance on
> some popular benchmarks.
>
> I've regression tested it over the weekend with no issues.
>
> OK?

This is OK as this is a tuning patch that was posted before the stage3
deadline and only wires in a pipeline description.

Ramana

>
> Cheers,
> James
>
> ---
> 2014-01-19  James Greenhalgh  
>
> * config/arm/arm-cores.def (cortex-a57): Use the new Cortex-A57
> pipeline model.
> config/arm/arm.md: Include the new Cortex-A57 model.
> (generic_sched): Don't use generic_sched when tuning for
> Cortex-A57.

[Patch][wwwdocs]Deprecate the ARM TPCS related options in gcc 5.0

[Terry Guo]

Hi there,

This patch intends to update gcc 5.0 change.html to deprecate TPCS related 
options because TPCS is obsoleted per the ABI document at 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf. 
Is it OK?

BR,
Terry

Index: htdocs/gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.72
diff -u -r1.72 changes.html
--- htdocs/gcc-5/changes.html   25 Jan 2015 23:47:32 -  1.72
+++ htdocs/gcc-5/changes.html   26 Jan 2015 03:23:35 -
@@ -501,8 +501,9 @@
The deprecated option -mwords-little-endian
has been removed.
   
-   The options relating to the old ABI -mapcs and
-  -mapcs-frame have been deprecated.
+   The options relating to the old ABI -mapcs,
+  -mapcs-frame, -mtpcs-frame and
+  -mtpcs-leaf-frame have been deprecated.
   
   The transitional options -mlra and -mno-lra
have been removed. The ARM backend now uses the local register allocator

Re: [debug-early] C++ clones and limbo DIEs

[Richard Biener]

On Fri, Jan 23, 2015 at 7:45 PM, Aldy Hernandez  wrote:
> Phew... ok, I'm a little stuck here with the interaction between dwarf2out
> and LTO, and I'm hoping y'all can shed some light.  Please bear with me
> through the verbosity, it gets clearer (I hope) near the end.
>
>
> On 01/16/2015 12:45 PM, Jason Merrill wrote:
>>
>> On 01/16/2015 12:50 PM, Aldy Hernandez wrote:

 Can you remove the first flush and just do it in the second place?
>>>
>>>
>>> If I only flush the limbo list in the second place, that's basically
>>> what mainline does, albeit abstracted into a function.  I thought the
>>> whole point was to get rid of the limbo list, or at least keep it from
>>> being a structure that has to go through LTO streaming.
>>
>>
>> It would expect it to be before free_lang_data and LTO streaming.
>
>
> The reason this wouldn't make a difference is because, as it stands, dwarf
> for the clones are not generated until final.c:
>
>   if (!DECL_IGNORED_P (current_function_decl))
> debug_hooks->function_decl (current_function_decl);
>
> which happens after free_lang_data.
>
> However, we can generate early dwarf for the clones right from the parser,
> and things _mostly_ work:

I think that is the correct thing to do.

> diff --git a/gcc/cp/optimize.c b/gcc/cp/optimize.c
> index 62e32d2..5539244 100644
> --- a/gcc/cp/optimize.c
> +++ b/gcc/cp/optimize.c
> @@ -539,6 +539,11 @@ maybe_clone_body (tree fn)
>/* Start processing the function.  */
>start_preparsed_function (clone, NULL_TREE, SF_PRE_PARSED);
>
> +  /* Generate early dwarf for the clone now that we have a body
> +for it.  */
> +   debug_hooks->early_global_decl (clone);
> +
>/* Tell cgraph if both ctors or both dtors are known to have
>  the same body.  */
>if (can_alias
>
> And I say _mostly_ work, because now local statics will have the
> DECL_ABSTRACT_P bit set, making LTO think that things live in another
> partition, and are no longer trivially needed.  For instance:
>
> struct TYPE { TYPE (int);  } ;
>
> TYPE::TYPE (int some_argument)
> {
>   static int static_p = 5;
> }
>
> With the above patch, early dwarf generation will call gen_decl_die, which
> eventually does:
>
>   /* If we're emitting a clone, emit info for the abstract instance.  */
>   if (origin || DECL_ORIGIN (decl) != decl)
> dwarf2out_abstract_function (origin
>  ? DECL_ORIGIN (origin)
>  : DECL_ABSTRACT_ORIGIN (decl));
>
> Where decl and DECL_ABSTRACT_ORIGIN(decl) are:
> (gdb) p decl
> $87 = 
> (gdb) p decl.decl_common.abstract_origin
> $88 = 
>
> Now dwarf2out_abstract_function() will set DECL_ABSTRACT_P for all the
> children of the abstract origin:
>
>   was_abstract = DECL_ABSTRACT_P (decl);
>   set_decl_abstract_flags (decl, 1);
>   dwarf2out_decl (decl);
>   if (! was_abstract)
> set_decl_abstract_flags (decl, 0);
>
> Unfortunately, this sets DECL_ABSTRACT_P for the "static_p" above, and
> refuses to unset it after the call to dwarf2out_decl.

I think the C++ FE does sth odd here by having an abstract origin that
is not abstract (If I understand you correctly here).  That is, the dwarf2out.c
code above should be able to do

  gcc_assert (was_abstract);

instead of setting abstract flags here.  Otherwise the abstract origin
wasn't and abstract origin.

Or I am completely missing something - which means LTO is wrong
to interpret DECL_ABSTRACT as it does:

/* Nonzero for a given ..._DECL node means that this node represents an
   "abstract instance" of the given declaration (e.g. in the original
   declaration of an inline function).  When generating symbolic debugging
   information, we mustn't try to generate any address information for nodes
   marked as "abstract instances" because we don't actually generate
   any code or allocate any data space for such instances.  */
#define DECL_ABSTRACT_P(NODE) \
  (DECL_COMMON_CHECK (NODE)->decl_common.abstract_flag)

The above suggests LTO is correct in not outputting the decl.

So it is either the C++ FE that is wrong in declaring this an abstract origin
or dwarf2out.c is wrong in simply making all abstract origins (and its chilren)
abstract because being an abstract origin doesn't require being abstract.

Jason?

> Through some miraculous gymnastics, LTO streams out symbols without the
> "analyzed" bit set if things are not "in partition", which happens because
> symtab_node::get_partitioning_class() returns SYMBOL_EXTERNAL (ahem, not in
> partition) when the DECL_ABSTRACT_P bit is set.
>
> So... dwarf2out_abstract_function() sets the DECL_ABSTRACT_P bit, and LTO
> thinks that local statics in a clone are in another partition, which causes
> the analyzed bit to be dropped on the floor, which causes
> symbol_table::remove_unreferenced_decls() to no longer think that local
> statics are trivially needed.  And if the local static is no longer needed,
> varpool will not output it

Re: PATCH: PR bootstrap/64754: [5 Regression] bootstrap failed with --with-build-config=bootstrap-lto

[Richard Biener]

On Fri, Jan 23, 2015 at 11:43 PM, H.J. Lu  wrote:
> Hi,
>
> r218005 added:
>
> +  /* ???  Store somewhere better.  */
> +  unsigned short ruid;
>
>
> + if (restrict_var->ruid == 0)
> +   restrict_var->ruid = ++last_ruid;
> + MR_DEPENDENCE_CLIQUE (ref) = clique;
> + MR_DEPENDENCE_BASE (ref) = restrict_var->ruid;
>
> Since ruid isn't initialized, we get random order.  This patch initializes
> ruid to 0.  Tested on Linux/x86.  OK to install?

Oops.

Ok.

Thanks,
Richard.

> Thanks.
>
>
> H.J.
> ---
> 2015-01-23  H.J. Lu  
>
> PR bootstrap/64754
> * tree-ssa-structalias.c (new_var_info): Initialize ruid.
>
> diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
> index 96d1ce3..4c43b75 100644
> --- a/gcc/tree-ssa-structalias.c
> +++ b/gcc/tree-ssa-structalias.c
> @@ -409,6 +409,7 @@ new_var_info (tree t, const char *name)
>ret->may_have_pointers = true;
>ret->only_restrict_pointers = false;
>ret->is_restrict_var = false;
> +  ret->ruid = 0;
>ret->is_global_var = (t == NULL_TREE);
>ret->is_fn_info = false;
>if (t && DECL_P (t))

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Eric Botcazou]

> While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
> some targets like i?86/x86_64 choose to populate it again during machine
> reorg and some target don't free it at the end of machine reorg.
> This patch updates cleanup_barrier pass, so that it adjusts basic block
> boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash during
> final pass.

This isn't a recent regression so what about fixing it more "properly"?  For 
example, by calling free_bb_for_insn at the end of the machinre reorg passes 
which called compute_bb_for_insn at the beginning?  Or do the affected ports 
need the BB info all the way down to final?

-- 
Eric Botcazou

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote:
> > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
> > some targets like i?86/x86_64 choose to populate it again during machine
> > reorg and some target don't free it at the end of machine reorg.
> > This patch updates cleanup_barrier pass, so that it adjusts basic block
> > boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash during
> > final pass.
> 
> This isn't a recent regression so what about fixing it more "properly"?  For 
> example, by calling free_bb_for_insn at the end of the machinre reorg passes 
> which called compute_bb_for_insn at the beginning?  Or do the affected ports 
> need the BB info all the way down to final?

Yes, they do, that is why it crashed during final.

Jakub

Re: [RFC] PR64703, glibc sysdeps/powerpc/powerpc64/dl-machine.h miscompile

[Richard Biener]

On Sat, Jan 24, 2015 at 12:23 AM, Alan Modra  wrote:
> How does this look as a potential fix for PR64703?  I haven't made
> many forays into gimple code, so even though this patch passes
> bootstrap and regression testing on powerpc64-linux it's quite
> possible this is the wrong place to change.  If it does look to be OK,
> then I'll fill out the targetm changes, include a testcase etc.

It looks mostly ok, comments below.

> PR target/64703
> * tree-ssa-alias.c (pt_solution_includes_base): New function,
> extracted from..
> (ref_maybe_used_by_call_p_1): ..here.  Delete dead code checking
> for NULL return from ao_ref_base.  Handle potential memory
> reference by indirect calls on targets using function descriptors.
>
> Index: gcc/tree-ssa-alias.c
> ===
> --- gcc/tree-ssa-alias.c(revision 220025)
> +++ gcc/tree-ssa-alias.c(working copy)
> @@ -1532,6 +1532,23 @@ refs_output_dependent_p (tree store1, tree store2)
>return refs_may_alias_p_1 (&r1, &r2, false);
>  }
>
> +static bool
> +pt_solution_includes_base (struct pt_solution *pt, tree base)

Needs a comment.

> +{
> +  if (DECL_P (base))
> +return pt_solution_includes (pt, base);
> +
> +  if ((TREE_CODE (base) == MEM_REF
> +   || TREE_CODE (base) == TARGET_MEM_REF)
> +  && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME)
> +{
> +  struct ptr_info_def *pi = SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0));
> +  if (pi)
> +   return pt_solutions_intersect (pt, &pi->pt);
> +}
> +  return true;
> +}
> +
>  /* If the call CALL may use the memory reference REF return true,
> otherwise return false.  */
>
> @@ -1542,15 +1559,24 @@ ref_maybe_used_by_call_p_1 (gcall *call, ao_ref *r
>unsigned i;
>int flags = gimple_call_flags (call);
>
> +  base = ao_ref_base (ref);

You dropped the

  if (!base)
return true;

check - please put it back.

> +  callee = gimple_call_fn (call);
> +  if (callee && TREE_CODE (callee) == SSA_NAME

Do we never propagate the address of a function descriptor here?
That is, can we generate a testcase like

   descr fn;
   
   foo (&fn);

void foo (fn)
{
   (*fn) (a, b);
}

and then inline foo so the call becomes

  (*&fn) (a, b);

?  We'd then still implicitely read from 'fn'.  I also wonder whether
(and where!) we resolve such a descriptor reference to the actual
function on GIMPLE?

That is - don't you simply want to use

  if (targetm.function_descriptors
  && ptr_deref_mayalias_ref_p_1 (callee, ref))
return true;

here?

Thanks,
Richard.

> +  /* && targetm.function_descriptors */)
> +{
> +  /* Handle indirect call.  When a target defines the address of a
> +function as that of a function descriptor, then dereferencing
> +a function pointer implicitly references memory.  */
> +  struct ptr_info_def *pi = SSA_NAME_PTR_INFO (callee);
> +  if (pi && pt_solution_includes_base (&pi->pt, base))
> +   return true;
> +}
> +
>/* Const functions without a static chain do not implicitly use memory.  */
>if (!gimple_call_chain (call)
>&& (flags & (ECF_CONST|ECF_NOVOPS)))
>  goto process_args;
>
> -  base = ao_ref_base (ref);
> -  if (!base)
> -return true;
> -
>/* A call that is not without side-effects might involve volatile
>   accesses and thus conflicts with all other volatile accesses.  */
>if (ref->volatile_p)
> @@ -1564,7 +1590,7 @@ ref_maybe_used_by_call_p_1 (gcall *call, ao_ref *r
>&& !is_global_var (base))
>  goto process_args;
>
> -  callee = gimple_call_fndecl (call);
> +  callee = gimple_call_addr_fndecl (callee);
>
>/* Handle those builtin functions explicitly that do not act as
>   escape points.  See tree-ssa-structalias.c:find_func_aliases
> @@ -1803,23 +1829,7 @@ ref_maybe_used_by_call_p_1 (gcall *call, ao_ref *r
>  }
>
>/* Check if the base variable is call-used.  */
> -  if (DECL_P (base))
> -{
> -  if (pt_solution_includes (gimple_call_use_set (call), base))
> -   return true;
> -}
> -  else if ((TREE_CODE (base) == MEM_REF
> -   || TREE_CODE (base) == TARGET_MEM_REF)
> -  && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME)
> -{
> -  struct ptr_info_def *pi = SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0));
> -  if (!pi)
> -   return true;
> -
> -  if (pt_solutions_intersect (gimple_call_use_set (call), &pi->pt))
> -   return true;
> -}
> -  else
> +  if (pt_solution_includes_base (gimple_call_use_set (call), base))
>  return true;
>
>/* Inspect call arguments for passed-by-value aliases.  */
>
> --
> Alan Modra
> Australia Development Lab, IBM

Re: [4.8] backport PR57748 fixes (wrong-code and ICE regression)

[Richard Biener]

On Sun, Jan 25, 2015 at 3:25 PM, Mikael Pettersson  wrote:
> This backports the fixes for PR middle-end/57748, a wrong-code and ICE
> regression, to the 4.8 branch.
>
> Tested extensively on x86_64, powerpc64, sparc64, ARMv{5,7}, and m68k.
>
> Ok for 4.8?

Ok - I assume you have checked that all relevant patches in this area have
been backported already?

Thanks,
Richard.

> (I don't have commit rights.)
>
> /Mikael
>
> gcc/
>
> 2015-01-25  Mikael Pettersson  
>
> Backport from mainline
>
> 2013-09-20  Bernd Edlinger  
>
> PR middle-end/57748
> * expr.c (expand_assignment): Remove misalignp code path.
>
> 2014-01-08  Bernd Edlinger  
>
> PR middle-end/57748
> * expr.h (expand_expr_real, expand_expr_real_1): Add new parameter
> inner_reference_p.
> (expand_expr, expand_normal): Adjust.
> * expr.c (expand_expr_real, expand_expr_real_1): Add new parameter
> inner_reference_p. Use inner_reference_p to expand inner references.
> (store_expr): Adjust.
> * cfgexpand.c (expand_call_stmt): Adjust.
>
> gcc/testsuite/
>
> 2015-01-25  Mikael Pettersson  
>
> Backport from mainline
>
> 2013-09-20  Bernd Edlinger  
>
> PR middle-end/57748
> * gcc.dg/torture/pr57748-1.c: New test.
> * gcc.dg/torture/pr57748-2.c: New test.
>
> 2014-01-08  Bernd Edlinger  
>
> PR middle-end/57748
> * gcc.dg/torture/pr57748-3.c: New test.
> * gcc.dg/torture/pr57748-4.c: New test.
>
> diff -rupN gcc-4.8-20150122/gcc/cfgexpand.c 
> gcc-4.8-20150122.pr57748/gcc/cfgexpand.c
> --- gcc-4.8-20150122/gcc/cfgexpand.c2014-01-07 17:49:22.0 +0100
> +++ gcc-4.8-20150122.pr57748/gcc/cfgexpand.c2015-01-25 15:00:35.240949368 
> +0100
> @@ -2111,7 +2111,7 @@ expand_call_stmt (gimple stmt)
>if (lhs)
>  expand_assignment (lhs, exp, false);
>else
> -expand_expr_real_1 (exp, const0_rtx, VOIDmode, EXPAND_NORMAL, NULL);
> +expand_expr (exp, const0_rtx, VOIDmode, EXPAND_NORMAL);
>
>mark_transaction_restart_calls (stmt);
>  }
> diff -rupN gcc-4.8-20150122/gcc/expr.c gcc-4.8-20150122.pr57748/gcc/expr.c
> --- gcc-4.8-20150122/gcc/expr.c 2014-11-28 18:06:23.0 +0100
> +++ gcc-4.8-20150122.pr57748/gcc/expr.c 2015-01-25 15:00:35.240949368 +0100
> @@ -4708,8 +4708,6 @@ expand_assignment (tree to, tree from, b
>int unsignedp;
>int volatilep = 0;
>tree tem;
> -  bool misalignp;
> -  rtx mem = NULL_RTX;
>
>push_temp_slots ();
>tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
> @@ -4728,40 +4726,7 @@ expand_assignment (tree to, tree from, b
>   && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
> get_bit_range (&bitregion_start, &bitregion_end, to, &bitpos, 
> &offset);
>
> -  /* If we are going to use store_bit_field and extract_bit_field,
> -make sure to_rtx will be safe for multiple use.  */
> -  mode = TYPE_MODE (TREE_TYPE (tem));
> -  if (TREE_CODE (tem) == MEM_REF
> - && mode != BLKmode
> - && ((align = get_object_alignment (tem))
> - < GET_MODE_ALIGNMENT (mode))
> - && ((icode = optab_handler (movmisalign_optab, mode))
> - != CODE_FOR_nothing))
> -   {
> - struct expand_operand ops[2];
> -
> - misalignp = true;
> - to_rtx = gen_reg_rtx (mode);
> - mem = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
> -
> - /* If the misaligned store doesn't overwrite all bits, perform
> -rmw cycle on MEM.  */
> - if (bitsize != GET_MODE_BITSIZE (mode))
> -   {
> - create_input_operand (&ops[0], to_rtx, mode);
> - create_fixed_operand (&ops[1], mem);
> - /* The movmisalign pattern cannot fail, else the 
> assignment
> -would silently be omitted.  */
> - expand_insn (icode, 2, ops);
> -
> - mem = copy_rtx (mem);
> -   }
> -   }
> -  else
> -   {
> - misalignp = false;
> - to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
> -   }
> +  to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
>
>/* If the bitfield is volatile, we want to access it in the
>  field's mode, not the computed mode.
> @@ -4900,17 +4865,6 @@ expand_assignment (tree to, tree from, b
>   get_alias_set (to), nontemporal);
> }
>
> -  if (misalignp)
> -   {
> - struct expand_operand ops[2];
> -
> - create_fixed_operand (&ops[0], mem);
> - create_input_operand (&ops[1], to_rtx, mode);
> - /* The movmisalign pattern cannot fail, else the assignment
> -would silently be omitted.  */
> - expand_insn (icode, 2, ops);
> -   }
> -
>if (result)
> preserve_temp_slots (result);
>pop_temp_slots ();
> @@ -5262,7 +5

Re: [PATCH] Fix half of PR63439

[Eric Botcazou]

> For the second half we really need to fix SPARC to be a vect64
> target (the testcase is vectorized with v8qi).

Yes, that makes sense in conjunction with the options used for vectorization.

-- 
Eric Botcazou

Re: [PATCH] Fix half of PR63439

[Richard Biener]

On Mon, 26 Jan 2015, Eric Botcazou wrote:

> > For the second half we really need to fix SPARC to be a vect64
> > target (the testcase is vectorized with v8qi).
> 
> Yes, that makes sense in conjunction with the options used for vectorization.

As I can't test sparc can you or rainer do the change and see if it
works fine?

Thanks,
Richard.

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 10:11:00AM +0100, Jakub Jelinek wrote:
> On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote:
> > > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
> > > some targets like i?86/x86_64 choose to populate it again during machine
> > > reorg and some target don't free it at the end of machine reorg.
> > > This patch updates cleanup_barrier pass, so that it adjusts basic block
> > > boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash during
> > > final pass.
> > 
> > This isn't a recent regression so what about fixing it more "properly"?  
> > For 
> > example, by calling free_bb_for_insn at the end of the machinre reorg 
> > passes 
> > which called compute_bb_for_insn at the beginning?  Or do the affected 
> > ports 
> > need the BB info all the way down to final?
> 
> Yes, they do, that is why it crashed during final.

In particular, all the i386/x86_64 atom tuning AGU stuff depends on it
heavily, but e.g. ix86_ok_to_clobber_flags and various others too.

Jakub

Re: [RFC] POWER8 default for PPC64LE

[Jakub Jelinek]

On Sat, Jan 17, 2015 at 09:18:14PM -0500, David Edelsohn wrote:
> Thanks, David
> 
> * config/rs6000/default64.h: Include rs6000-cpus.def.
> (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8).
> * config/rs6000/driver-rs6000.c (detect_processor_aix): Add POWER7.
> * config/rs6000/linux64.h: Always default to POWER8.
> * config/rs6000/rs6000.c (rs6000_file_start): Emit .machine
> pseudo-op to specify assembler dialect.

Unfortunately, this broke all qi/hi mode atomics on ppc64le, when configured
--with-cpu=power7 --with-tune=power8.
The problem is that TARGET_SYNC_HI_QI is defined as
TARGET_QUAD_MEMORY || TARGET_QUAD_MEMORY_ATOMIC || TARGET_DIRECT_MOVE
and from these 3, despite the configured default or even explicit
-mcpu=power7 the second one was never cleared.

The following patch seems to fix it, ok for trunk if testing passes?

What about release branches?

2015-01-26  Jakub Jelinek  

* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add
OPTION_MASK_QUAD_MEMORY_ATOMIC.

--- gcc/config/rs6000/rs6000-cpus.def.jj2015-01-05 13:07:17.0 
+0100
+++ gcc/config/rs6000/rs6000-cpus.def   2015-01-26 10:41:54.267031985 +0100
@@ -93,6 +93,7 @@
 | OPTION_MASK_PPC_GFXOPT   \
 | OPTION_MASK_PPC_GPOPT\
 | OPTION_MASK_QUAD_MEMORY  \
+| OPTION_MASK_QUAD_MEMORY_ATOMIC   \
 | OPTION_MASK_RECIP_PRECISION  \
 | OPTION_MASK_SOFT_FLOAT   \
 | OPTION_MASK_STRICT_ALIGN_OPTIONAL\


Jakub

[PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Hale Wang]

Hi,

The GCC combine pass combines the insns even though they contain volatile
registers. This doesn't make sence.

The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164
shows the expected asm command "mov r1, r1" is not generated."r1" is defined
as a volatile register, and there are three insns related to r1:

(insn 98 97 40 3 (set (reg/v:SI 1 r1 [ b ]) (reg:SI 154 [ b ])) 
(insn 41 40 43 3 (set (reg/f:SI 148)(reg/v:SI 1 r1 [ b ]))
(insn 43 41 45 3 (parallel [
(set (reg/v:SI 0 r0 [ ret ])
(asm_operands/v:SI ("mov %2, %2  mov %3, %3  mov %4, %4")
("=r") 0 [
(reg/v:SI 0 r0 [ a ])
(reg/v:SI 1 r1 [ b ])
(reg/v:SI 2 r2 [ c ])
(mem/c:QI (reg/f:SI 148) [0 MEM[(char *)&temp]+0 S1
A8])

The combine pass combine these insns:

(note 98 97 40 3 NOTE_INSN_DELETED)
(note 41 40 43 3 NOTE_INSN_DELETED)
(insn 43 41 45 3 (parallel [
(set (reg/v:SI 0 r0 [ ret ])
(asm_operands/v:SI ("mov %2, %2  mov %3, %3  mov %4, %4")
("=r") 0 [
(reg/v:SI 0 r0 [ a ])
(reg:SI 154 [ b ])
(reg/v:SI 2 r2 [ c ])
(mem/c:QI (reg:SI 154 [ b ]) [0 MEM[(char *)&temp]+0
S1 A8])


The volatile register "r1" is totally disappeared in the asm_operands, and
the generated asm code is unexpected.

This patch is used to disable the combine operation if the insns contain
volatile registers. A new test case is also added in this patch.

Is it OK for trunk?

BR,
Hale Wang

ChangeLog:

2015-01-22  Hale Wang  

PR middle-end/46164
* combine.c (can_combine_p): Don't combine the insns if
a volatile register is contained.

2015-01-22  Hale Wang  

PR middle-end/46164
* gcc.target/arm/pr46164.c: New test.


diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..cf48666 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2004,6 +2004,13 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn
*pred ATTRIBUTE_UNUSED,
  return 0;
}
 
+  /* If src contains a volatile register, reject, because the register may
+ possibly be used in a asm operand.  The combined insn may cause the
asm
+ operand to be generated unexpectly.  */
+
+  if (REG_P (src) && REG_USERVAR_P (src))
+return 0;
+
   /* If INSN contains anything volatile, or is an `asm' (whether volatile
  or not), reject, unless nothing volatile comes between it and I3 */
 
diff --git a/gcc/testsuite/gcc.target/arm/pr46164.c
b/gcc/testsuite/gcc.target/arm/pr46164.c
new file mode 100644
index 000..ad3b7cb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr46164.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-mcpu=cortex-m3 -mthumb -O1" } */
+
+char temp[16];
+extern int foo1 (void);
+
+void foo (void)
+{
+  int i;
+  int len;
+
+  while (1)
+  {
+len = foo1 ();
+register char *a asm ("r1") = temp;
+asm volatile ("mov %[r1], %[r1]\n " :: [r1]"r"(a), "m"(*a));
+
+for (i = 0; i < len; i++)
+{
+  if (temp[i] == 10)
+  return;
+}
+  }
+}
+
+/* { dg-final { scan-assembler "\[\\t \]+mov\ r1,\ r1" } } */

pr46164-combine-volatile-register.patch-3
Description: Binary data

Fix PR testsuite/64712

[Eric Botcazou]

It's an uninitialized variable in a testcase I added back in 2008 that had 
been silent until we started to generate overflow checks by default.

Tested on x86_64-suse-linux, applied on the mainline and 4.9 branch.


2015-01-26  Eric Botcazou  

PR testsuite/64712
* gnat.dg/unchecked_convert1.adb (Unchecked_Convert1): Initialize A.


-- 
Eric BotcazouIndex: gnat.dg/unchecked_convert1.adb
===
--- gnat.dg/unchecked_convert1.adb	(revision 220008)
+++ gnat.dg/unchecked_convert1.adb	(working copy)
@@ -4,6 +4,7 @@
 with Ada.Unchecked_Conversion;
 
 procedure Unchecked_Convert1 is
+
   type Byte is mod 2**8;
 
   type Stream is array (Natural range <>) of Byte;
@@ -24,9 +25,10 @@ procedure Unchecked_Convert1 is
 return Do_Sum (To_Chunk (S(S'First ..  S'First + Rec'Size / 8 - 1)));
   end;
 
-  A : Stream (1..9);
+  A : Stream (1..9) := (others => 0);
   I : Integer;
 
 begin
+  A (9) := 1;
   I := Sum (A(1..8));
 end;

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Andrew Pinski]

On Mon, Jan 26, 2015 at 1:55 AM, Hale Wang  wrote:
> Hi,
>
> The GCC combine pass combines the insns even though they contain volatile
> registers. This doesn't make sence.
>
> The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164
> shows the expected asm command "mov r1, r1" is not generated."r1" is defined
> as a volatile register, and there are three insns related to r1:
>
> (insn 98 97 40 3 (set (reg/v:SI 1 r1 [ b ]) (reg:SI 154 [ b ]))
> (insn 41 40 43 3 (set (reg/f:SI 148)(reg/v:SI 1 r1 [ b ]))
> (insn 43 41 45 3 (parallel [
> (set (reg/v:SI 0 r0 [ ret ])
> (asm_operands/v:SI ("mov %2, %2  mov %3, %3  mov %4, %4")
> ("=r") 0 [
> (reg/v:SI 0 r0 [ a ])
> (reg/v:SI 1 r1 [ b ])
> (reg/v:SI 2 r2 [ c ])
> (mem/c:QI (reg/f:SI 148) [0 MEM[(char *)&temp]+0 S1
> A8])
> 
> The combine pass combine these insns:
>
> (note 98 97 40 3 NOTE_INSN_DELETED)
> (note 41 40 43 3 NOTE_INSN_DELETED)
> (insn 43 41 45 3 (parallel [
> (set (reg/v:SI 0 r0 [ ret ])
> (asm_operands/v:SI ("mov %2, %2  mov %3, %3  mov %4, %4")
> ("=r") 0 [
> (reg/v:SI 0 r0 [ a ])
> (reg:SI 154 [ b ])
> (reg/v:SI 2 r2 [ c ])
> (mem/c:QI (reg:SI 154 [ b ]) [0 MEM[(char *)&temp]+0
> S1 A8])
> 
>
> The volatile register "r1" is totally disappeared in the asm_operands, and
> the generated asm code is unexpected.


I think it is allowed to the second combining, just not the first.
Also it is not about volatile registers here but rather user specified
registers into inline-asm.
Also I thought can_combine_p would reject combing into an inline-asm
to prevent this issue.

Thanks,
Andrew

>
> This patch is used to disable the combine operation if the insns contain
> volatile registers. A new test case is also added in this patch.
>
> Is it OK for trunk?
>
> BR,
> Hale Wang
>
> ChangeLog:
>
> 2015-01-22  Hale Wang  
>
> PR middle-end/46164
> * combine.c (can_combine_p): Don't combine the insns if
> a volatile register is contained.
>
> 2015-01-22  Hale Wang  
>
> PR middle-end/46164
> * gcc.target/arm/pr46164.c: New test.
>
>
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 5c763b4..cf48666 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -2004,6 +2004,13 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn
> *pred ATTRIBUTE_UNUSED,
>   return 0;
> }
>
> +  /* If src contains a volatile register, reject, because the register may
> + possibly be used in a asm operand.  The combined insn may cause the
> asm
> + operand to be generated unexpectly.  */
> +
> +  if (REG_P (src) && REG_USERVAR_P (src))
> +return 0;
> +
>/* If INSN contains anything volatile, or is an `asm' (whether volatile
>   or not), reject, unless nothing volatile comes between it and I3 */
>
> diff --git a/gcc/testsuite/gcc.target/arm/pr46164.c
> b/gcc/testsuite/gcc.target/arm/pr46164.c
> new file mode 100644
> index 000..ad3b7cb
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pr46164.c
> @@ -0,0 +1,26 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mcpu=cortex-m3 -mthumb -O1" } */
> +
> +char temp[16];
> +extern int foo1 (void);
> +
> +void foo (void)
> +{
> +  int i;
> +  int len;
> +
> +  while (1)
> +  {
> +len = foo1 ();
> +register char *a asm ("r1") = temp;
> +asm volatile ("mov %[r1], %[r1]\n " :: [r1]"r"(a), "m"(*a));
> +
> +for (i = 0; i < len; i++)
> +{
> +  if (temp[i] == 10)
> +  return;
> +}
> +  }
> +}
> +
> +/* { dg-final { scan-assembler "\[\\t \]+mov\ r1,\ r1" } } */

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote:
> The GCC combine pass combines the insns even though they contain volatile
> registers. This doesn't make sence.
> 
> The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164
> shows the expected asm command "mov r1, r1" is not generated."r1" is defined
> as a volatile register, and there are three insns related to r1:

There is nothing volatile on reg/v, that is just a flag that the
corresponding variable has been declared by the user.  Preventing that to be
combined would be a serious regression on code quality.

Jakub

Re: [PATCH] Fix half of PR63439

[Rainer Orth]

Richard Biener  writes:

> On Mon, 26 Jan 2015, Eric Botcazou wrote:
>
>> > For the second half we really need to fix SPARC to be a vect64
>> > target (the testcase is vectorized with v8qi).
>> 
>> Yes, that makes sense in conjunction with the options used for vectorization.
>
> As I can't test sparc can you or rainer do the change and see if it
> works fine?

Here's what I had in my local tree during last weekend's bootstraps: it
worked fine indeed.

Rainer


2015-01-23  Rainer Orth  

* lib/target-supports.exp (check_effective_target_vect64): Add
sparc*-*-*.

# HG changeset patch
# Parent 986c36eb0740934e43a3e296f442719f5cea7d28
Make SPARC a vect64 target

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4566,7 +4566,8 @@ proc check_effective_target_vect64 { } {
 set et_vect64_saved 0
 if { ([istarget arm*-*-*]
 	  && [check_effective_target_arm_neon_ok]
-	  && [check_effective_target_arm_little_endian]) } {
+	  && [check_effective_target_arm_little_endian])
+ || [istarget sparc*-*-*] } {
set et_vect64_saved 1
 }
 }

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

Re: [PATCH] Fix half of PR63439

[Eric Botcazou]

> Here's what I had in my local tree during last weekend's bootstraps: it
> worked fine indeed.
> 
>   Rainer
> 
> 
> 2015-01-23  Rainer Orth  
> 
>   * lib/target-supports.exp (check_effective_target_vect64): Add
>   sparc*-*-*.

Fine with me then, thanks.

-- 
Eric Botcazou

Re: [wwwdocs] C++ SD-6 feature test column for cxx0x.html and cxx1y.html

[Gerald Pfeifer]

On Sunday 2015-01-25 23:10, Ed Smith-Rowland wrote:

Here is a new patch (no change from previous)..

If you could apply it that would be great.


Sure thing.  Applied right away.

Gerald

Re: [patch] [C++14] Implement N3657: heterogeneous lookup in associative containers.

[Jonathan Wakely]

On 24/01/15 22:46 +, Jonathan Wakely wrote:

On 24/01/15 23:03 +0100, François Dumont wrote:
types. I am also surprised that it is not using enable_if, IMHO it 
makes the code clearer.


It doesn't work though.


@@ -1155,9 +1150,8 @@
  return _S_iter(__y);
}

-  template::type>
-   iterator
+  template
+   enable_if_t<__has_is_transparent<_Compare>::value, iterator>
_M_find_tr(const _Kt& __k)


This doesn't work.

Consider:

#include 

struct I
{
  int i;
  operator int() const { return i; }
};

int main()
{
  std::set s;
  I i = { };
  s.find(i);
}

(I will add something like this to the testsuite.)


Done with this patch, tested x86_64-linux and committed to trunk.

commit ba331e783334feb20f30f1b92a93d8c9d8f895be
Author: Jonathan Wakely 
Date:   Mon Jan 26 10:43:16 2015 +

	* testsuite/23_containers/set/operations/2.cc: Add test for
	non-transparent comparison function.

diff --git a/libstdc++-v3/testsuite/23_containers/set/operations/2.cc b/libstdc++-v3/testsuite/23_containers/set/operations/2.cc
index 752bc7d..84ddd1f 100644
--- a/libstdc++-v3/testsuite/23_containers/set/operations/2.cc
+++ b/libstdc++-v3/testsuite/23_containers/set/operations/2.cc
@@ -128,6 +128,22 @@ test05()
   VERIFY( Cmp::count == 0);
 }
 
+void
+test06()
+{
+  // https://gcc.gnu.org/ml/libstdc++/2015-01/msg00176.html
+  // Verify the new function template overloads do not cause problems
+  // when the comparison function is not transparent.
+  struct I
+  {
+int i;
+operator int() const { return i; }
+  };
+
+  std::set s;
+  I i = { };
+  s.find(i);
+}
 
 int
 main()
@@ -137,4 +153,5 @@ main()
   test03();
   test04();
   test05();
+  test06();
 }

Re: [Patch][wwwdocs]Deprecate the ARM TPCS related options in gcc 5.0

[Gerald Pfeifer]

On Monday 2015-01-26 16:47, Terry Guo wrote:
> This patch intends to update gcc 5.0 change.html to deprecate TPCS 
> related options because TPCS is obsoleted per the ABI document at 
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf. 
> Is it OK?

>From a language perspective I suggest to say "The options <> related to the old ABI..." or "The options related
to the old ABI -- <> -- ...", where I somewhat
prefer the former.

Please wait for Richard or Ramana for final review and approval.

Gerald

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Steven Bosscher]

On Mon, Jan 26, 2015 at 10:11 AM, Jakub Jelinek wrote:
> On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote:
>> > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
>> > some targets like i?86/x86_64 choose to populate it again during machine
>> > reorg and some target don't free it at the end of machine reorg.
>> > This patch updates cleanup_barrier pass, so that it adjusts basic block
>> > boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash during
>> > final pass.
>>
>> This isn't a recent regression so what about fixing it more "properly"?  For
>> example, by calling free_bb_for_insn at the end of the machinre reorg passes
>> which called compute_bb_for_insn at the beginning?  Or do the affected ports
>> need the BB info all the way down to final?
>
> Yes, they do, that is why it crashed during final.

And they should not do so. It cannot be relied upon, in general. Even
now, recomputing BLOCK_FOR_INSN only works because machine reorg is
the first pass after free_cfg (so nothing has changed yet to the insns
stream).

Some ports (including x86_64/i386, ia64, and most non-sched_dbr ports)
could simply do away with free_cfg and cleanup_barriers. But some
ports put things into the insns stream after free_cfg that
verify_flow_info chokes on, e.g. the fake insns for const pools for
ARM (that causes bugs elsewhere also, see e.g.
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg02101.html). The current
situation is confusing and bound to give bugs sooner or later...

I had patches to have an "early" and "late" free_cfg pass -- I think I
even posted them and I still believe that's the right short-term
solution -- to make sure nobody can put something between free_cfg and
a target with a machine_reorg that needs the CFG, or at least
BLOCK_FOR_INSN.

Oh well...

Ciao!
Steven

Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

[Gerald Pfeifer]

On Friday 2015-01-23 17:44, David Malcolm wrote:
> The following patch builds and installs the JIT documentation for
> the website (just HTML for now).
> 
> It's tricky to test (I don't have a copy of /www/gcc/bin/preprocess),
> but I was able to use this to generate sane-looking documentation,
> both for the .texi files, and for the JIT documentation.

You can easily get the preprocess script by checking out wwwdocs,
cf. https://gcc.gnu.org/about.html.

That still will require MetaHTML which, sadly, became an abandoned
FSF project, and will require a hack or two to build, so let's just
go with your patch.

A few notes, though:

> maintainer-scripts/ChangeLog:
>   PR jit/64257
>   * update_web_docs_svn: Don't delete gcc/jit/docs,
>   since the jit docs are not .tex files (Makefile, .rst and
>   .png).  Special-case the building of the JIT docs (using
>   sphinx-build).  Special-case copying them up (since they
>   contain .css, .js and .png files in addition to .html, and
>   have nested subdirectories).

The "since" should be part of the code, not the ChangeLog.

> diff --git a/maintainer-scripts/update_web_docs_svn 
> b/maintainer-scripts/update_web_docs_svn
> index c661220..c7eb890 100755
> --- a/maintainer-scripts/update_web_docs_svn
> +++ b/maintainer-scripts/update_web_docs_svn
> +# The JIT is a special-case, using sphinx rather than texinfo.

special case

> +# The jit Makefile uses "sphinx-build", which is packaged in
> +# Fedora and EPEL 6 within "python-sphinx".

JIT (above) vs jit (here)?

How about saying "...packaged in "python-sphinx" in Fedora and
EPEL 6 and in "python-Sphinx" in openSUSE"?

> +# Again, the jit is a special case, with nested subdirectories
> +# below "jit", and with some non-HTML files (.png images from us,
> +# plus .js and .css supplied by sphinx).
> +for file in $(find jit \
> +-name "*.html" -o -name "*.css" \
> +-o -name "*.js" -o -name "*.png"); do

This looks like a Bash-ism.  Can you use backticks of something
like 

  find ... | while read file; ...

?

> +cp $file $DOCSDIR/$file

Just "cp $file $DOCSDIR/" ?  This one may be a better of style,
but is easier to tweak in case we need to quote later on, for
example.

Gerald

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 12:35:30PM +0100, Steven Bosscher wrote:
> On Mon, Jan 26, 2015 at 10:11 AM, Jakub Jelinek wrote:
> > On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote:
> >> > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
> >> > some targets like i?86/x86_64 choose to populate it again during machine
> >> > reorg and some target don't free it at the end of machine reorg.
> >> > This patch updates cleanup_barrier pass, so that it adjusts basic block
> >> > boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash 
> >> > during
> >> > final pass.
> >>
> >> This isn't a recent regression so what about fixing it more "properly"?  
> >> For
> >> example, by calling free_bb_for_insn at the end of the machinre reorg 
> >> passes
> >> which called compute_bb_for_insn at the beginning?  Or do the affected 
> >> ports
> >> need the BB info all the way down to final?
> >
> > Yes, they do, that is why it crashed during final.
> 
> And they should not do so. It cannot be relied upon, in general. Even
> now, recomputing BLOCK_FOR_INSN only works because machine reorg is
> the first pass after free_cfg (so nothing has changed yet to the insns
> stream).
> 
> Some ports (including x86_64/i386, ia64, and most non-sched_dbr ports)
> could simply do away with free_cfg and cleanup_barriers. But some
> ports put things into the insns stream after free_cfg that
> verify_flow_info chokes on, e.g. the fake insns for const pools for
> ARM (that causes bugs elsewhere also, see e.g.
> https://gcc.gnu.org/ml/gcc-patches/2011-07/msg02101.html). The current
> situation is confusing and bound to give bugs sooner or later...
> 
> I had patches to have an "early" and "late" free_cfg pass -- I think I
> even posted them and I still believe that's the right short-term
> solution -- to make sure nobody can put something between free_cfg and
> a target with a machine_reorg that needs the CFG, or at least
> BLOCK_FOR_INSN.

Sure, we have targets which need cfg late, and targets which don't, and
targets which do need it only diring machine reorg and not afterwards.

pass_free_cfg doesn't do just free_bb_for_insn though, it also adds
a note for hot cold partitioning, and for DBR targets other stuff, though
DBR targets are likely helpless with keeping CFG till the end.

What my patch does is still compatible with removing that
free_bb_for_insn call from pass_free_cfg::execute if some flag is set
in targetm, it teaches the pass to handle cfg if it is around.

I agree that freeing the cfg and immediately computing it again doesn't make
sense, but I just don't see this patch being incompatible with that.

Jakub

[PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

[Robert Suchanek]

Hi,

Here is a patch to clean up a large number of reported failures when a toolchain
is configured with --with-nan=2008 for mips*-linux-gnu triplet and clean up a 
failures
for mips-img-linux-gnu where nan2008 is set by the default.

In the former case, regression involves testing e.g. -mips4 with default 
options which
causes emission of warnings that the -mips4 architecture does not support 
nan2008, and
hence, the test is classified as a fail ("test for excess errors" type of 
error).
The patch implies -mnan=legacy switch for all tests that are run for ISA rev < 
2.

In the latter case, even if we decrease the ISA level for incompatible options 
for
the loongson vector extension tests, especially loongson-simd.c, a test that 
includes
stdint.h or stdlib.h will end up including the glibc header 'stubs-.h>' 
and will
fail as the mipsr6 toolchain will only have stubs-o32_hard_2008.h. A toolchain 
supporting
nan1985 will have the required stubs-o32_hard.h. The only neat solution AFAICS 
was to add
a new effective target that tries to compile and include stdlib.h to check if 
we have
the proper support for the legacy NaN marking the concerned tests as 
UNSUPPORTED. 

Regards,
Robert

2015-01-26  Robert Suchanek  

gcc/testsuite
* lib/target-supports.exp (check_effective_target_mips_nanlegacy): New.
* gcc.target/mips/loongson-simd.c: Require legacy NaN support.
* gcc.target/mips/mips.exp (mips-dg-options): Imply -mnan=legacy for
ISA rev < 2.
---
 gcc/testsuite/gcc.target/mips/loongson-simd.c |1 +
 gcc/testsuite/gcc.target/mips/mips.exp|1 +
 gcc/testsuite/lib/target-supports.exp |9 +
 3 files changed, 11 insertions(+)

diff --git a/gcc/testsuite/gcc.target/mips/loongson-simd.c 
b/gcc/testsuite/gcc.target/mips/loongson-simd.c
index 160da6b..949632e 100644
--- a/gcc/testsuite/gcc.target/mips/loongson-simd.c
+++ b/gcc/testsuite/gcc.target/mips/loongson-simd.c
@@ -22,6 +22,7 @@ along with GCC; see the file COPYING3.  If not see
 /* loongson.h does not handle or check for MIPS16ness or
microMIPSness.  There doesn't seem any good reason for it to, given
that the Loongson processors do not support either.  */
+/* { dg-require-effective-target mips_nanlegacy } */
 /* { dg-options "isa=loongson -mhard-float -mno-micromips -mno-mips16 
-flax-vector-conversions" } */
 
 #include "loongson.h"
diff --git a/gcc/testsuite/gcc.target/mips/mips.exp 
b/gcc/testsuite/gcc.target/mips/mips.exp
index b81d344..a0980a9 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -1300,6 +1300,7 @@ proc mips-dg-options { args } {
mips_make_test_option options "-mno-dsp"
mips_make_test_option options "-mno-synci"
mips_make_test_option options "-mno-micromips"
+   mips_make_test_option options "-mnan=legacy"
}
 if { $isa_rev > 5 } {
mips_make_test_option options "-mno-dsp"
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index e51d07d..de2f599 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3036,6 +3036,15 @@ proc check_effective_target_mips_loongson { } {
 }]
 }
 
+# Return 1 if this is a MIPS target that supports the legacy NAN.
+
+proc check_effective_target_mips_nanlegacy { } {
+return [check_no_compiler_messages nanlegacy assembly {
+   #include 
+   int main () { return 0; }
+} "-mnan=legacy"]
+}
+
 # Return 1 if this is an ARM target that adheres to the ABI for the ARM
 # Architecture.
 
-- 
1.7.9.5

Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

[Tejas Belagod]

On 25/01/15 21:05, Christophe Lyon wrote:

On 23 January 2015 at 14:44, Christophe Lyon  wrote:

On 23 January 2015 at 12:42, Christophe Lyon  wrote:

On 23 January 2015 at 11:18, Tejas Belagod  wrote:

On 22/01/15 21:31, Christophe Lyon wrote:


On 22 January 2015 at 16:22, Tejas Belagod  wrote:


On 22/01/15 14:28, Christophe Lyon wrote:



On 22 January 2015 at 12:19, Tejas Belagod 
wrote:



On 21/01/15 15:07, Christophe Lyon wrote:




On 19 January 2015 at 17:54, Marcus Shawcroft
 wrote:




On 19 January 2015 at 15:43, Christophe Lyon

wrote:




On 19 January 2015 at 14:29, Marcus Shawcroft
 wrote:




On 16 January 2015 at 17:52, Christophe Lyon
 wrote:


OK provided, as per the previous couple, that we don;t regression
or
introduce new fails on aarch64[_be] or aarch32.





This patch shows failures on aarch64 and aarch64_be for vmax and
vmin
when the input is -NaN.
It's a corner case, and my reading of the ARM ARM is that the
result
should the same as on aarch32.
I haven't had time to look at it in more details though.
So, not OK?





They should have the same behaviour in aarch32 and aarch64. Did you
test on HW or a model?


I ran the tests on qemu for aarch32 and aarch64-linux, and on the
foundation model for aarch64*-elf.





Leave this one out until we understand why it fails. /Marcus





I've looked at this a bit more.
We have
fmaxv0.4s, v0.4s, v1.4s
where v0 is a vector of -NaN (0xffc0) and v1 is a vector of 1.

The output is still -NaN (0xffc0), while the test expects
defaultNaN (0x7fc0).



In the AArch32 execution state, Advanced SIMD FP arithmetic always uses
the
DefaultNaN setting regardless of the DN-bit value in the FPSCR. In
AArch64
execution state, result of Advanced SIMD FP arithmetic operations
depend
on
the value of the DN-bit i.e. either propagate the input NaN or generate
DefaultNaN depending on the value of DN.




Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I
can see only the latter (no diff between aarch32 and aarch64 in
FPProcessNan pseudo-code)



If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec -
under DN:

"The value of this bit only controls scalar floating-point arithmetic.
Advanced SIMD arithmetic always uses the Default NaN setting, regardless
of
the value of the DN bit."

Also on page 3180 for the description of VMAX(vector FP), it says:
"
*  max(+0.0, -0.0) = +0.0
* If any input is a NaN, the corresponding result element is the default
NaN.
"


Oops I was looking at FMAX (vector) pg 936.


The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to
FPMax() which is on pg. 2285

// StandardFPSCRValue()
// 
FPCRType StandardFPSCRValue()
return ‘0’ : FPSCR.AHP : ‘11’

Here bit-25(FPSCR.DN) is set to 1.



So, we should get defaultNaN too on aarch64, and no need to try to
force DN to 1 in gdb?

What can be wrong?



On pg 3180, I see VMAX(FPSIMD) for A32/T32, not A64. I hope we're reading
the same document.

Regardless of the page number, if you see the pseudocode for VMAX(FPSIMD)
for AArch32, StandardFPSCRValue() (i.e. DN = 1) is passed to FPMax() which
means generate DefaultNaN() regardless.

OTOH, on pg 936, you have FMAX(vector) for A64 where FPMax() in the
pseudocode gets just FPCR.



Ok, that was my initial understanding but our discussion confused me.

And that's why I tried to force DN = 1 in gdb before single-stepping over
fmaxv0.4s, v0.4s, v1.4s

but it changed nothing :-(
Hence my question about a gdb possible bug or misuse.


Hmm... user error, I missed one bit
set $fpcr=0x200
works under gdb.


I'll try modifying the test to have it force DN=1.


Forcing DN=1 in the test makes it pass.

I am going to look at adding that cleanly to my test, and resubmit it.

Thanks, and sorry for the noise.


Here is the updated version:
- Now I set DN=1 on AArch64 in clean_results, as it is the main
initialization function.
- I removed the double negative :-)
- I removed the useless [u]int64 and poly variants

Christophe.

2015-01-25  Christophe Lyon  

* gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
(_ARM_FPSRC): Add DN and AHP fields.
(clean_results): Force DN=1 on AArch64.
* gcc.target/aarch64/advsimd-intrinsics/binary_op_no64.inc: New file.
* gcc.target/aarch64/advsimd-intrinsics/vhadd.c: New file.
* gcc.target/aarch64/advsimd-intrinsics/vhsub.c: New file.
* gcc.target/aarch64/advsimd-intrinsics/vmax.c: New file.
* gcc.target/aarch64/advsimd-intrinsics/vmin.c: New file.
* gcc.target/aarch64/advsimd-intrinsics/vrhadd.c: New file.



I guess you don't need the fake dependency fix for this as this is 
mostly called only once?


+  _ARM_FPSCR _afpscr_for_dn;
+  asm volatile ("mrs %0,fpcr" : "=r" (_afpscr_for_dn));
+  _afpscr_for_dn.b.DN = 1;
+  asm volatile ("msr fpcr,%0" : : "r" (_afpscr_for_dn));

Otherwise, your patch looks OK to me(but I can't approve it).

Thanks,
Tejas.

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Richard Biener]

On Mon, Jan 26, 2015 at 12:47 PM, Jakub Jelinek  wrote:
> On Mon, Jan 26, 2015 at 12:35:30PM +0100, Steven Bosscher wrote:
>> On Mon, Jan 26, 2015 at 10:11 AM, Jakub Jelinek wrote:
>> > On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote:
>> >> > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
>> >> > some targets like i?86/x86_64 choose to populate it again during machine
>> >> > reorg and some target don't free it at the end of machine reorg.
>> >> > This patch updates cleanup_barrier pass, so that it adjusts basic block
>> >> > boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash 
>> >> > during
>> >> > final pass.
>> >>
>> >> This isn't a recent regression so what about fixing it more "properly"?  
>> >> For
>> >> example, by calling free_bb_for_insn at the end of the machinre reorg 
>> >> passes
>> >> which called compute_bb_for_insn at the beginning?  Or do the affected 
>> >> ports
>> >> need the BB info all the way down to final?
>> >
>> > Yes, they do, that is why it crashed during final.
>>
>> And they should not do so. It cannot be relied upon, in general. Even
>> now, recomputing BLOCK_FOR_INSN only works because machine reorg is
>> the first pass after free_cfg (so nothing has changed yet to the insns
>> stream).
>>
>> Some ports (including x86_64/i386, ia64, and most non-sched_dbr ports)
>> could simply do away with free_cfg and cleanup_barriers. But some
>> ports put things into the insns stream after free_cfg that
>> verify_flow_info chokes on, e.g. the fake insns for const pools for
>> ARM (that causes bugs elsewhere also, see e.g.
>> https://gcc.gnu.org/ml/gcc-patches/2011-07/msg02101.html). The current
>> situation is confusing and bound to give bugs sooner or later...
>>
>> I had patches to have an "early" and "late" free_cfg pass -- I think I
>> even posted them and I still believe that's the right short-term
>> solution -- to make sure nobody can put something between free_cfg and
>> a target with a machine_reorg that needs the CFG, or at least
>> BLOCK_FOR_INSN.
>
> Sure, we have targets which need cfg late, and targets which don't, and
> targets which do need it only diring machine reorg and not afterwards.
>
> pass_free_cfg doesn't do just free_bb_for_insn though, it also adds
> a note for hot cold partitioning, and for DBR targets other stuff, though
> DBR targets are likely helpless with keeping CFG till the end.
>
> What my patch does is still compatible with removing that
> free_bb_for_insn call from pass_free_cfg::execute if some flag is set
> in targetm, it teaches the pass to handle cfg if it is around.
>
> I agree that freeing the cfg and immediately computing it again doesn't make
> sense, but I just don't see this patch being incompatible with that.

I wonder if handing over pass pipeline control to targets at
machine_reorg time (including free_cfg) makes sense...
(either giving control back for stuff like final() or make it call
into the middle-end again).

Richard.

> Jakub

Re: [Patch, Fortran] PR63861 - fix OpenMP/ACC's gfc_has_alloc_comps

[Tobias Burnus]

Dear all,

I wrote:
> -  while (GFC_DESCRIPTOR_TYPE_P (type) || GFC_ARRAY_TYPE_P (type))
> +  if (GFC_DESCRIPTOR_TYPE_P (type)
> +  || (GFC_ARRAY_TYPE_P (type) && GFC_TYPE_ARRAY_RANK (type) == 0))

That's nonsense: It should be "!= 0". If one has an array type which has
a rank > 0 (i.e. it is not a scalar coarray), it shall get the element type.


The == 0 got muddled in because I couldn't decide whether it should be
"while" -> "if", i.e.

 if (GFC_DESCRIPTOR_TYPE_P (type) || GFC_ARRAY_TYPE_P (type))
   type = gfc_get_element_type (type);

or remain "while" with an added rank != 0 check, i.e.

 while (GFC_DESCRIPTOR_TYPE_P (type)
|| (GFC_ARRAY_TYPE_P (type) && GFC_TYPE_ARRAY_RANK (type) != 0))
   type = gfc_get_element_type (type);

Both should works as gfc_get_element_type() return for scalar coarrays
of type GFC_ARRAY_TYPE_P() the unmodified argument.


The question is why I didn't see the nonsense in the test suite. It
doesn't seem to be tested for in gcc/testsuite/gfortran.dg/; it might be
tested in libgomp/testsuite/ - I don't recall whether I retested after
the (incomplete) change back from "if" to "while" + (wrong) rank check.


Jakub: It should show up in a test in libgomp/testsuite/, shouldn't it?

Jakub: Do you know why you used a WHILE and not a simple IF? I tried
to come up with a case where the element type is an array, but I failed.

All: Any preference for "if" or "while" + rank != 0?

Tobias

Re: [Patch, AArch64, Obvious] Fix PR64231.

[Tejas Belagod]

On 23/01/15 17:15, Jakub Jelinek wrote:

On Fri, Jan 23, 2015 at 08:48:43AM -0800, Mike Stump wrote:

On Jan 23, 2015, at 3:03 AM, Tejas Belagod  wrote:

This is an almost obvious patch to fix PR64231 as discovered by A. Pinksi and 
as proposed by Jakub.


Kinda crappy code.  The macro to use here should take the number of bits as an 
int, and wether the constant is signed or not.

   FITS (x, 32, UNSIGNED)


Except that the test is testing something different.
First of all, it is closer to FITS (x, 33, SIGNED), but
the details are different, the test as is (except for the bug on 32-bit
hosts) INTVAL (x) is in not in [ -4GB + 33, 4GB - 32 ] interval (inclusive).
Why it isn't exactly "not in [ -4GB, 4GB - 1 ]" or similar.



The value of the offset itself is a heuristic as we cannot accurately 
say what the distance of a symbol from the ADRP will be at compile time. 
So it doesn't really matter what the exact value of range is in this case.


Thanks,
Tejas.

Re: [Patch, Fortran] PR63861 - fix OpenMP/ACC's gfc_has_alloc_comps

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 01:14:39PM +0100, Tobias Burnus wrote:
> The question is why I didn't see the nonsense in the test suite. It
> doesn't seem to be tested for in gcc/testsuite/gfortran.dg/; it might be
> tested in libgomp/testsuite/ - I don't recall whether I retested after
> the (incomplete) change back from "if" to "while" + (wrong) rank check.
> 
> 
> Jakub: It should show up in a test in libgomp/testsuite/, shouldn't it?

That surprises me too, I thought the coverage of that was sufficient.

> Jakub: Do you know why you used a WHILE and not a simple IF? I tried
> to come up with a case where the element type is an array, but I failed.

Most likely just because e.g. for C/C++ I'd also recurse on ARRAY_TYPEs
until I find the ultimate element.  Thus didn't think if it is possible to
have descriptor or descriptor-less arrays inside of arrays.
> 
> All: Any preference for "if" or "while" + rank != 0?

If it works, fine.  But perhaps put there some comment on why
for rank == 0 arrays get_element_type is undesirable.

Jakub

RE: [PATCH, RFC] LRA subreg handling

[Robert Suchanek]

> > Here we do have a hard register, but it isn't valid to form the subreg
> > on that hard register.  Reload had to cope with that case too.
> >
> > Since the subreg on the original hard register is invalid, we can't use
> > it to decide whether the intention was to write to only a part of the
> > inner register.  But I don't think we need to use the hard register
> > here.  The original register was a psuedo and I'm pretty sure...

Indeed, it is a hard register (64 IIRC) since get_try_hard_regno () must
return >= 0. 
 
> > > The differences (hard vs pseudo regs) are primarily an implementation
> > > detail.  I was really looking to see if there was existing code which
> > > would turn an output reload into an in-out reload for these subregs.
> > >
> > > The in-out nature of certain subregs is something I've personally
> > > stumbled over in various contexts (for example, this also came up
> > > during RTL-SSA investigations years ago).
> >
> > ...the rule for pseudos is that words of a multiword pseudo can be
> > accessed independently but subword pieces of an individual word can't.
> > This obviously isn't ideal if a mode is intended for wider-than-word
> > registers, since not all words will be independently addressable when
> > allocated to those registers.  The code above is partly dealing with the
> > fallout from that.  It's also why we have strict_lowpart for cases like
> > al on i386.
> >
> > So IMO the patch is too broad.  I think it should only use INOUT reloads
> > for !strict_low if the inner mode is wider than a word and the outer
> > mode is strictly narrower than the inner mode.  That's on top of Vlad's
> > comment about only converting OP_OUTs, of course.
> 
> This sounds correct/sensible. The change as committed will be turning
> some OP_OUT reloads into OP_INOUT unnecessarily. Checking for !strict_low
> is however probably redundant as strict_low must be OP_INOUT and never
> OP_OUT but we could mask backend bugs by converting strict_low subregs.
> 
> I think this should be resolved for GCC 5 if others agree it is an issue.
> 
> Matthew

This makes sense since we've got the inner wider than a word and I agree
it'd be better to resolve this for GCC 5.

Robert 

Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

[Christophe Lyon]

On 26 January 2015 at 13:10, Tejas Belagod  wrote:
> On 25/01/15 21:05, Christophe Lyon wrote:
>>
>> On 23 January 2015 at 14:44, Christophe Lyon 
>> wrote:
>>>
>>> On 23 January 2015 at 12:42, Christophe Lyon 
>>> wrote:

 On 23 January 2015 at 11:18, Tejas Belagod 
 wrote:
>
> On 22/01/15 21:31, Christophe Lyon wrote:
>>
>>
>> On 22 January 2015 at 16:22, Tejas Belagod 
>> wrote:
>>>
>>>
>>> On 22/01/15 14:28, Christophe Lyon wrote:



 On 22 January 2015 at 12:19, Tejas Belagod 
 wrote:
>
>
>
> On 21/01/15 15:07, Christophe Lyon wrote:
>>
>>
>>
>>
>> On 19 January 2015 at 17:54, Marcus Shawcroft
>>  wrote:
>>>
>>>
>>>
>>>
>>> On 19 January 2015 at 15:43, Christophe Lyon
>>> 
>>> wrote:




 On 19 January 2015 at 14:29, Marcus Shawcroft
  wrote:
>
>
>
>
> On 16 January 2015 at 17:52, Christophe Lyon
>  wrote:
>
>>> OK provided, as per the previous couple, that we don;t
>>> regression
>>> or
>>> introduce new fails on aarch64[_be] or aarch32.
>>
>>
>>
>>
>>
>> This patch shows failures on aarch64 and aarch64_be for vmax
>> and
>> vmin
>> when the input is -NaN.
>> It's a corner case, and my reading of the ARM ARM is that the
>> result
>> should the same as on aarch32.
>> I haven't had time to look at it in more details though.
>> So, not OK?
>
>
>
>
>
> They should have the same behaviour in aarch32 and aarch64. Did
> you
> test on HW or a model?
>
 I ran the tests on qemu for aarch32 and aarch64-linux, and on
 the
 foundation model for aarch64*-elf.
>>>
>>>
>>>
>>>
>>>
>>> Leave this one out until we understand why it fails. /Marcus
>>
>>
>>
>>
>>
>> I've looked at this a bit more.
>> We have
>> fmaxv0.4s, v0.4s, v1.4s
>> where v0 is a vector of -NaN (0xffc0) and v1 is a vector of 1.
>>
>> The output is still -NaN (0xffc0), while the test expects
>> defaultNaN (0x7fc0).
>>
>
> In the AArch32 execution state, Advanced SIMD FP arithmetic always
> uses
> the
> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In
> AArch64
> execution state, result of Advanced SIMD FP arithmetic operations
> depend
> on
> the value of the DN-bit i.e. either propagate the input NaN or
> generate
> DefaultNaN depending on the value of DN.




 Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I
 can see only the latter (no diff between aarch32 and aarch64 in
 FPProcessNan pseudo-code)

>>>
>>> If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec
>>> -
>>> under DN:
>>>
>>> "The value of this bit only controls scalar floating-point
>>> arithmetic.
>>> Advanced SIMD arithmetic always uses the Default NaN setting,
>>> regardless
>>> of
>>> the value of the DN bit."
>>>
>>> Also on page 3180 for the description of VMAX(vector FP), it says:
>>> "
>>> *  max(+0.0, -0.0) = +0.0
>>> * If any input is a NaN, the corresponding result element is the
>>> default
>>> NaN.
>>> "
>>>
>> Oops I was looking at FMAX (vector) pg 936.
>>
>>> The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue()
>>> to
>>> FPMax() which is on pg. 2285
>>>
>>> // StandardFPSCRValue()
>>> // 
>>> FPCRType StandardFPSCRValue()
>>> return ‘0’ : FPSCR.AHP : ‘11’
>>>
>>> Here bit-25(FPSCR.DN) is set to 1.
>>>
>>
>> So, we should get defaultNaN too on aarch64, and no need to try to
>> force DN to 1 in gdb?
>>
>> What can be wrong?
>>
>
> On pg 3180, I see VMAX(FPSIMD) for A32/T32, not A64. I hope we're
> reading
> the same document.
>
> Regardless of the page number, if you see the pseudocode for
> VMAX(FPSIMD)
> for AArch32, StandardFPSCRValue() (i.e. DN = 1) is passed to FPMax()
> which
> means generate DefaultNaN() regardless.
>
> OTOH, on pg 936, you have FMAX(vector) for A64 where FPMax() in the
> pseudocode

Re: [PATCH, i386] Remove EBX usage from asm code

[Rainer Orth]

Uros Bizjak  writes:

>> Yes, the name is better. It would also fit with Solaris.
>
> Bootstrap and regression test was OK.
>
> Committed with following ChangeLogs:
>
> libgcc/ChangeLog:
>
> 2015-01-23  Uros Bizjak  
>
> * config/i386/elf-lib.h: New file.
> (CRT_GET_RFIB_DATA): Move definition from gcc/config/i386/gnu-user.h.
> Wrap definition in #ifdef __i386__.
> * libgcc/config.host (i[34567]86-*-linux*, i[34567]86-*-kfreebsd*-gnu)
> (i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*)
> (i[34567]86-*-kopensolaris*-gnu, x86_64-*-linux*)
> (x86_64-*-kfreebsd*-gnu, x86_64-*-knetbsd*-gnu): Add i386/elf-lib.h
> to tm_file.
>
> gcc/ChangeLog:
>
> 2015-01-23  Uros Bizjak  
>
> * config/i386/gnu-user.h (CRT_GET_RFIB_DATA): Move definition to
> libgcc/config/i386/elf-lib.h.

I'll be comitting the following (which also removes the now unnecessary
Solaris/amd64 workaround from the unwinder) once another round of
bootstraps (Solaris 10 and 11/x86) has completed.

Rainer


2015-01-26  Rainer Orth  

gcc:
* config/i386/sysv4.h (CRT_GET_RFIB_DATA): Remove.

libgcc:
* config.host (i[34567]86-*-solaris2*, x86_64-*-solaris2.1[0-9]*):
Add i386/elf-lib.h to tm_file.
* config/i386/elf-lib.h: Fix comment.
* unwind-dw2-fde-dip.c (_Unwind_IteratePhdrCallback) [__x86_64__
&& __sun__ && __svr4__]: Remove workaround.

# HG changeset patch
# Parent b339ee5283ddcbd36c1afabc73f418e6ce9518ed
Only define CRT_GET_RFIB_DATA for 32-bit in i386/sysv4.h

diff --git a/gcc/config/i386/sysv4.h b/gcc/config/i386/sysv4.h
--- a/gcc/config/i386/sysv4.h
+++ b/gcc/config/i386/sysv4.h
@@ -49,16 +49,3 @@ along with GCC; see the file COPYING3.  
 	goto DONE;			\
   }	\
   } while (0)
-
-/* Used by crtstuff.c to initialize the base of data-relative relocations.
-   These are GOT relative on x86, so return the pic register.  */
-#define CRT_GET_RFIB_DATA(BASE)		\
-  __asm__ ("call\t.LPR%=\n"		\
-	   ".LPR%=:\n\t"		\
-	   "pop{l}\t%0\n\t"		\
-	   /* Due to a GAS bug, this cannot use EAX.  That encodes	\
-	  smaller than the traditional EBX, which results in the	\
-	  offset being off by one.  */\
-	   "add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-.LPR%=],%0"		\
-		   "|%0,_GLOBAL_OFFSET_TABLE_+(.-.LPR%=)}"		\
-	   : "=d"(BASE))
diff --git a/libgcc/config.host b/libgcc/config.host
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -619,6 +619,7 @@ i[34567]86-*-rtems*)
 i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
 	tmake_file="$tmake_file i386/t-crtpc i386/t-crtfm"
 	extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o crtfastmath.o"
+	tm_file="${tm_file} i386/elf-lib.h"
 	md_unwind_header=i386/sol2-unwind.h
 	;;
 i[4567]86-wrs-vxworks|i[4567]86-wrs-vxworksae)
diff --git a/libgcc/config/i386/elf-lib.h b/libgcc/config/i386/elf-lib.h
--- a/libgcc/config/i386/elf-lib.h
+++ b/libgcc/config/i386/elf-lib.h
@@ -1,4 +1,4 @@
-/* Definitions for Intel 386 systems using GNU userspace.
+/* Definitions for Intel 386 ELF systems.
Copyright (C) 2015 Free Software Foundation, Inc.
 
 GCC is free software; you can redistribute it and/or modify it under
diff --git a/libgcc/unwind-dw2-fde-dip.c b/libgcc/unwind-dw2-fde-dip.c
--- a/libgcc/unwind-dw2-fde-dip.c
+++ b/libgcc/unwind-dw2-fde-dip.c
@@ -343,9 +343,6 @@ static int
 }
 # elif defined __FRV_FDPIC__ && defined __linux__
   data->dbase = load_base.got_value;
-# elif defined __x86_64__ && defined __sun__ && defined __svr4__
-  /* While CRT_GET_RFIB_DATA is also defined for 64-bit Solaris 10+/x86, it
- doesn't apply since it uses DW_EH_PE_pcrel encoding.  */
 # else
 #  error What is DW_EH_PE_datarel base on this platform?
 # endif

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

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 01:11:01PM +0100, Richard Biener wrote:
> > I agree that freeing the cfg and immediately computing it again doesn't make
> > sense, but I just don't see this patch being incompatible with that.
> 
> I wonder if handing over pass pipeline control to targets at
> machine_reorg time (including free_cfg) makes sense...
> (either giving control back for stuff like final() or make it call
> into the middle-end again).

Perhaps, but not sure if such changes are desirable for stage4.
And certainly unsuitable for release branches.

Jakub

Re: Merge current set of OpenACC changes from gomp-4_0-branch

[Thomas Schwinge]

Hi!

Sorry for the late answer -- I've been on sick leave, and just now
returning to work.  Julian, would you please have a look at the following
issues?

> > > In r219682, I have committed to trunk our current set of OpenACC changes,
> > > which we had prepared on gomp-4_0-branch.  Thanks to everyone who has
> > > been contributing!

On Fri, 23 Jan 2015 20:20:53 +0300, Ilya Verbin  wrote:
> On 17 Jan 02:16, Ilya Verbin wrote:
> > Unfortunately, it broke offloading from shared libraries (I mean common libs
> > with NEEDED entries, not dlopened).

Sorry for that!

> > Such things are not covered by the
> > testsuite, that's why you missed this issue.  Here is a simple testcase:



Probably a good motivation for adding such a test case.  ;-)

> > So, you don't assume that a device can have multiple images from multiple 
> > libs?
> 
> Ping?

This probably is "just" a bug that we introduced with our changes?
(Julian?)


> Also, could you please explain, why did you divide a device initialization 
> into
> two functions -- gomp_init_device and gomp_init_tables?

As I understand it (again, Julian, please correct me if I got that
wrong), the reason is that for OpenACC support, we need these as two
separate (independent) actions.  Is this causing problems for OpenMP
offloading?


> Currently I'm trying to rebase on trunk my old patch, which fixes offloading
> from dlopened libraries: 
> http://gcc.gnu.org/ml/gcc-patches/2014-11/msg01604.html
> It works for OpenMP and MIC, but I don't know how not to break OpenACC and 
> PTX.


Grüße,
 Thomas


pgpNuLLIR31d6.pgp
Description: PGP signature

Re: [PATCH][AARCH64]Fix TLS local exec model addressing code generation inconsistency.

[Marcus Shawcroft]

On 20 January 2015 at 14:57, Renlin Li  wrote:

> gcc/ChangeLog:
>
> 2015-01-20 Renlin Li 
>
> * config/aarch64/aarch64.c (aarch64_load_symref_appropriately): Correct
> the comment.
> * config/aarch64/aarch64.md (tlsle_small_): Add left shift 12-bit
> for higher part.

OK /Marcus

Re: [[ARM/AArch64][testsuite] 13/36] Add vmla_n and vmls_n tests.

[Marcus Shawcroft]

On 20 January 2015 at 15:28, Christophe Lyon  wrote:
> On 16 January 2015 at 17:24, Tejas Belagod  wrote:
>>> +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
>>> };
>>
>>
>> No poly vmlx_n, otherwise LGTM.
>>
> Here is a new version, with a bit more cleanup than requested, since
> only 16x4 and 32x2 variants are supported.

OK /Marcus

Re: [[ARM/AArch64][testsuite] 09/36] Add vsubhn, vraddhn and vrsubhn tests. Split vaddhn.c into vXXXhn.inc and vaddhn.c to share code with other new tests.

[Marcus Shawcroft]

On 20 January 2015 at 15:24, Christophe Lyon  wrote:

> Here is an updated version, where I have removed a few more useless
> variables than you noticed: the [u]int64x1 as well as the 128 bits
> ones.


OK /Marcus

[gomp4] Merge trunk r219681 (2015-01-15) into gomp-4_0-branch

[Thomas Schwinge]

Hi!

In r220110, I have committed a merge from trunk r219681 (2015-01-15) into
gomp-4_0-branch.  This is the last trunk revision before the »Merge
current set of OpenACC changes from gomp-4_0-branch« commit.


Grüße,
 Thomas


pgpFT6G9VIhcG.pgp
Description: PGP signature

Re: [[ARM/AArch64][testsuite] 17/36] Add vpadd, vpmax and vpmin tests.

[Marcus Shawcroft]

On 20 January 2015 at 15:30, Christophe Lyon  wrote:

 +  /* Apply a unary operator named INSN_NAME.  */
>>>
>>>
>>> Unary op?
>>>
>> Hmm cut & paste issue. Thanks
>>
> Here is an updated versoin, also renaming VPADD into VPXXX, since it's
> in a template.


Updated version is OK /Marcus

Re: [[ARM/AArch64][testsuite] 21/36] Add vmovl tests.

[Marcus Shawcroft]

On 20 January 2015 at 15:32, Christophe Lyon  wrote:

>> No poly or float for vmovl.
>>
> Here is a new version, with more cleanup: only 16x8, 32x4 and 64x2
> variants are necessary.


This version is OK /Marcus

Re: [[ARM/AArch64][testsuite] 28/36] Add vmnv tests.

[Marcus Shawcroft]

On 20 January 2015 at 15:33, Christophe Lyon  wrote:
> On 16 January 2015 at 19:27, Tejas Belagod  wrote:
>>> +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x, 0x, 0x, 0x,
>>> +0x, 0x, 0x, 0x };
>>> +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0x, 0x,
>>> +  0x, 0x };
>>> +
>>
>>
>> No float or poly16 for vmvn_*.
>>
> Updated as attached, removed 64x1 and 64x2 too.
>

OK /Marcus

Re: [[ARM/AArch64][testsuite] 29/36] Add vpadal tests.

[Marcus Shawcroft]

On 20 January 2015 at 15:34, Christophe Lyon  wrote:
> On 16 January 2015 at 19:29, Tejas Belagod  wrote:
>>> +VECT_VAR_DECL(expected,poly,8,16) [] = { 0x33, 0x33, 0x33, 0x33,
>>> +0x33, 0x33, 0x33, 0x33,
>>> +0x33, 0x33, 0x33, 0x33,
>>> +0x33, 0x33, 0x33, 0x33 };
>>> +VECT_VAR_DECL(expected,poly,16,8) [] = { 0x, 0x, 0x, 0x,
>>> +0x, 0x, 0x, 0x };
>>> +VECT_VAR_DECL(expected,hfloat,32,4) [] = { 0x, 0x,
>>> +  0x, 0x };
>>> +
>>
>>
>> No float or poly ops for VPADAL insns.
>>
> int8 variants are not necessary either, updated as attached.

OK /Marcus

Re: [[ARM/AArch64][testsuite] 30/36] Add vpaddl tests.

[Marcus Shawcroft]

On 20 January 2015 at 15:35, Christophe Lyon  wrote:

>> Hmm changed my mind: vpaddl takes only one vector as input, although
>> it does add 2 vector elements.
>>
> Here is an updated version, removing poly, float and int8 variants.

OK /Marcus

RE: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Hale Wang]

> -Original Message-
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Monday, January 26, 2015 6:03 PM
> To: Hale Wang
> Cc: GCC Patches
> Subject: Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a
> volatile register is contained.
> 
> 
> I think it is allowed to the second combining, just not the first.
> Also it is not about volatile registers here but rather user specified 
> registers
> into inline-asm.
> Also I thought can_combine_p would reject combing into an inline-asm to
> prevent this issue.
> 

Hi Andrew,

Thanks a lot.
As you suggested, I changed the patch to reject combing into an inline-asm. I 
have attached the patch.
Is it OK for you?

BR,
Hale

> Thanks,
> Andrew
> 
> >
> > This patch is used to disable the combine operation if the insns
> > contain volatile registers. A new test case is also added in this patch.
> >
> > Is it OK for trunk?
> >
> > BR,
> > Hale Wang
> >
> > ChangeLog:
> >
> > 2015-01-22  Hale Wang  
> >
> > PR middle-end/46164
> > * combine.c (can_combine_p): Don't combine the insns if
> > a volatile register is contained.
> >
> > 2015-01-22  Hale Wang  
> >
> > PR middle-end/46164
> > * gcc.target/arm/pr46164.c: New test.

diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..2e8290a 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1769,7 +1769,7 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn 
*pred ATTRIBUTE_UNUSED,
 {
   int i;
   const_rtx set = 0;
-  rtx src, dest;
+  rtx src, dest, asm_op;
   rtx_insn *p;
 #ifdef AUTO_INC_DEC
   rtx link;
@@ -1983,6 +1983,10 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn 
*pred ATTRIBUTE_UNUSED,
   else if (GET_CODE (dest) != CC0)
 return 0;
 
+  /* If i3 contains an inline-asm operand, reject, because the user specified
+ registers in the inline-asm maybe removed by the combining.  */
+  if ((asm_op = extract_asm_operands (PATTERN (i3))) != NULL)
+return 0;
 
   if (GET_CODE (PATTERN (i3)) == PARALLEL)
 for (i = XVECLEN (PATTERN (i3), 0) - 1; i >= 0; i--)
diff --git a/gcc/testsuite/gcc.target/arm/pr46164.c 
b/gcc/testsuite/gcc.target/arm/pr46164.c
new file mode 100644
index 000..ad3b7cb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr46164.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-mcpu=cortex-m3 -mthumb -O1" } */
+
+char temp[16];
+extern int foo1 (void);
+
+void foo (void)
+{
+  int i;
+  int len;
+
+  while (1)
+  {
+len = foo1 ();
+register char *a asm ("r1") = temp;
+asm volatile ("mov %[r1], %[r1]\n " :: [r1]"r"(a), "m"(*a));
+
+for (i = 0; i < len; i++)
+{
+  if (temp[i] == 10)
+  return;
+}
+  }
+}
+
+/* { dg-final { scan-assembler "\[\\t \]+mov\ r1,\ r1" } } */

pr46164-combine-volatile-register.patch-4
Description: Binary data

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

[Rainer Orth]

FX  writes:

>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB
>> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out]
>> This means that the PIC library is being built with non-pic relocs.
>
> config/mh-darwin says that -mdynamic-no-pic is there because it “speeds
> compiles by 3-5%”. I don’t think we care about speed when the bootstrap
> fails, so can we remove it altogether?

Darwin/i686 still doesn't bootstrap without this patch, I believe.
Shouldn't it be applied to trunk before GCC 5 ships, rather than leaving
that target broken?

Rainer

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

Re: [patch, build] Restore bootstrap in building libcc1 on darwin

[Iain Sandoe]

On 26 Jan 2015, at 14:13, Rainer Orth wrote:

> FX  writes:
> 
>>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
>>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB
>>> -fPIC _won't_ override -mdynamic-no-pic, so that's not a simple way out]
>>> This means that the PIC library is being built with non-pic relocs.
>> 
>> config/mh-darwin says that -mdynamic-no-pic is there because it “speeds
>> compiles by 3-5%”. I don’t think we care about speed when the bootstrap
>> fails, so can we remove it altogether?
> 
> Darwin/i686 still doesn't bootstrap without this patch, I believe.
> Shouldn't it be applied to trunk before GCC 5 ships, rather than leaving
> that target broken?

I'll try and post a patch to fix it properly this week..
Iain

Re: [COMMITTED] Merge libffi with upstream

[Rainer Orth]

"H.J. Lu"  writes:

> On Fri, Jan 16, 2015 at 5:38 AM, Rainer Orth
>  wrote:
>> Jakub Jelinek  writes:
>>
 @@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl

  set targetabis { "" }
  if [string match $compiler_vendor "gnu"] {
 -if [istarget "i?86-*-*"] {
 +if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
 + && [is-effective-target ilp32] } {
>>>
>>> Shouldn't that be ia32 instead if ilp32 ?  I mean, do you want
>>> it for -mx32 too or not?
>>
>> I've no idea if x32 supports stdcall or not.
>
> No, x32 doesn't.  You should check ia32, not ilp32.

2015-01-16  Rainer Orth  

* testsuite/lib/libffi.exp: Load target-supports.exp.
(run-many-tests): Only set targetabis for ia32.

# HG changeset patch
# Parent 5b70ffc67684f61ff23547e4b3ad25e64a2ca2a2
Correctly check for 32-bit x86

diff --git a/libffi/testsuite/lib/libffi.exp b/libffi/testsuite/lib/libffi.exp
--- a/libffi/testsuite/lib/libffi.exp
+++ b/libffi/testsuite/lib/libffi.exp
@@ -23,6 +23,7 @@ proc load_gcc_lib { filename } {
 
 load_lib dg.exp
 load_lib libgloss.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib target-libpath.exp
 load_gcc_lib wrapper.exp
 
@@ -311,7 +312,8 @@ proc run-many-tests { testcases extra_fl
 
 set targetabis { "" }
 if [string match $compiler_vendor "gnu"] {
-if [istarget "i?86-*-*"] {
+if { ([istarget "i?86-*-*"] || [istarget "x86_64-*-*"])
+	 && [is-effective-target ia32] } {
 set targetabis {
 ""
 "-DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__"

This patch worked for me.  Ok for mainline now?

Thanks.
Rainer

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

Re: [patch, libbacktrace/libsanitizer/libquadmath/libcilkrts] fix multilib builds

[Tobias Burnus]

Matthias Klose wrote:
> >> However for the libbacktrace and the libsanitizer builds, the 
> >> AM_ENABLE_MULTILIB
> >> macro is included way too late.  Scan the generated configure file for
> >> "cross_compiling" and see that the above snippet is added after the failing
> >> checks. The fix seems to be simple, just move the AM_ENABLE_MULTILIB macro 
> >> up so
> >> that the "cross_compiling" value is corrected before it is tested.  This 
> >> is what
> >> the patch is doing.
[...]
> CCed, and there are more directories needing an update: libquadmath and
> libcilkrts.  Note that libcilkrts didn't have an AM_ENABLE_MULTILIB call at 
> all,
> but nevertheless builds the multilib libraries.

> The attached patch just moves the AM_ENABLE_MULTILIB calls up in the files, so
> that these are found before GCC_NO_EXECUTABLES (which is not called in every
> libXXdir) and AC_PROC_CC.
> 
> x32 multilib enabled x86_64-linux-gnu and i686-linux-gnu configurations built
> successfully on a non-x32 enabled kernel.

>From my side, the libquadmath part of patch is okay.


Ian Lance Taylor wrote to the libbacktrace part of the patch:
> Probably a build maintainer should take a look at this patch.

I concur that that wouldn't harm.

Tobias

Re: Merge current set of OpenACC changes from gomp-4_0-branch

[Ilya Verbin]

On 26 Jan 14:44, Thomas Schwinge wrote:
> On 17 Jan 02:16, Ilya Verbin wrote:
> > Such things are not covered by the
> > testsuite, that's why you missed this issue.  Here is a simple testcase:
> 
> 
> 
> Probably a good motivation for adding such a test case.  ;-)

I thought about it, but I don't know how to compile 2 binaries and run one of
them using dejagnu.

> > So, you don't assume that a device can have multiple images from multiple 
> > libs?
> 
> This probably is "just" a bug that we introduced with our changes?
> (Julian?)
> 
> > Also, could you please explain, why did you divide a device initialization 
> > into
> > two functions -- gomp_init_device and gomp_init_tables?
> 
> As I understand it (again, Julian, please correct me if I got that
> wrong), the reason is that for OpenACC support, we need these as two
> separate (independent) actions.  Is this causing problems for OpenMP
> offloading?

I'm asking since in this patch 
http://gcc.gnu.org/ml/gcc-patches/2014-11/msg01604.html
I tried to change libgomp<->plugin interface to enable offloading from libs,
loaded at any time.
My proposal was to replace GOMP_OFFLOAD_register_image and
GOMP_OFFLOAD_get_table with GOMP_OFFLOAD_[un]load_image.
When target device is initialized, GOMP_OFFLOAD_load_image registers one image
in the plugin and returns corresponding target addresses for the image.
The mapping between host and target addresses happens as previously.
I hope that this approach is suitable for both MIC and PTX.

Here is my current patch, it works for OpenMP->MIC, but obviously will not work
for PTX, since it requires symmetrical changes in the plugin.  Could you please
take a look, whether it is possible to support this new interface in PTX plugin?


diff --git a/libgomp/libgomp-plugin.h b/libgomp/libgomp-plugin.h
index d9cbff5..1072ae4 100644
--- a/libgomp/libgomp-plugin.h
+++ b/libgomp/libgomp-plugin.h
@@ -51,14 +51,12 @@ enum offload_target_type
   OFFLOAD_TARGET_TYPE_INTEL_MIC = 6
 };
 
-/* Auxiliary struct, used for transferring a host-target address range mapping
-   from plugin to libgomp.  */
-struct mapping_table
+/* Auxiliary struct, used for transferring pairs of addresses from plugin
+   to libgomp.  */
+struct addr_pair
 {
-  uintptr_t host_start;
-  uintptr_t host_end;
-  uintptr_t tgt_start;
-  uintptr_t tgt_end;
+  uintptr_t start;
+  uintptr_t end;
 };
 
 /* Miscellaneous functions.  */
diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
index 3089401..4e021f9 100644
--- a/libgomp/libgomp.h
+++ b/libgomp/libgomp.h
@@ -773,10 +773,10 @@ struct gomp_device_descr
   unsigned int (*get_caps_func) (void);
   int (*get_type_func) (void);
   int (*get_num_devices_func) (void);
-  void (*register_image_func) (void *, void *);
   void (*init_device_func) (int);
   void (*fini_device_func) (int);
-  int (*get_table_func) (int, struct mapping_table **);
+  int (*load_image_func) (int, void *, struct addr_pair **);
+  void (*unload_image_func) (int, void *);
   void *(*alloc_func) (int, size_t);
   void (*free_func) (int, void *);
   void *(*dev2host_func) (int, void *, const void *, size_t);
@@ -793,9 +793,6 @@ struct gomp_device_descr
   /* Set to true when device is initialized.  */
   bool is_initialized;
 
-  /* True when offload regions have been registered with this device.  */
-  bool offload_regions_registered;
-
   /* OpenACC-specific data and functions.  */
   /* This is mutable because of its mutable data_environ and target_data
  members.  */
diff --git a/libgomp/libgomp.map b/libgomp/libgomp.map
index f44174e..2b2b953 100644
--- a/libgomp/libgomp.map
+++ b/libgomp/libgomp.map
@@ -231,6 +231,7 @@ GOMP_4.0 {
 GOMP_4.0.1 {
   global:
GOMP_offload_register;
+   GOMP_offload_unregister;
 } GOMP_4.0;
 
 OACC_2.0 {
diff --git a/libgomp/oacc-host.c b/libgomp/oacc-host.c
index 6aeb1e7..5d67c6c 100644
--- a/libgomp/oacc-host.c
+++ b/libgomp/oacc-host.c
@@ -43,10 +43,10 @@ static struct gomp_device_descr host_dispatch =
 .get_caps_func = GOMP_OFFLOAD_get_caps,
 .get_type_func = GOMP_OFFLOAD_get_type,
 .get_num_devices_func = GOMP_OFFLOAD_get_num_devices,
-.register_image_func = GOMP_OFFLOAD_register_image,
 .init_device_func = GOMP_OFFLOAD_init_device,
 .fini_device_func = GOMP_OFFLOAD_fini_device,
-.get_table_func = GOMP_OFFLOAD_get_table,
+.load_image_func = GOMP_OFFLOAD_load_image,
+.unload_image_func = GOMP_OFFLOAD_unload_image,
 .alloc_func = GOMP_OFFLOAD_alloc,
 .free_func = GOMP_OFFLOAD_free,
 .dev2host_func = GOMP_OFFLOAD_dev2host,
@@ -56,7 +56,6 @@ static struct gomp_device_descr host_dispatch =
 .mem_map.is_initialized = false,
 .mem_map.splay_tree.root = NULL,
 .is_initialized = false,
-.offload_regions_registered = false,
 
 .openacc = {
   .open_device_func = GOMP_OFFLOAD_openacc_open_device,
diff --git a/libgomp/oacc-init.c b/libgom

[PATCH] Fix PR64764

[Richard Biener]

The following fixes PR64764.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2015-01-26  Richard Biener  

PR middle-end/64764
* tree-ssa-uninit.c (is_pred_expr_subset_of): Handle
combining two BIT_AND_EXPR predicates.

* gcc.dg/uninit-19.c: New testcase.

Index: gcc/tree-ssa-uninit.c
===
--- gcc/tree-ssa-uninit.c   (revision 220107)
+++ gcc/tree-ssa-uninit.c   (working copy)
@@ -1377,7 +1377,8 @@ is_pred_expr_subset_of (pred_info expr1,
   if (expr2.invert)
 code2 = invert_tree_comparison (code2, false);
 
-  if (code1 == EQ_EXPR && code2 == BIT_AND_EXPR)
+  if ((code1 == EQ_EXPR || code1 == BIT_AND_EXPR)
+  && code2 == BIT_AND_EXPR)
 return wi::eq_p (expr1.pred_rhs,
 wi::bit_and (expr1.pred_rhs, expr2.pred_rhs));
 
Index: gcc/testsuite/gcc.dg/uninit-19.c
===
--- gcc/testsuite/gcc.dg/uninit-19.c(revision 0)
+++ gcc/testsuite/gcc.dg/uninit-19.c(working copy)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O -Wuninitialized" } */
+
+int a, l, m;
+float *b;
+float c, d, e, g, h;
+unsigned char i, k;
+void
+fn1 (int p1, float *f1, float *f2, float *f3, unsigned char *c1, float *f4,
+ unsigned char *c2, float *p10)
+{
+  if (p1 & 8)
+b[3] = p10[a];  /* { dg-warning "may be used uninitialized" } */
+}
+
+void
+fn2 ()
+{
+  float *n;
+  if (l & 6)
+n = &c + m;
+  fn1 (l, &d, &e, &g, &i, &h, &k, n);
+}

[PATCH][1/2] Improve array bound warnings

[Richard Biener]

I've looked at PR64277 and noticed we haven't been applying TLC to the
array-bound warning code for a long time.  I noticed we don't
warn for out-of-bound return &a[11]; - fixed with the simplifications.
I also noticed that anti-range handling has off-by-one errors
(well, always applied ignore_off_by_one and to both ends of the array).

Bootstrap and regtest pending on x86_64-unknown-linux-gnu.

It doesn't help the testcase in PR64277 ([2/2] will somewhat).

Ok for trunk?  (seems we never warned for returning &a[11] and
anti-range handling was broken all the time)

I can as well queue this for GCC 6.

Thanks,
Richard.

2015-01-26  Richard Biener  

PR tree-optimization/64277
* tree-vrp.c (check_array_ref): Fix anti-range handling,
simplify upper bound handling.
(search_for_addr_array): Simplify.
(check_array_bounds): Handle ADDR_EXPRs here.
(check_all_array_refs): Simplify.

* gcc.dg/Warray-bounds-12.c: New testcase.
* gcc.dg/Warray-bounds-13.c: Likewise.

Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c  (revision 220107)
--- gcc/tree-vrp.c  (working copy)
*** check_array_ref (location_t location, tr
*** 6546,6554 
if (vr && vr->type == VR_ANTI_RANGE)
  {
if (TREE_CODE (up_sub) == INTEGER_CST
!   && tree_int_cst_lt (up_bound, up_sub)
&& TREE_CODE (low_sub) == INTEGER_CST
!   && tree_int_cst_lt (low_sub, low_bound))
  {
warning_at (location, OPT_Warray_bounds,
  "array subscript is outside array bounds");
--- 6546,6556 
if (vr && vr->type == VR_ANTI_RANGE)
  {
if (TREE_CODE (up_sub) == INTEGER_CST
!   && (ignore_off_by_one
! ? tree_int_cst_lt (up_bound, up_sub)
! : tree_int_cst_le (up_bound, up_sub))
&& TREE_CODE (low_sub) == INTEGER_CST
!   && tree_int_cst_le (low_sub, low_bound))
  {
warning_at (location, OPT_Warray_bounds,
  "array subscript is outside array bounds");
*** check_array_ref (location_t location, tr
*** 6557,6566 
  }
else if (TREE_CODE (up_sub) == INTEGER_CST
   && (ignore_off_by_one
!  ? (tree_int_cst_lt (up_bound, up_sub)
! && !tree_int_cst_equal (up_bound_p1, up_sub))
!  : (tree_int_cst_lt (up_bound, up_sub)
! || tree_int_cst_equal (up_bound_p1, up_sub
  {
if (dump_file && (dump_flags & TDF_DETAILS))
{
--- 6559,6566 
  }
else if (TREE_CODE (up_sub) == INTEGER_CST
   && (ignore_off_by_one
!  ? !tree_int_cst_le (up_sub, up_bound_p1)
!  : !tree_int_cst_le (up_sub, up_bound)))
  {
if (dump_file && (dump_flags & TDF_DETAILS))
{
*** check_array_ref (location_t location, tr
*** 6593,6617 
  static void
  search_for_addr_array (tree t, location_t location)
  {
-   while (TREE_CODE (t) == SSA_NAME)
- {
-   gimple g = SSA_NAME_DEF_STMT (t);
- 
-   if (gimple_code (g) != GIMPLE_ASSIGN)
-   return;
- 
-   if (get_gimple_rhs_class (gimple_assign_rhs_code (g))
- != GIMPLE_SINGLE_RHS)
-   return;
- 
-   t = gimple_assign_rhs1 (g);
- }
- 
- 
-   /* We are only interested in addresses of ARRAY_REF's.  */
-   if (TREE_CODE (t) != ADDR_EXPR)
- return;
- 
/* Check each ARRAY_REFs in the reference chain. */
do
  {
--- 6593,6598 
*** check_array_bounds (tree *tp, int *walk_
*** 6701,6712 
if (TREE_CODE (t) == ARRAY_REF)
  check_array_ref (location, t, false /*ignore_off_by_one*/);
  
!   if (TREE_CODE (t) == MEM_REF
!   || (TREE_CODE (t) == RETURN_EXPR && TREE_OPERAND (t, 0)))
! search_for_addr_array (TREE_OPERAND (t, 0), location);
! 
!   if (TREE_CODE (t) == ADDR_EXPR)
! *walk_subtree = FALSE;
  
return NULL_TREE;
  }
--- 6682,6692 
if (TREE_CODE (t) == ARRAY_REF)
  check_array_ref (location, t, false /*ignore_off_by_one*/);
  
!   else if (TREE_CODE (t) == ADDR_EXPR)
! {
!   search_for_addr_array (t, location);
!   *walk_subtree = FALSE;
! }
  
return NULL_TREE;
  }
*** check_all_array_refs (void)
*** 6736,6764 
{
  gimple stmt = gsi_stmt (si);
  struct walk_stmt_info wi;
! if (!gimple_has_location (stmt))
continue;
  
! if (is_gimple_call (stmt))
!   {
! size_t i;
! size_t n = gimple_call_num_args (stmt);
! for (i = 0; i < n; i++)
!   {
! tree arg = gimple_call_arg (stmt, i);
! search_for_addr_array (arg, gimple_location (stmt));
!   }
!   }
! else
!   {
! memset (&wi, 0, sizeof (wi));
! wi.info = CONST_CAST (void *, (const void *)
!   

Re: [PATCH][1/2] Improve array bound warnings

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 03:57:20PM +0100, Richard Biener wrote:
> 
> I've looked at PR64277 and noticed we haven't been applying TLC to the
> array-bound warning code for a long time.  I noticed we don't
> warn for out-of-bound return &a[11]; - fixed with the simplifications.
> I also noticed that anti-range handling has off-by-one errors
> (well, always applied ignore_off_by_one and to both ends of the array).
> 
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
> 
> It doesn't help the testcase in PR64277 ([2/2] will somewhat).
> 
> Ok for trunk?  (seems we never warned for returning &a[11] and
> anti-range handling was broken all the time)
> 
> I can as well queue this for GCC 6.

I think for this warning which is notorious for generating false positives
everywhere it would be better to defer to GCC 6 at this point.

> 2015-01-26  Richard Biener  
> 
>   PR tree-optimization/64277
>   * tree-vrp.c (check_array_ref): Fix anti-range handling,
>   simplify upper bound handling.
>   (search_for_addr_array): Simplify.
>   (check_array_bounds): Handle ADDR_EXPRs here.
>   (check_all_array_refs): Simplify.
> 
>   * gcc.dg/Warray-bounds-12.c: New testcase.
>   * gcc.dg/Warray-bounds-13.c: Likewise.

Jakub

[PATCH][2/2] Improve array-bound warnings and VRP

[Richard Biener]

This is the 2nd thing I came up with after looking at PR64277.
VRP does a poor job computing value-ranges of unrolled loop IVs
thus a very simple thing to do is to factor in previous VRP results
by intersecting what VRP2 computes with recorded SSA name range infos
(that also makes errors in those more likely to pop up... :/).

This reduces the number of array bound warnings I get from the testcase
but doesn't fix it completely.  It also ends up with saner value-ranges.

Bootstrapped and tested on x86_64-unknown-linux-gnu (with one
libstdc++ runtime failure which I am now checking if caused by the patch,
and thus likely an existing latent issue with SSA name range info).

Ok for trunk?  Or should I delay this to GCC 6?

Thanks,
Richard.

2015-01-26  Richard Biener  

PR tree-optimization/64277
* tree-vrp.c (update_value_range): Intersect the range with
old recorded SSA name range information.

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 220107)
+++ gcc/tree-vrp.c  (working copy)
@@ -847,6 +847,23 @@ update_value_range (const_tree var, valu
   value_range_t *old_vr;
   bool is_new;
 
+  /* If there is a value-range on the SSA name from earlier analysis
+ factor that in.  */
+  if (INTEGRAL_TYPE_P (TREE_TYPE (var)))
+{
+  wide_int min, max;
+  value_range_type rtype = get_range_info (var, &min, &max);
+  if (rtype == VR_RANGE || rtype == VR_ANTI_RANGE)
+   {
+ value_range_d nr;
+ nr.type = rtype;
+ nr.min = wide_int_to_tree (TREE_TYPE (var), min);
+ nr.max = wide_int_to_tree (TREE_TYPE (var), max);
+ nr.equiv = NULL;
+ vrp_intersect_ranges (new_vr, &nr);
+   }
+}
+
   /* Update the value range, if necessary.  */
   old_vr = get_value_range (var);
   is_new = old_vr->type != new_vr->type

Re: [PATCH][2/2] Improve array-bound warnings and VRP

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote:
> 
> This is the 2nd thing I came up with after looking at PR64277.
> VRP does a poor job computing value-ranges of unrolled loop IVs
> thus a very simple thing to do is to factor in previous VRP results
> by intersecting what VRP2 computes with recorded SSA name range infos
> (that also makes errors in those more likely to pop up... :/).
> 
> This reduces the number of array bound warnings I get from the testcase
> but doesn't fix it completely.  It also ends up with saner value-ranges.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu (with one
> libstdc++ runtime failure which I am now checking if caused by the patch,
> and thus likely an existing latent issue with SSA name range info).
> 
> Ok for trunk?  Or should I delay this to GCC 6?

Does this work even without the other patch?
What do you think about Ilya's patch to set TREE_NO_WARNING in the unrolled
iterations where we had to keep the exit check?

> 2015-01-26  Richard Biener  
> 
>   PR tree-optimization/64277
>   * tree-vrp.c (update_value_range): Intersect the range with
>   old recorded SSA name range information.

Jakub

Re: [PATCH][2/2] Improve array-bound warnings and VRP

[Richard Biener]

On Mon, 26 Jan 2015, Jakub Jelinek wrote:

> On Mon, Jan 26, 2015 at 04:06:11PM +0100, Richard Biener wrote:
> > 
> > This is the 2nd thing I came up with after looking at PR64277.
> > VRP does a poor job computing value-ranges of unrolled loop IVs
> > thus a very simple thing to do is to factor in previous VRP results
> > by intersecting what VRP2 computes with recorded SSA name range infos
> > (that also makes errors in those more likely to pop up... :/).
> > 
> > This reduces the number of array bound warnings I get from the testcase
> > but doesn't fix it completely.  It also ends up with saner value-ranges.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu (with one
> > libstdc++ runtime failure which I am now checking if caused by the patch,
> > and thus likely an existing latent issue with SSA name range info).
> > 
> > Ok for trunk?  Or should I delay this to GCC 6?
> 
> Does this work even without the other patch?

Yes, I've actually developed 2/2 first.  The other patch only ever
emits more warnings...

> What do you think about Ilya's patch to set TREE_NO_WARNING in the unrolled
> iterations where we had to keep the exit check?

I don't like it too much - it papers over the real issue and prevents
valid warnings from being emitted.  Maybe we can set TREE_NO_WARNING on
the last iteration (that is the only one we usually end up warning
on - like after this patch).  There are also many dups - regressions
in 4.8 I belive where we warn for the last iteration in an unrolled loop.

Richard.

Re: [PATCH][2/2] Improve array-bound warnings and VRP

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
> > > Ok for trunk?  Or should I delay this to GCC 6?
> > 
> > Does this work even without the other patch?
> 
> Yes, I've actually developed 2/2 first.  The other patch only ever
> emits more warnings...

Then it probably should be ok.  I'm really afraid of emitting more warnings
with such high false positive rate now.

> > What do you think about Ilya's patch to set TREE_NO_WARNING in the unrolled
> > iterations where we had to keep the exit check?
> 
> I don't like it too much - it papers over the real issue and prevents
> valid warnings from being emitted.  Maybe we can set TREE_NO_WARNING on
> the last iteration (that is the only one we usually end up warning
> on - like after this patch).  There are also many dups - regressions
> in 4.8 I belive where we warn for the last iteration in an unrolled loop.

Do we check only the last iteration?  Won't we warn about other iterations
too?  -Warray-bounds have plenty of warnings in dead jump threaded code that
the compiler can't prove is dead etc.
IMHO the warning should be done in VRP1 only.

Jakub

Re: [PATCH][2/2] Improve array-bound warnings and VRP

[Richard Biener]

On Mon, 26 Jan 2015, Jakub Jelinek wrote:

> On Mon, Jan 26, 2015 at 04:18:32PM +0100, Richard Biener wrote:
> > > > Ok for trunk?  Or should I delay this to GCC 6?
> > > 
> > > Does this work even without the other patch?
> > 
> > Yes, I've actually developed 2/2 first.  The other patch only ever
> > emits more warnings...
> 
> Then it probably should be ok.  I'm really afraid of emitting more warnings
> with such high false positive rate now.
> 
> > > What do you think about Ilya's patch to set TREE_NO_WARNING in the 
> > > unrolled
> > > iterations where we had to keep the exit check?
> > 
> > I don't like it too much - it papers over the real issue and prevents
> > valid warnings from being emitted.  Maybe we can set TREE_NO_WARNING on
> > the last iteration (that is the only one we usually end up warning
> > on - like after this patch).  There are also many dups - regressions
> > in 4.8 I belive where we warn for the last iteration in an unrolled loop.
> 
> Do we check only the last iteration?  Won't we warn about other iterations
> too?  -Warray-bounds have plenty of warnings in dead jump threaded code that
> the compiler can't prove is dead etc.

Sure - but for unrolling

 int a[2];
 for (int i = 0; i < 5; i++)
  a[i] = i;

I'd like to see warnings and we only warn if we unroll this because
the value-range of i includes indexes that are valid.

> IMHO the warning should be done in VRP1 only.

Yeah, I agree - but I remember that people wanted the extra stuff
from VRP2 (just quickly checked that gcc.dg/Warray-bounds* doesn't
regress with disabling VRP2).

So - do we want to disable array bound warnings for VRP2?  I'd be
happy to approve of that and it will most certainly fix all of the
recent (4.8+) regressions related to loop peeling.

Thanks,
Richard.

Re: [PATCH][2/2] Improve array-bound warnings and VRP

[Jakub Jelinek]

On Mon, Jan 26, 2015 at 04:28:02PM +0100, Richard Biener wrote:
> Sure - but for unrolling
> 
>  int a[2];
>  for (int i = 0; i < 5; i++)
>   a[i] = i;
> 
> I'd like to see warnings and we only warn if we unroll this because
> the value-range of i includes indexes that are valid.

Don't we warn here for -Waggressive-loop-optimizations already?

> > IMHO the warning should be done in VRP1 only.
> 
> Yeah, I agree - but I remember that people wanted the extra stuff
> from VRP2 (just quickly checked that gcc.dg/Warray-bounds* doesn't
> regress with disabling VRP2).
> 
> So - do we want to disable array bound warnings for VRP2?  I'd be
> happy to approve of that and it will most certainly fix all of the
> recent (4.8+) regressions related to loop peeling.

That would be my preference, if not many people complain about that.
People can use -fsanitize=undefined if they want more accurate and detailed
out of bounds checking anyway, and/or -fsanitize=address.

Jakub

Re: [RFC] POWER8 default for PPC64LE

[David Edelsohn]

On Mon, Jan 26, 2015 at 4:46 AM, Jakub Jelinek  wrote:
> On Sat, Jan 17, 2015 at 09:18:14PM -0500, David Edelsohn wrote:
>> Thanks, David
>>
>> * config/rs6000/default64.h: Include rs6000-cpus.def.
>> (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8).
>> * config/rs6000/driver-rs6000.c (detect_processor_aix): Add POWER7.
>> * config/rs6000/linux64.h: Always default to POWER8.
>> * config/rs6000/rs6000.c (rs6000_file_start): Emit .machine
>> pseudo-op to specify assembler dialect.
>
> Unfortunately, this broke all qi/hi mode atomics on ppc64le, when configured
> --with-cpu=power7 --with-tune=power8.
> The problem is that TARGET_SYNC_HI_QI is defined as
> TARGET_QUAD_MEMORY || TARGET_QUAD_MEMORY_ATOMIC || TARGET_DIRECT_MOVE
> and from these 3, despite the configured default or even explicit
> -mcpu=power7 the second one was never cleared.
>
> The following patch seems to fix it, ok for trunk if testing passes?
>
> What about release branches?
>
> 2015-01-26  Jakub Jelinek  
>
> * config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add
> OPTION_MASK_QUAD_MEMORY_ATOMIC.

Okay.

Thanks, David

Retracted: [PATCH 0/4][ARM Intrinsics][RFTesting] Add missing float16x8_t type, and float16x[48] intrinsics

[Alan Lawrence]

There are still bugs in these patches, they should not go in. Hope to have 
something ready, with tests, in the next stage 1.


Cheers, Alan

Alan Lawrence wrote:
These add all the V[48]HFmode insns and corresponding intrinsics for ARM. 
Depends on the two patches at 
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01422.html .


Unfortunately I don't at present have a testsuite. I've done some testing both 
manually and on a large internal testsuite for Neon/ACLE intrinsics, but I'm 
wondering if anyone has anything they might be able to contribute? Christophe, 
perhaps you can give me some pointers, how might one add float16 to the 
advsimd-intrinsics testsuite / how easy would this be?


Cross-tested check-gcc on arm-none-eabi
Bootstrapped on arm-none-linux-gnueabihf cortex-a15

Re: [Patch, Fortran, OOP] PR 64230: [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component

[Janus Weil]

2015-01-24 18:18 GMT+01:00 Tobias Burnus :
>> this is a second patch dealing with finalization-related regressions,
>> [...]
>> This patch fixes an invalid memory reference inside the finalizer
>> routine (at runtime), which apparently was caused by dereferencing a
>> pointer without checking if it's NULL. I simply insert a call to
>> ASSOCIATED.
>> [...]
>>
>> This one regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk and
>> 4.9?
>
>
> OK. Thanks for the patch!

Thanks for the review, Tobias. Committed to trunk as r220125. Will
backport to 4.9 soon.

Cheers,
Janus

RE: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

[Moore, Catherine]

> -Original Message-
> From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
> Sent: Monday, January 26, 2015 6:48 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Matthew Fortune; Moore, Catherine
> Subject: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain
> 
> Hi,
> 
> Here is a patch to clean up a large number of reported failures when a
> toolchain
> is configured with --with-nan=2008 for mips*-linux-gnu triplet and clean up a
> failures
> for mips-img-linux-gnu where nan2008 is set by the default.
> 
> In the former case, regression involves testing e.g. -mips4 with default
> options which
> causes emission of warnings that the -mips4 architecture does not support
> nan2008, and
> hence, the test is classified as a fail ("test for excess errors" type of 
> error).
> The patch implies -mnan=legacy switch for all tests that are run for ISA rev <
> 2.
> 
> In the latter case, even if we decrease the ISA level for incompatible options
> for
> the loongson vector extension tests, especially loongson-simd.c, a test that
> includes
> stdint.h or stdlib.h will end up including the glibc header 'stubs-.h>' 
> and
> will
> fail as the mipsr6 toolchain will only have stubs-o32_hard_2008.h. A toolchain
> supporting
> nan1985 will have the required stubs-o32_hard.h. The only neat solution
> AFAICS was to add
> a new effective target that tries to compile and include stdlib.h to check if 
> we
> have
> the proper support for the legacy NaN marking the concerned tests as
> UNSUPPORTED.
> 
> Regards,
> Robert
> 
> 2015-01-26  Robert Suchanek  
> 
> gcc/testsuite
>   * lib/target-supports.exp (check_effective_target_mips_nanlegacy):
> New.
>   * gcc.target/mips/loongson-simd.c: Require legacy NaN support.
>   * gcc.target/mips/mips.exp (mips-dg-options): Imply -mnan=legacy
> for
>   ISA rev < 2.
> ---

This patch is OK.

[PATCH RFC] Running auto-vectorization tests multiple times

[Robert Suchanek]

Hi,

I'm trying to lift the restriction to run auto-vectorization tests 
more than once and would like to check if I'm going in the right
direction. I attached a draft patch.

Currently, auto-vectorization tests are enabled by a call to
check_vect_support_and_set_flags procedure and if there is support
then the global DEFAULT_VECTFLAGS is modified and the procedure
returns true. However, this is problematic in the MIPS case as we
have Loongson vector support, Paired-Single (PS) instructions and
the new MIPS SIMD ASE (MSA). Loongson is the easiest as it cannot
be executed along with the options for PS and MSA (both require -mfp64)
and vice versa, but we can vectorise PS and MSA in a single run.
This obviously requires a possibility to run the same tests twice,
with -mpaired-single and -mmsa.

check_vect_support_and_set_flags is called in a few places:
- gcc.dg/graphite/graphite.exp
- gcc.dg/vect/vect.exp
- gfortran.dg/graphite/graphite.exp
- gfortran.dg/vect/vect.exp
- g++.dg/vect/vect.exp

The first complication is the use of variations of dg-runtest:
gcc-dg-runtest, g++-dg-runtest, gfortran-dg-runtest and the plain
dg-runtest.

The idea to enable multi execution is to add a new procedure,
et-dg-runtest, with similar arguments as the above but with
an additional argument taking the name of procedure for a callback.

et-dg-runtest would iterate over a list of all effective targets
i.e. global ET_TARGETS, setup by check_vect_support_and_set_flags,
add needed options for a target and check if we want to just compile
or run the tests by calling helpers.

Implementation would require a couple of helper procedures to make
it work, thus, for each  e.g. mips_loongson, mips_msa we would
define the following procedures in lib/target-supports.exp:
- add_options_for_ (optional) returning flags needed for 
- check_effective_target_ to check if we can compile
- check_effective_target__hw_available to check if we can run
- check_effective_target__runtime (optional) - calls the two
  above plus any other additional checks like OS environment, etc.

If a port wants to exploit multiple execution then  would 
need to be appended in vect_support_and_set_flags to the global
ET_TARGETS and add the aforementioned helper procedures.
Some ports already follow this convention to certain extent. However,
DEFAULT_VECTCFLAGS should not be set as the appropriate flags will
be added on the fly via add_options_for_ if it's defined.

If the port supports only one vector extension, no other changes are needed
and DEFAULT_VECTCFLAGS should be modified as per old behaviour.

Any other thoughts/suggestions? 

The patch is a concept and will not run MSA tests as the MSA support
is not in the trunk yet.

Regards,
Robert

[PATCH] Run vector tests for more than one effective target.

gcc/testsuite
* g++.dg/vect/vect.exp: Add and set new global ET_TARGETS. Call
g++-dg-runtest via et-dg-runtest.
* gcc.dg/graphite/graphite.exp: Likewise, but for gcc-dg-runtest.
* gcc.dg/vect/vect.exp: Likewise.
* gfortran.dg/graphite/graphite.exp: Likewise, but for
gfortran-dg-runtest.
* gfortran.dg/vect/vect.exp: Likewise.
* lib/target-supports.exp (check_mpaired_single_hw_available): New.
(check_mips_loongson_hw_available): Likewise.
(check_mips_msa_hw_available): Likewise.
(check_effective_target_mpaired_single_runtime): Likewise.
(check_effective_target_mips_loongson_runtime): Likewise.
(check_effective_target_mips_msa_runtime): Likewise.
(add_options_for_mpaired_single): Likewise.
(add_options_for_mips_msa): Likewise.
(check_effective_target_mips_msa): Likewise.
(et-dg-runtest): Likewise.
(vect_support_and_set_flags): Add supported MIPS targets to ET_TARGETS
list.
---
 gcc/testsuite/g++.dg/vect/vect.exp  |   16 +-
 gcc/testsuite/gcc.dg/graphite/graphite.exp  |6 +-
 gcc/testsuite/gcc.dg/vect/vect.exp  |  157 +++---
 gcc/testsuite/gfortran.dg/graphite/graphite.exp |7 +-
 gcc/testsuite/gfortran.dg/vect/vect.exp |   45 --
 gcc/testsuite/lib/target-supports.exp   |  195 ++-
 6 files changed, 340 insertions(+), 86 deletions(-)

diff --git a/gcc/testsuite/g++.dg/vect/vect.exp 
b/gcc/testsuite/g++.dg/vect/vect.exp
index aba1866..1e02d6b 100644
--- a/gcc/testsuite/g++.dg/vect/vect.exp
+++ b/gcc/testsuite/g++.dg/vect/vect.exp
@@ -39,6 +39,10 @@ set save-dg-do-what-default ${dg-do-what-default}
 global DEFAULT_VECTCFLAGS
 set DEFAULT_VECTCFLAGS ""
 
+# Reset list of effective targets to be checked against tests.
+global ET_TARGETS
+set ET_TARGETS ""
+
 # These flags are used for all targets.
 lappend DEFAULT_VECTCFLAGS "-O2" "-ftree-vectorize" "-fno-vect-cost-model"
 
@@ -58,10 +62,10 @@ lappend VECT_SLP_CFLAGS "-fdump-tree-slp-details"
 dg-init
 
 # Main loop.
-g++-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/pr*.{c,cc,S} ]] \
-

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Segher Boessenkool]

On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote:
> The GCC combine pass combines the insns even though they contain volatile
> registers.

"Local register variable", "register asm".

> This doesn't make sence.

On the contrary, it makes a lot of sense: you *want* insns 41+43 to be
combined in the below, that is the purpose of having local register
variables at all!

> The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164
> shows the expected asm command "mov r1, r1" is not generated."r1" is defined
> as a volatile register, and there are three insns related to r1:
> 
> (insn 98 97 40 3 (set (reg/v:SI 1 r1 [ b ]) (reg:SI 154 [ b ])) 
> (insn 41 40 43 3 (set (reg/f:SI 148)(reg/v:SI 1 r1 [ b ]))
> (insn 43 41 45 3 (parallel [
> (set (reg/v:SI 0 r0 [ ret ])
> (asm_operands/v:SI ("mov %2, %2  mov %3, %3  mov %4, %4")
> ("=r") 0 [
> (reg/v:SI 0 r0 [ a ])
> (reg/v:SI 1 r1 [ b ])
> (reg/v:SI 2 r2 [ c ])
> (mem/c:QI (reg/f:SI 148) [0 MEM[(char *)&temp]+0 S1
> A8])

98+41 was not combined.  Why?  41+43 was not combined.  Why?

Answer that and you likely know how to solve this problem properly :-)


Segher

RE: [PATCH][4.9] PR 64569 - Backport support for MIPS binutils 2.25

[Matthew Fortune]

> This is a minimal backport of features added to GCC 5 to enable use
> of binutils 2.25 with GCC 4.9 for MIPS soft-float builds. Further
> details in the PR:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64569
> 
> The commits which are being backported are listed below (the last
> one is posted but not committed yet).
> 
> r213870: Fix mips16.S for soft-float
> r213872: Pass -m(soft|hard|single|double)-float via ASM_SPEC
> r217446: Implement o32 FPXX (very minimal backport)
> r217939: Update configure check for HAVE_MIPS_DOT_MODULE
> r??: Make ASM_SPEC changes conditional on HAVE_MIPS_DOT_MODULE

Updated - The last one in the list is committed as:
r219867: MIPS: Only pass floating-point options to the assembler when necessary

I'm not sure who to CC as RM for GCC 4.9.

Thanks,
Matthew

> 
> gcc/
>   * config.in [!USED_FOR_TARGET] (HAVE_AS_DOT_MODULE): Undefine.
>   * config/mips/mips.h (FP_ASM_SPEC): New macro.
>   (ASM_SPEC): Use FP_ASM_SPEC.
>   * configure.ac (HAVE_AS_DOT_MODULE): Detect support for .module
>   and FPXX extensions.
> 
> libgcc/
>   * config/mips/mips16.S: Do not build for soft-float.
> 
> Once this is done I will do the same backport for GCC 4.8.
> 
> Tested to check that soft-float builds work with binutils 2.25 and
> the floating-point options are not passed for binutils 2.24.
> 
> Thanks,
> Matthew
> 
> ---
>  gcc/config.in   |  6 ++
>  gcc/config/mips/mips.h  | 19 ++-
>  gcc/configure   | 32 
>  gcc/configure.ac|  7 +++
>  libgcc/config/mips/mips16.S | 10 +++---
>  5 files changed, 70 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/config.in b/gcc/config.in
> index 1e85325..013a606 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -447,6 +447,12 @@
>  #endif
> 
> 
> +/* Define if the assembler understands .module. */
> +#ifndef USED_FOR_TARGET
> +#undef HAVE_AS_DOT_MODULE
> +#endif
> +
> +
>  /* Define if your assembler supports the -no-mul-bug-abort option. */
>  #ifndef USED_FOR_TARGET
>  #undef HAVE_AS_NO_MUL_BUG_ABORT_OPTION
> diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
> index a786d4c..ff88d98 100644
> --- a/gcc/config/mips/mips.h
> +++ b/gcc/config/mips/mips.h
> @@ -1163,6 +1163,22 @@ struct mips_cpu_info {
>  #define SUBTARGET_ASM_SPEC ""
>  #endif
> 
> +/* FP_ASM_SPEC represents the floating-point options that must be passed
> +   to the assembler when FPXX support exists.  Prior to that point the
> +   assembler could accept the options but were not required for
> +   correctness.  We only add the options when absolutely necessary
> +   because passing -msoft-float to the assembler will cause it to reject
> +   all hard-float instructions which may require some user code to be
> +   updated.  */
> +
> +#ifdef HAVE_AS_DOT_MODULE
> +#define FP_ASM_SPEC "\
> +%{mhard-float} %{msoft-float} \
> +%{msingle-float} %{mdouble-float}"
> +#else
> +#define FP_ASM_SPEC
> +#endif
> +
>  #undef ASM_SPEC
>  #define ASM_SPEC "\
>  %{G*} %(endian_spec) %{mips1} %{mips2} %{mips3} %{mips4} \
> @@ -1188,7 +1204,8 @@ struct mips_cpu_info {
>  %{mfp32} %{mfp64} %{mnan=*} \
>  %{mshared} %{mno-shared} \
>  %{msym32} %{mno-sym32} \
> -%{mtune=*} \
> +%{mtune=*}" \
> +FP_ASM_SPEC "\
>  %(subtarget_asm_spec)"
> 
>  /* Extra switches sometimes passed to the linker.  */
> diff --git a/gcc/configure b/gcc/configure
> index 291e463..d5b6879 100755
> --- a/gcc/configure
> +++ b/gcc/configure
> @@ -26140,6 +26140,38 @@ $as_echo "#define HAVE_AS_GNU_ATTRIBUTE 1"
> >>confdefs.h
> 
>  fi
> 
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for
> .module support" >&5
> +$as_echo_n "checking assembler for .module support... " >&6; }
> +if test "${gcc_cv_as_mips_dot_module+set}" = set; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  gcc_cv_as_mips_dot_module=no
> +  if test x$gcc_cv_as != x; then
> +$as_echo '.module mips2
> +   .module fp=xx' > conftest.s
> +if { ac_try='$gcc_cv_as $gcc_cv_as_flags -32 -o conftest.o conftest.s
> >&5'
> +  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> +  (eval $ac_try) 2>&5
> +  ac_status=$?
> +  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> +  test $ac_status = 0; }; }
> +then
> + gcc_cv_as_mips_dot_module=yes
> +else
> +  echo "configure: failed program was" >&5
> +  cat conftest.s >&5
> +fi
> +rm -f conftest.o conftest.s
> +  fi
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
> $gcc_cv_as_mips_dot_module" >&5
> +$as_echo "$gcc_cv_as_mips_dot_module" >&6; }
> +if test $gcc_cv_as_mips_dot_module = yes; then
> +
> +$as_echo "#define HAVE_AS_DOT_MODULE 1" >>confdefs.h
> +
> +fi
> +
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for
> .micromips support" >&5
>  $as_echo_n "checking assembler for .micromips support... " >&6; }
>  if test "${gcc_cv_as_micromips_support+set}" = set; then :
> dif

[PATCH, CHKP] Fix bounds return check for calls

[Ilya Enkovich]

Hi,

Currently chkp_call_returns_bounds_p works incorrectly for bounds narrowing.  
Also it doesn't reflect recent changes in calls instrumentation.  This patch 
fixes the problem.

Bootstrapped and checked on x86_64-unknown-linux-gnu.  OK for trunk?

Thanks,
Ilya
--
2015-01-26  Ilya Enkovich  

* tree-chkp.c (chkp_call_returns_bounds_p): Fix handling of
bounds narrowing, already instrumented calls and calls to
not instrumentable functions.

2015-01-26  Ilya Enkovich  

* gcc.target/i386/chkp-narrow-bounds.c: New.


diff --git a/gcc/testsuite/gcc.target/i386/chkp-narrow-bounds.c 
b/gcc/testsuite/gcc.target/i386/chkp-narrow-bounds.c
new file mode 100644
index 000..28bc622
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/chkp-narrow-bounds.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target mpx } */
+/* { dg-options "-fcheck-pointer-bounds -mmpx -O2 -fdump-tree-chkp" } */
+/* { dg-final { scan-tree-dump "bndcl" "chkp" } } */
+/* { dg-final { scan-tree-dump "bndcu" "chkp" } } */
+/* { dg-final { cleanup-tree-dump "chkp" } } */
+
+int
+test (int *p)
+{
+  int *p1 = __bnd_narrow_ptr_bounds (p - 10, p, sizeof (int) * 20);
+  return p1[10];
+}
diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
index e7649ef..b0a3a15 100644
--- a/gcc/tree-chkp.c
+++ b/gcc/tree-chkp.c
@@ -2113,13 +2113,19 @@ chkp_call_returns_bounds_p (gcall *call)
   if (gimple_call_internal_p (call))
 return false;
 
+  if (gimple_call_builtin_p (call, BUILT_IN_CHKP_NARROW_PTR_BOUNDS)
+  || chkp_gimple_call_builtin_p (call, BUILT_IN_CHKP_NARROW))
+return true;
+
+  if (gimple_call_with_bounds_p (call))
+return true;
+
   tree fndecl = gimple_call_fndecl (call);
 
   if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD)
 return false;
 
-  if (fndecl
-  && lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl)))
+  if (fndecl && !chkp_instrumentable_p (fndecl))
 return false;
 
   if (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)

Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

[David Malcolm]

On Mon, 2015-01-26 at 12:43 +0100, Gerald Pfeifer wrote:
> On Friday 2015-01-23 17:44, David Malcolm wrote:
> > The following patch builds and installs the JIT documentation for
> > the website (just HTML for now).
> > 
> > It's tricky to test (I don't have a copy of /www/gcc/bin/preprocess),
> > but I was able to use this to generate sane-looking documentation,
> > both for the .texi files, and for the JIT documentation.
> You can easily get the preprocess script by checking out wwwdocs,
> cf. https://gcc.gnu.org/about.html.

Thanks.

> That still will require MetaHTML which, sadly, became an abandoned
> FSF project, and will require a hack or two to build, so let's just
> go with your patch.
> 
> A few notes, though:
> 
> > maintainer-scripts/ChangeLog:
> > PR jit/64257
> > * update_web_docs_svn: Don't delete gcc/jit/docs,
> > since the jit docs are not .tex files (Makefile, .rst and
> > .png).  Special-case the building of the JIT docs (using
> > sphinx-build).  Special-case copying them up (since they
> > contain .css, .js and .png files in addition to .html, and
> > have nested subdirectories).
> 
> The "since" should be part of the code, not the ChangeLog.

Fair point; I've moved both of these to comments in the file.

> > diff --git a/maintainer-scripts/update_web_docs_svn 
> > b/maintainer-scripts/update_web_docs_svn
> > index c661220..c7eb890 100755
> > --- a/maintainer-scripts/update_web_docs_svn
> > +++ b/maintainer-scripts/update_web_docs_svn
> > +# The JIT is a special-case, using sphinx rather than texinfo.
> 
> special case

Fixed.

> > +# The jit Makefile uses "sphinx-build", which is packaged in
> > +# Fedora and EPEL 6 within "python-sphinx".
> 
> JIT (above) vs jit (here)?

I now use lowercase "jit" throughout.

> How about saying "...packaged in "python-sphinx" in Fedora and
> EPEL 6 and in "python-Sphinx" in openSUSE"?

Added.

> > +# Again, the jit is a special case, with nested subdirectories
> > +# below "jit", and with some non-HTML files (.png images from us,
> > +# plus .js and .css supplied by sphinx).
> > +for file in $(find jit \
> > +-name "*.html" -o -name "*.css" \
> > +-o -name "*.js" -o -name "*.png"); do
> 
> This looks like a Bash-ism.  Can you use backticks of something
> like 
> 
>   find ... | while read file; ...
> 
> ?

Done.

(Your proposal is superior since it avoids potentially long command
lines; but out of interest, why specifically avoid bash here?)

> > +cp $file $DOCSDIR/$file
> 
> Just "cp $file $DOCSDIR/" ?  This one may be a better of style,
> but is easier to tweak in case we need to quote later on, for
> example.

The jit documentation has a nested directory structure (e.g. there are 7
instances of an "index.html" within them), "$file" actually will contain
a path to a file, so we do need to have $file on the right-hand side of
the cp command.

I've added a comment to clarify that.

I'm attaching a revised patch which I hope addresses these issues;
tested (crudely) as before.

How does this look?

Thanks
Dave
>From 7f7e15881981228e51b347f23df6e3106ddd68ea Mon Sep 17 00:00:00 2001
From: David Malcolm 
Date: Fri, 23 Jan 2015 17:26:57 -0500
Subject: [PATCH] update_web_docs_svn: support the JIT documentation

maintainer-scripts/ChangeLog:
	* update_web_docs_svn: Don't delete gcc/jit/docs or
	gcc/jit/jit-common.h, gcc/jit/notes.txt. Special case the
	building of the jit docs (using sphinx-build).  Special case
	copying them up.
---
 maintainer-scripts/update_web_docs_svn | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/maintainer-scripts/update_web_docs_svn b/maintainer-scripts/update_web_docs_svn
index c661220..ac3bae6 100755
--- a/maintainer-scripts/update_web_docs_svn
+++ b/maintainer-scripts/update_web_docs_svn
@@ -111,11 +111,18 @@ fi
 # generator programs with the installed library, not the new one and
 # (b) to avoid packaging all the sources instead of only documentation
 # sources.
+# Note that we have to preserve gcc/jit/docs since the jit docs are
+# not .texi files (Makefile, .rst and .png), and the jit docs use
+# include directives to pull in content from jit/jit-common.h and
+# jit/notes.txt, so we have to preserve those also.
 find gcc -type f \( -name '*.texi' \
   -o -path gcc/gcc/doc/install.texi2html \
   -o -path gcc/gcc/doc/include/texinfo.tex \
   -o -path gcc/gcc/BASE-VER \
   -o -path gcc/gcc/DEV-PHASE \
+  -o -path "gcc/gcc/jit/docs/*" \
+  -o -path "gcc/gcc/jit/jit-common.h" \
+  -o -path "gcc/gcc/jit/notes.txt" \
   -o -print0 \) | xargs -0 rm -f
 
 # Build a tarball of the sources.
@@ -158,6 +165,16 @@ for file in $MANUALS; do
   fi
 done
 
+# The jit is a special-case, using sphinx rather than texinfo.
+# The jit Makefile uses "sphinx-build".  This is packaged in
+# Fedora and EPEL 6 within "python-sphinx", and in openSUSE
+# within "python-Sphinx".
+pushd gcc/gcc/jit/docs
+make html
+popd
+cp -a gcc/gcc/jit/docs/_build/html jit
+

[PATCH][AArch64] Remove an unused reload hook.

[Matthew Wahab]

Hello,

The LEGITIMIZE_RELOAD_ADDRESS macro is only needed for reload. Since the 
Aarch64 backend no longer supports reload, this macro is not needed and 
this patch removes it.


Tested aarch64-none-linux-gnu with gcc-check. No new failures.

Ok for trunk?
Matthew

gcc/
2015-01-26  Matthew Wahab  

* config/aarch64/aarch64.h (LEGITIMIZE_RELOAD_ADDRESS): Remove.
* config/aarch64/arch64-protos.h
(aarch64_legitimize_reload_address): Remove.
* config/aarch64/aarch64.c (aarch64_legitimize_reload_address):
Remove.diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 59c5824..da31d49 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -236,7 +236,6 @@ int aarch64_hard_regno_nregs (unsigned, machine_mode);
 int aarch64_simd_attr_length_move (rtx_insn *);
 int aarch64_uxt_size (int, HOST_WIDE_INT);
 rtx aarch64_final_eh_return_addr (void);
-rtx aarch64_legitimize_reload_address (rtx *, machine_mode, int, int, int);
 const char *aarch64_output_move_struct (rtx *operands);
 rtx aarch64_return_addr (int, rtx);
 rtx aarch64_simd_gen_const_vector_dup (machine_mode, int);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index dd49fcd..bfc9cfe 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -4667,120 +4667,6 @@ aarch64_legitimize_address (rtx x, rtx /* orig_x  */, machine_mode mode)
   return x;
 }
 
-/* Try a machine-dependent way of reloading an illegitimate address
-   operand.  If we find one, push the reload and return the new rtx.  */
-
-rtx
-aarch64_legitimize_reload_address (rtx *x_p,
-   machine_mode mode,
-   int opnum, int type,
-   int ind_levels ATTRIBUTE_UNUSED)
-{
-  rtx x = *x_p;
-
-  /* Do not allow mem (plus (reg, const)) if vector struct mode.  */
-  if (aarch64_vect_struct_mode_p (mode)
-  && GET_CODE (x) == PLUS
-  && REG_P (XEXP (x, 0))
-  && CONST_INT_P (XEXP (x, 1)))
-{
-  rtx orig_rtx = x;
-  x = copy_rtx (x);
-  push_reload (orig_rtx, NULL_RTX, x_p, NULL,
-		   BASE_REG_CLASS, GET_MODE (x), VOIDmode, 0, 0,
-		   opnum, (enum reload_type) type);
-  return x;
-}
-
-  /* We must recognize output that we have already generated ourselves.  */
-  if (GET_CODE (x) == PLUS
-  && GET_CODE (XEXP (x, 0)) == PLUS
-  && REG_P (XEXP (XEXP (x, 0), 0))
-  && CONST_INT_P (XEXP (XEXP (x, 0), 1))
-  && CONST_INT_P (XEXP (x, 1)))
-{
-  push_reload (XEXP (x, 0), NULL_RTX, &XEXP (x, 0), NULL,
-		   BASE_REG_CLASS, GET_MODE (x), VOIDmode, 0, 0,
-		   opnum, (enum reload_type) type);
-  return x;
-}
-
-  /* We wish to handle large displacements off a base register by splitting
- the addend across an add and the mem insn.  This can cut the number of
- extra insns needed from 3 to 1.  It is only useful for load/store of a
- single register with 12 bit offset field.  */
-  if (GET_CODE (x) == PLUS
-  && REG_P (XEXP (x, 0))
-  && CONST_INT_P (XEXP (x, 1))
-  && HARD_REGISTER_P (XEXP (x, 0))
-  && mode != TImode
-  && mode != TFmode
-  && aarch64_regno_ok_for_base_p (REGNO (XEXP (x, 0)), true))
-{
-  HOST_WIDE_INT val = INTVAL (XEXP (x, 1));
-  HOST_WIDE_INT low = val & 0xfff;
-  HOST_WIDE_INT high = val - low;
-  HOST_WIDE_INT offs;
-  rtx cst;
-  machine_mode xmode = GET_MODE (x);
-
-  /* In ILP32, xmode can be either DImode or SImode.  */
-  gcc_assert (xmode == DImode || xmode == SImode);
-
-  /* Reload non-zero BLKmode offsets.  This is because we cannot ascertain
-	 BLKmode alignment.  */
-  if (GET_MODE_SIZE (mode) == 0)
-	return NULL_RTX;
-
-  offs = low % GET_MODE_SIZE (mode);
-
-  /* Align misaligned offset by adjusting high part to compensate.  */
-  if (offs != 0)
-	{
-	  if (aarch64_uimm12_shift (high + offs))
-	{
-	  /* Align down.  */
-	  low = low - offs;
-	  high = high + offs;
-	}
-	  else
-	{
-	  /* Align up.  */
-	  offs = GET_MODE_SIZE (mode) - offs;
-	  low = low + offs;
-	  high = high + (low & 0x1000) - offs;
-	  low &= 0xfff;
-	}
-	}
-
-  /* Check for overflow.  */
-  if (high + low != val)
-	return NULL_RTX;
-
-  cst = GEN_INT (high);
-  if (!aarch64_uimm12_shift (high))
-	cst = force_const_mem (xmode, cst);
-
-  /* Reload high part into base reg, leaving the low part
-	 in the mem instruction.
-	 Note that replacing this gen_rtx_PLUS with plus_constant is
-	 wrong in this case because we rely on the
-	 (plus (plus reg c1) c2) structure being preserved so that
-	 XEXP (*p, 0) in push_reload below uses the correct term.  */
-  x = gen_rtx_PLUS (xmode,
-			gen_rtx_PLUS (xmode, XEXP (x, 0), cst),
-			GEN_INT (low));
-
-  push_reload (XEXP (x, 0), NULL_RTX, &XEXP (x, 0), NULL,
-		   BASE_REG_CLASS, xmode, VOIDmode, 0, 0,
-		   opnum, (enum reload_type) type);
-  return x;
-}
-

RFA: RL78: Minor prologue and epilogue enhancements

[Nick Clifton]

Hi DJ,

  The patch below contains two minor enhancements for the RL78 prologue
  and epilogue code.  The first is for when a large amount of local
  stack space needs to be allocated.  Rather than generating a long
  sequence of SUB SP, # instructions, the patched codes moves SP
  into AX, performs a single subtraction there, and then moves AX back
  into SP.

  The second optimization is for the G10.  It allows the BC, DE and HL
  registers to be pushed and popped directly, rather than via moving
  them into AX first.

  Tested with no regressions on an rl78-elf toolchain.

  OK to apply ?

Cheers
  Nick

2015-01-26  Nick Clifton  

* config/rl78/rl78.c (rl78_expand_prologue): In G10 mode push the
BC, DE and HL registers directly, not via AX.
When decrementing the stack pointer by a large amount, transfer SP
into AX and perform the subtraction there.
(rl78_expand_epilogue): Perform the inverse of the above
enhancements.

Index: gcc/config/rl78/rl78.c
===
--- gcc/config/rl78/rl78.c  (revision 220126)
+++ gcc/config/rl78/rl78.c  (working copy)
@@ -1230,6 +1230,7 @@
 {
   int i, fs;
   rtx sp = gen_rtx_REG (HImode, STACK_POINTER_REGNUM);
+  rtx ax = gen_rtx_REG (HImode, AX_REG);
   int rb = 0;
 
   if (rl78_is_naked_func ())
@@ -1253,15 +1254,19 @@
   for (i = 0; i < 16; i++)
 if (cfun->machine->need_to_push [i])
   {
+   int reg = i * 2;
+
if (TARGET_G10)
  {
-   if (i != 0)
- emit_move_insn (gen_rtx_REG (HImode, AX_REG), gen_rtx_REG 
(HImode, i * 2));
-   F (emit_insn (gen_push (gen_rtx_REG (HImode, AX_REG;
+   if (reg >= 8)
+ {
+   emit_move_insn (ax, gen_rtx_REG (HImode, reg));
+   reg = AX_REG;
+ }
  }
else
  {
-   int need_bank = i / 4;
+   int need_bank = i/4;
 
if (need_bank != rb)
  {
@@ -1268,9 +1273,9 @@
emit_insn (gen_sel_rb (GEN_INT (need_bank)));
rb = need_bank;
  }
-   F (emit_insn (gen_push (gen_rtx_REG (HImode, i * 2;
+ }
 
- }
+   F (emit_insn (gen_push (gen_rtx_REG (HImode, reg;
   }
 
   if (rb != 0)
@@ -1280,23 +1285,41 @@
   if (is_interrupt_func (cfun->decl) && cfun->machine->uses_es)
 {
   emit_insn (gen_movqi_from_es (gen_rtx_REG (QImode, A_REG)));
-  F (emit_insn (gen_push (gen_rtx_REG (HImode, AX_REG;
+  F (emit_insn (gen_push (ax)));
 }
 
   if (frame_pointer_needed)
 {
-  F (emit_move_insn (gen_rtx_REG (HImode, AX_REG),
-gen_rtx_REG (HImode, STACK_POINTER_REGNUM)));
-  F (emit_move_insn (gen_rtx_REG (HImode, FRAME_POINTER_REGNUM),
-gen_rtx_REG (HImode, AX_REG)));
+  F (emit_move_insn (ax, sp));
+  F (emit_move_insn (gen_rtx_REG (HImode, FRAME_POINTER_REGNUM), ax));
 }
 
   fs = cfun->machine->framesize_locals + cfun->machine->framesize_outgoing;
-  while (fs > 0)
+  if (fs > 0)
 {
-  int fs_byte = (fs > 254) ? 254 : fs;
-  F (emit_insn (gen_subhi3 (sp, sp, GEN_INT (fs_byte;
-  fs -= fs_byte;
+  /* If we need to subtract more than 254*3 then it is faster and
+smaller to move SP into AX and perform the subtraction there.  */
+  if (fs > 254 * 3)
+   {
+ rtx insn;
+
+ emit_move_insn (ax, sp);
+ emit_insn (gen_subhi3 (ax, ax, GEN_INT (fs)));
+ insn = emit_move_insn (sp, ax);
+ add_reg_note (insn, REG_FRAME_RELATED_EXPR,
+   gen_rtx_SET (SImode, sp,
+gen_rtx_PLUS (HImode, sp, GEN_INT (-fs;
+   }
+  else
+   {
+ while (fs > 0)
+   {
+ int fs_byte = (fs > 254) ? 254 : fs;
+
+ F (emit_insn (gen_subhi3 (sp, sp, GEN_INT (fs_byte;
+ fs -= fs_byte;
+   }
+   }
 }
 }
 
@@ -1306,6 +1329,7 @@
 {
   int i, fs;
   rtx sp = gen_rtx_REG (HImode, STACK_POINTER_REGNUM);
+  rtx ax = gen_rtx_REG (HImode, AX_REG);
   int rb = 0;
 
   if (rl78_is_naked_func ())
@@ -1313,20 +1337,27 @@
 
   if (frame_pointer_needed)
 {
-  emit_move_insn (gen_rtx_REG (HImode, AX_REG),
- gen_rtx_REG (HImode, FRAME_POINTER_REGNUM));
-  emit_move_insn (gen_rtx_REG (HImode, STACK_POINTER_REGNUM),
- gen_rtx_REG (HImode, AX_REG));
+  emit_move_insn (ax, gen_rtx_REG (HImode, FRAME_POINTER_REGNUM));
+  emit_move_insn (sp, ax);
 }
   else
 {
   fs = cfun->machine->framesize_locals + cfun->machine->framesize_outgoing;
-  while (fs > 0)
+  if (fs > 254 * 3)
{
- int fs_byte = (fs > 254) ? 254 : fs;
+ emit_move_insn (ax, sp);
+ emit_insn (gen_addhi3 (ax, ax, GEN_INT (fs)));
+ emit_move_insn (sp, ax);
+   }
+  else
+   

RFA: RL78: Add assembler versions of some libgcc functions.

[Nick Clifton]

Hi DJ,

  The attached patch provides some enhancements to libgcc for the RL78.
  It includes faster and smaller versions of the bit counting and simple
  floating point functions, and a version of the integer multiply
  support function designed to work on the G10.

  Tested on an rl78-elf toolchain with no regressions.

  OK to apply ?

Cheers
  Nick
  
2015-01-26  Nick Clifton  

* config/rl78/cmpsi2.S: Use function start and end macros.
(__gcc_bcmp): New function.
* config/rl78/lshrsi3.S: Use function start and end macros.
* config/rl78/mulsi3.S: Add support for G10.
(__mulqi3): New function for G10.
* config/rl78/signbit.S: Use function start and end macros.
* config/rl78/t-rl78 (LIB2ADD): Add bit-count.S, fpbit-sf.S and
fpmath-sf.S.
(LIB2FUNCS_EXCLUDE): Define.
(LIB2FUNCS_ST): Define.
* config/rl78/trampoline.S: Use function start and end macros.
* config/rl78/vregs.h (START_FUNC): New macro.
(START_ANOTHER_FUNC): New macro.
(END_FUNC): New macro.
(END_ANOTHER_FUNC): New macro.
* config/rl78/bit-count.S: New file.  Contains assembler
implementations of the bit counting functions: ___clzhi2,
__clzsi2, ctzhi2, ctzsi2, ffshi2, ffssi2, __partityhi2,
__paritysi2, __popcounthi2 and __popcountsi2.
* config/rl78/fpbit-sf.S: New file.  Contains assembler
implementationas of the math functions: __negsf2, __cmpsf2,
__eqsf2, __nesf2, __lesf2, __ltsf2, __gesf2, gtsf2, __unordsf2,
__fixsfsi,  __fixunssfsi, __floatsisf and __floatunssisf.
* config/rl78/fpmath-sf.S: New file.  Contains assembler
implementations of the math functions: __subsf3, __addsf3,
__mulsf3 and __divsf3



rl78.libgcc.patch.xz
Description: application/xz

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Segher Boessenkool]

> > The test case listed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164
> > shows the expected asm command "mov r1, r1" is not generated."r1" is defined
> > as a volatile register, and there are three insns related to r1:
> > 
> > (insn 98 97 40 3 (set (reg/v:SI 1 r1 [ b ]) (reg:SI 154 [ b ])) 
> > (insn 41 40 43 3 (set (reg/f:SI 148)(reg/v:SI 1 r1 [ b ]))
> > (insn 43 41 45 3 (parallel [
> > (set (reg/v:SI 0 r0 [ ret ])
> > (asm_operands/v:SI ("mov %2, %2  mov %3, %3  mov %4, %4")
> > ("=r") 0 [
> > (reg/v:SI 0 r0 [ a ])
> > (reg/v:SI 1 r1 [ b ])
> > (reg/v:SI 2 r2 [ c ])
> > (mem/c:QI (reg/f:SI 148) [0 MEM[(char *)&temp]+0 S1
> > A8])
> 
> 98+41 was not combined.  Why?  41+43 was not combined.  Why?

Actually, it looks like it first rejected 98+41, then combined 41+43 (and
that is fine), and then it combined 98+43?


Segher

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[H.J. Lu]

On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak  wrote:
> On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak  wrote:
>> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
>>  wrote:
>>> On Saturday 24 January 2015, Uros Bizjak wrote:
 On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak  wrote:
 > Hello!
 >
 >>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote:
 >>> > I recently wanted to use multiversioning for BMI2 specific extensions
 >>> > PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add
 >>> > it, and also added AES, F16C and BMI1 for completeness.
 >>>
 >>> AES nor F16C doesn't make any sense IMHO for multiversioning, you need
 >>> special intrinsics for that anyway and when you use them, the function
 >>> will fail to compile without those features.
 >>> Multiversioning only makes sense for ISA features the compiler uses for
 >>> normal C/C++ code without any intrinsics.
 >>
 >> Patch reduced to just adding BMI and BMI2 multiversioning:
 > +2014-12-29  Allan Sandfeld Jensen  
 > +
 > + * config/i386/i386.c (get_builtin_code_for_version): Add
 > + support for BMI and BMI2 multiversion functions.
 >
 > +2014-12-29  Allan Sandfeld Jensen  
 > +
 > + * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
 > + * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
 >
 > +2014-12-29  Allan Sandfeld Jensen  
 > +
 > + * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI and
 > + FEATURE_BMI2.
 > + (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
 >
 > OK for mainline

 Allan, did you commit the patch to mainline? I don't see it in SVN logs.

 (If you don't have SVN commit access, please mention it in the patch
 submission, so someone will commit the patch for you).

>>> Sorry. I don't have SVN commit access.
>>
>> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in
>> gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to
>> missing parenthesis).
>
> ... and now with committed ChangeLog and patch.
>
> gcc/ChangeLog:
>
> * config/i386/i386.c (get_builtin_code_for_version): Add
> support for BMI and BMI2 multiversion functions.
> (fold_builtin_cpu): Add F_BMI and F_BMI2.
>
> libgcc/ChangeLog:
>
> * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI and
> FEATURE_BMI2.
> (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>
> testsuite/ChangeLog:
>
> * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
> * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9ec40cb..441911d 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree *predica
te_list)
 P_PROC_SSE4_A,
 P_SSE4_1,
 P_SSE4_2,
-P_PROC_SSE4_2,
 P_POPCNT,
+P_PROC_SSE4_2,
 P_AVX,
 P_PROC_AVX,
+P_BMI,
+P_PROC_BMI,
 P_FMA4,
 P_XOP,
 P_PROC_XOP,
 P_FMA,
 P_PROC_FMA,
+P_BMI2,
 P_AVX2,
 P_PROC_AVX2,
 P_AVX512F,

This changed the priority of P_POPCNT and caused

FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test

on Nehalem and Westmere machines:

mv1.exe: /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51:
int main(): Assertion `val == 5' failed.

since "val" is 6 now.


-- 
H.J.

Re: [COMMITTED] Merge libffi with upstream

[Richard Henderson]

On 01/26/2015 06:19 AM, Rainer Orth wrote:
> 2015-01-16  Rainer Orth  
> 
>   * testsuite/lib/libffi.exp: Load target-supports.exp.
>   (run-many-tests): Only set targetabis for ia32.

Ok.


r~

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[H.J. Lu]

On Mon, Jan 26, 2015 at 10:04 AM, H.J. Lu  wrote:
> On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak  wrote:
>> On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak  wrote:
>>> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
>>>  wrote:
 On Saturday 24 January 2015, Uros Bizjak wrote:
> On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak  wrote:
> > Hello!
> >
> >>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote:
> >>> > I recently wanted to use multiversioning for BMI2 specific 
> >>> > extensions
> >>> > PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add
> >>> > it, and also added AES, F16C and BMI1 for completeness.
> >>>
> >>> AES nor F16C doesn't make any sense IMHO for multiversioning, you need
> >>> special intrinsics for that anyway and when you use them, the function
> >>> will fail to compile without those features.
> >>> Multiversioning only makes sense for ISA features the compiler uses 
> >>> for
> >>> normal C/C++ code without any intrinsics.
> >>
> >> Patch reduced to just adding BMI and BMI2 multiversioning:
> > +2014-12-29  Allan Sandfeld Jensen  
> > +
> > + * config/i386/i386.c (get_builtin_code_for_version): Add
> > + support for BMI and BMI2 multiversion functions.
> >
> > +2014-12-29  Allan Sandfeld Jensen  
> > +
> > + * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
> > + * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
> >
> > +2014-12-29  Allan Sandfeld Jensen  
> > +
> > + * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI and
> > + FEATURE_BMI2.
> > + (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
> >
> > OK for mainline
>
> Allan, did you commit the patch to mainline? I don't see it in SVN logs.
>
> (If you don't have SVN commit access, please mention it in the patch
> submission, so someone will commit the patch for you).
>
 Sorry. I don't have SVN commit access.
>>>
>>> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in
>>> gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to
>>> missing parenthesis).
>>
>> ... and now with committed ChangeLog and patch.
>>
>> gcc/ChangeLog:
>>
>> * config/i386/i386.c (get_builtin_code_for_version): Add
>> support for BMI and BMI2 multiversion functions.
>> (fold_builtin_cpu): Add F_BMI and F_BMI2.
>>
>> libgcc/ChangeLog:
>>
>> * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI and
>> FEATURE_BMI2.
>> (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>>
>> testsuite/ChangeLog:
>>
>> * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>> * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>>
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 9ec40cb..441911d 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree 
> *predica
> te_list)
>  P_PROC_SSE4_A,
>  P_SSE4_1,
>  P_SSE4_2,
> -P_PROC_SSE4_2,
>  P_POPCNT,
> +P_PROC_SSE4_2,
>  P_AVX,
>  P_PROC_AVX,
> +P_BMI,
> +P_PROC_BMI,
>  P_FMA4,
>  P_XOP,
>  P_PROC_XOP,
>  P_FMA,
>  P_PROC_FMA,
> +P_BMI2,
>  P_AVX2,
>  P_PROC_AVX2,
>  P_AVX512F,
>
> This changed the priority of P_POPCNT and caused
>
> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
>
> on Nehalem and Westmere machines:
>
> mv1.exe: /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51:
> int main(): Assertion `val == 5' failed.
>
> since "val" is 6 now.

I opened:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64806

-- 
H.J.

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Allan Sandfeld Jensen]

On Monday 26 January 2015, H.J. Lu wrote:
> On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak  wrote:
> > On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak  wrote:
> >> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
> >> 
> >>  wrote:
> >>> On Saturday 24 January 2015, Uros Bizjak wrote:
>  On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak  wrote:
>  > Hello!
>  > 
>  >>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen 
wrote:
>  >>> > I recently wanted to use multiversioning for BMI2 specific
>  >>> > extensions PDEP/PEXT, and noticed it wasn't there. So I wrote
>  >>> > this patch to add it, and also added AES, F16C and BMI1 for
>  >>> > completeness.
>  >>> 
>  >>> AES nor F16C doesn't make any sense IMHO for multiversioning, you
>  >>> need special intrinsics for that anyway and when you use them,
>  >>> the function will fail to compile without those features.
>  >>> Multiversioning only makes sense for ISA features the compiler
>  >>> uses for normal C/C++ code without any intrinsics.
>  >> 
>  >> Patch reduced to just adding BMI and BMI2 multiversioning:
>  > +2014-12-29  Allan Sandfeld Jensen  
>  > +
>  > + * config/i386/i386.c (get_builtin_code_for_version): Add
>  > + support for BMI and BMI2 multiversion functions.
>  > 
>  > +2014-12-29  Allan Sandfeld Jensen  
>  > +
>  > + * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>  > + * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>  > 
>  > +2014-12-29  Allan Sandfeld Jensen  
>  > +
>  > + * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI
>  > and + FEATURE_BMI2.
>  > + (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>  > 
>  > OK for mainline
>  
>  Allan, did you commit the patch to mainline? I don't see it in SVN
>  logs.
>  
>  (If you don't have SVN commit access, please mention it in the patch
>  submission, so someone will commit the patch for you).
> >>> 
> >>> Sorry. I don't have SVN commit access.
> >> 
> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in
> >> gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to
> >> missing parenthesis).
> > 
> > ... and now with committed ChangeLog and patch.
> > 
> > gcc/ChangeLog:
> > * config/i386/i386.c (get_builtin_code_for_version): Add
> > support for BMI and BMI2 multiversion functions.
> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
> > 
> > libgcc/ChangeLog:
> > * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI
> > and FEATURE_BMI2.
> > (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
> > 
> > testsuite/ChangeLog:
> > * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
> > * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 9ec40cb..441911d 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree
> *predica te_list)
>  P_PROC_SSE4_A,
>  P_SSE4_1,
>  P_SSE4_2,
> -P_PROC_SSE4_2,
>  P_POPCNT,
> +P_PROC_SSE4_2,
>  P_AVX,
>  P_PROC_AVX,
> +P_BMI,
> +P_PROC_BMI,
>  P_FMA4,
>  P_XOP,
>  P_PROC_XOP,
>  P_FMA,
>  P_PROC_FMA,
> +P_BMI2,
>  P_AVX2,
>  P_PROC_AVX2,
>  P_AVX512F,
> 
> This changed the priority of P_POPCNT and caused
> 
> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
> 
> on Nehalem and Westmere machines:
> 
> mv1.exe:
> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51: int
> main(): Assertion `val == 5' failed.
> 
> since "val" is 6 now.

Right. I am not sure why popcnt was prioritized below arch=corei7. The logic 
is supposed to be that any target that includes an extension is prioritized 
above that extension. I included the change in the order in i386.c, but not 
the updated test. It is probably better to not change the order in i386.c, or 
at least change that in a separate commit.

`Allan

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[H.J. Lu]

On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen
 wrote:
> On Monday 26 January 2015, H.J. Lu wrote:
>> On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak  wrote:
>> > On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak  wrote:
>> >> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
>> >>
>> >>  wrote:
>> >>> On Saturday 24 January 2015, Uros Bizjak wrote:
>>  On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak  wrote:
>>  > Hello!
>>  >
>>  >>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen
> wrote:
>>  >>> > I recently wanted to use multiversioning for BMI2 specific
>>  >>> > extensions PDEP/PEXT, and noticed it wasn't there. So I wrote
>>  >>> > this patch to add it, and also added AES, F16C and BMI1 for
>>  >>> > completeness.
>>  >>>
>>  >>> AES nor F16C doesn't make any sense IMHO for multiversioning, you
>>  >>> need special intrinsics for that anyway and when you use them,
>>  >>> the function will fail to compile without those features.
>>  >>> Multiversioning only makes sense for ISA features the compiler
>>  >>> uses for normal C/C++ code without any intrinsics.
>>  >>
>>  >> Patch reduced to just adding BMI and BMI2 multiversioning:
>>  > +2014-12-29  Allan Sandfeld Jensen  
>>  > +
>>  > + * config/i386/i386.c (get_builtin_code_for_version): Add
>>  > + support for BMI and BMI2 multiversion functions.
>>  >
>>  > +2014-12-29  Allan Sandfeld Jensen  
>>  > +
>>  > + * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>>  > + * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>>  >
>>  > +2014-12-29  Allan Sandfeld Jensen  
>>  > +
>>  > + * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI
>>  > and + FEATURE_BMI2.
>>  > + (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>>  >
>>  > OK for mainline
>> 
>>  Allan, did you commit the patch to mainline? I don't see it in SVN
>>  logs.
>> 
>>  (If you don't have SVN commit access, please mention it in the patch
>>  submission, so someone will commit the patch for you).
>> >>>
>> >>> Sorry. I don't have SVN commit access.
>> >>
>> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in
>> >> gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to
>> >> missing parenthesis).
>> >
>> > ... and now with committed ChangeLog and patch.
>> >
>> > gcc/ChangeLog:
>> > * config/i386/i386.c (get_builtin_code_for_version): Add
>> > support for BMI and BMI2 multiversion functions.
>> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
>> >
>> > libgcc/ChangeLog:
>> > * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI
>> > and FEATURE_BMI2.
>> > (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>> >
>> > testsuite/ChangeLog:
>> > * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>> > * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index 9ec40cb..441911d 100644
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree
>> *predica te_list)
>>  P_PROC_SSE4_A,
>>  P_SSE4_1,
>>  P_SSE4_2,
>> -P_PROC_SSE4_2,
>>  P_POPCNT,
>> +P_PROC_SSE4_2,
>>  P_AVX,
>>  P_PROC_AVX,
>> +P_BMI,
>> +P_PROC_BMI,
>>  P_FMA4,
>>  P_XOP,
>>  P_PROC_XOP,
>>  P_FMA,
>>  P_PROC_FMA,
>> +P_BMI2,
>>  P_AVX2,
>>  P_PROC_AVX2,
>>  P_AVX512F,
>>
>> This changed the priority of P_POPCNT and caused
>>
>> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
>> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
>> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
>>
>> on Nehalem and Westmere machines:
>>
>> mv1.exe:
>> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51: int
>> main(): Assertion `val == 5' failed.
>>
>> since "val" is 6 now.
>
> Right. I am not sure why popcnt was prioritized below arch=corei7. The logic
> is supposed to be that any target that includes an extension is prioritized

I don't understand your question.  popcnt feature is separate from -march.
Its priority has nothing to do with -march=corei7.

> above that extension. I included the change in the order in i386.c, but not
> the updated test. It is probably better to not change the order in i386.c, or
> at least change that in a separate commit.


-- 
H.J.

Re: [PATCH] update_web_docs_svn: support the JIT docs (PR jit/64257)

[Mike Stump]

On Jan 26, 2015, at 3:43 AM, Gerald Pfeifer  wrote:
>> +# Again, the jit is a special case, with nested subdirectories
>> +# below "jit", and with some non-HTML files (.png images from us,
>> +# plus .js and .css supplied by sphinx).
>> +for file in $(find jit \
>> +-name "*.html" -o -name "*.css" \
>> +-o -name "*.js" -o -name "*.png"); do
> 
> This looks like a Bash-ism.  Can you use back ticks

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

$() is standard and preferred over back ticks.  :-)  Life goes on.

Re: [PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)

[Jeff Law]

On 01/26/15 06:34, Jakub Jelinek wrote:

On Mon, Jan 26, 2015 at 01:11:01PM +0100, Richard Biener wrote:

I agree that freeing the cfg and immediately computing it again doesn't make
sense, but I just don't see this patch being incompatible with that.


I wonder if handing over pass pipeline control to targets at
machine_reorg time (including free_cfg) makes sense...
(either giving control back for stuff like final() or make it call
into the middle-end again).


Perhaps, but not sure if such changes are desirable for stage4.
And certainly unsuitable for release branches.
That would seem to take a big mistake (machine_reorg) and make it even 
worse.


Jeff

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Allan Sandfeld Jensen]

On Monday 26 January 2015, you wrote:
> On Mon, Jan 26, 2015 at 10:38 AM, Allan Sandfeld Jensen
> 
>  wrote:
> > On Monday 26 January 2015, H.J. Lu wrote:
> >> On Sun, Jan 25, 2015 at 10:37 AM, Uros Bizjak  wrote:
> >> > On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak  wrote:
> >> >> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
> >> >> 
> >> >>  wrote:
> >> >>> On Saturday 24 January 2015, Uros Bizjak wrote:
> >>  On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak  
wrote:
> >>  > Hello!
> >>  > 
> >>  >>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen
> > 
> > wrote:
> >>  >>> > I recently wanted to use multiversioning for BMI2 specific
> >>  >>> > extensions PDEP/PEXT, and noticed it wasn't there. So I wrote
> >>  >>> > this patch to add it, and also added AES, F16C and BMI1 for
> >>  >>> > completeness.
> >>  >>> 
> >>  >>> AES nor F16C doesn't make any sense IMHO for multiversioning,
> >>  >>> you need special intrinsics for that anyway and when you use
> >>  >>> them, the function will fail to compile without those
> >>  >>> features. Multiversioning only makes sense for ISA features
> >>  >>> the compiler uses for normal C/C++ code without any
> >>  >>> intrinsics.
> >>  >> 
> >>  >> Patch reduced to just adding BMI and BMI2 multiversioning:
> >>  > +2014-12-29  Allan Sandfeld Jensen  
> >>  > +
> >>  > + * config/i386/i386.c (get_builtin_code_for_version): Add
> >>  > + support for BMI and BMI2 multiversion functions.
> >>  > 
> >>  > +2014-12-29  Allan Sandfeld Jensen  
> >>  > +
> >>  > + * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
> >>  > + * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
> >>  > 
> >>  > +2014-12-29  Allan Sandfeld Jensen  
> >>  > +
> >>  > + * config/i386/cpuinfo.c (enum processor_features): Add
> >>  > FEATURE_BMI and + FEATURE_BMI2.
> >>  > + (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
> >>  > 
> >>  > OK for mainline
> >>  
> >>  Allan, did you commit the patch to mainline? I don't see it in SVN
> >>  logs.
> >>  
> >>  (If you don't have SVN commit access, please mention it in the
> >>  patch submission, so someone will commit the patch for you).
> >> >>> 
> >> >>> Sorry. I don't have SVN commit access.
> >> >> 
> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part
> >> >> in gcc/config/i386/i386.c, and mv17.C test didn't compile at all due
> >> >> to missing parenthesis).
> >> > 
> >> > ... and now with committed ChangeLog and patch.
> >> > 
> >> > gcc/ChangeLog:
> >> > * config/i386/i386.c (get_builtin_code_for_version): Add
> >> > support for BMI and BMI2 multiversion functions.
> >> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
> >> > 
> >> > libgcc/ChangeLog:
> >> > * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI
> >> > and FEATURE_BMI2.
> >> > (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
> >> > 
> >> > testsuite/ChangeLog:
> >> > * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
> >> > * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
> >> 
> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> >> index 9ec40cb..441911d 100644
> >> --- a/gcc/config/i386/i386.c
> >> +++ b/gcc/config/i386/i386.c
> >> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree
> >> *predica te_list)
> >> 
> >>  P_PROC_SSE4_A,
> >>  P_SSE4_1,
> >>  P_SSE4_2,
> >> 
> >> -P_PROC_SSE4_2,
> >> 
> >>  P_POPCNT,
> >> 
> >> +P_PROC_SSE4_2,
> >> 
> >>  P_AVX,
> >>  P_PROC_AVX,
> >> 
> >> +P_BMI,
> >> +P_PROC_BMI,
> >> 
> >>  P_FMA4,
> >>  P_XOP,
> >>  P_PROC_XOP,
> >>  P_FMA,
> >>  P_PROC_FMA,
> >> 
> >> +P_BMI2,
> >> 
> >>  P_AVX2,
> >>  P_PROC_AVX2,
> >>  P_AVX512F,
> >> 
> >> This changed the priority of P_POPCNT and caused
> >> 
> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
> >> 
> >> on Nehalem and Westmere machines:
> >> 
> >> mv1.exe:
> >> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51:
> >> int main(): Assertion `val == 5' failed.
> >> 
> >> since "val" is 6 now.
> > 
> > Right. I am not sure why popcnt was prioritized below arch=corei7. The
> > logic is supposed to be that any target that includes an extension is
> > prioritized
> 
> I don't understand your question.  popcnt feature is separate from -march.
> Its priority has nothing to do with -march=corei7.
> 
arch=corei7 implies popcnt. See PTA_NEHALEM in i386.c. The test would probably 
work with -march=core2.

AFAIK The logic of the priorities in multiversioning is that architecture 
specific functions are chosen over feature specific, unless the feature 

[PATCH, i386]: Fix PR64795, too many memor references for 'lea'

[Uros Bizjak]

Hello!

Attached patch tightens the condition for TYPE_LEA instructions.

2015-01-26  Uros Bizjak  

PR target/64795
* config/i386/i386.md (*movdi_internal): Also check operand 0
to determine TYPE_LEA operand.
(*movsi_internal): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Unfortunately, I was not able to construct a valid testcase, but the
problem is fixed in an obvious way.

Patch was committed to mainline, will be backported to release branches.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 220126)
+++ config/i386/i386.md (working copy)
@@ -2208,7 +2208,8 @@
  (const_string "ssecvt")
(eq_attr "alternative" "21,22,23,24")
  (const_string "mskmov")
-   (match_operand 1 "pic_32bit_operand")
+   (and (match_operand 0 "register_operand")
+(match_operand 1 "pic_32bit_operand"))
  (const_string "lea")
   ]
   (const_string "imov")))
@@ -2361,7 +2362,8 @@
  (const_string "ssemov")
(eq_attr "alternative" "13,14")
  (const_string "mskmov")
-   (match_operand 1 "pic_32bit_operand")
+   (and (match_operand 0 "register_operand")
+(match_operand 1 "pic_32bit_operand"))
  (const_string "lea")
   ]
   (const_string "imov")))

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[H.J. Lu]

On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
 wrote:
>> >> >>
>> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part
>> >> >> in gcc/config/i386/i386.c, and mv17.C test didn't compile at all due
>> >> >> to missing parenthesis).
>> >> >
>> >> > ... and now with committed ChangeLog and patch.
>> >> >
>> >> > gcc/ChangeLog:
>> >> > * config/i386/i386.c (get_builtin_code_for_version): Add
>> >> > support for BMI and BMI2 multiversion functions.
>> >> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
>> >> >
>> >> > libgcc/ChangeLog:
>> >> > * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI
>> >> > and FEATURE_BMI2.
>> >> > (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>> >> >
>> >> > testsuite/ChangeLog:
>> >> > * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>> >> > * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>> >>
>> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> >> index 9ec40cb..441911d 100644
>> >> --- a/gcc/config/i386/i386.c
>> >> +++ b/gcc/config/i386/i386.c
>> >> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree
>> >> *predica te_list)
>> >>
>> >>  P_PROC_SSE4_A,
>> >>  P_SSE4_1,
>> >>  P_SSE4_2,
>> >>
>> >> -P_PROC_SSE4_2,
>> >>
>> >>  P_POPCNT,
>> >>
>> >> +P_PROC_SSE4_2,
>> >>
>> >>  P_AVX,
>> >>  P_PROC_AVX,
>> >>
>> >> +P_BMI,
>> >> +P_PROC_BMI,
>> >>
>> >>  P_FMA4,
>> >>  P_XOP,
>> >>  P_PROC_XOP,
>> >>  P_FMA,
>> >>  P_PROC_FMA,
>> >>
>> >> +P_BMI2,
>> >>
>> >>  P_AVX2,
>> >>  P_PROC_AVX2,
>> >>  P_AVX512F,
>> >>
>> >> This changed the priority of P_POPCNT and caused
>> >>
>> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
>> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
>> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
>> >>
>> >> on Nehalem and Westmere machines:
>> >>
>> >> mv1.exe:
>> >> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51:
>> >> int main(): Assertion `val == 5' failed.
>> >>
>> >> since "val" is 6 now.
>> >
>> > Right. I am not sure why popcnt was prioritized below arch=corei7. The
>> > logic is supposed to be that any target that includes an extension is
>> > prioritized
>>
>> I don't understand your question.  popcnt feature is separate from -march.
>> Its priority has nothing to do with -march=corei7.
>>
> arch=corei7 implies popcnt. See PTA_NEHALEM in i386.c. The test would probably
> work with -march=core2.
>
> AFAIK The logic of the priorities in multiversioning is that architecture
> specific functions are chosen over feature specific, unless the feature is one
> that isn't required by the architecture.
>

On SSE4.2 machines, we should choose

int __attribute__ ((target("arch=corei7"))) foo ();

over

int __attribute__ ((target("popcnt"))) foo ();

But we shouldn't choose

int __attribute__ ((target("arch=corei7"))) foo ();

over

int __attribute__ ((target("arch=corei7,popcnt"))) foo ();

-- 
H.J.

Re: [PATCH] [gcc, combine] PR46164: Don't combine the insns if a volatile register is contained.

[Segher Boessenkool]

On Mon, Jan 26, 2015 at 05:55:52PM +0800, Hale Wang wrote:
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 5c763b4..cf48666 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -2004,6 +2004,13 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn
> *pred ATTRIBUTE_UNUSED,
> return 0;
>   }
>  
> +  /* If src contains a volatile register, reject, because the register may
> + possibly be used in a asm operand.  The combined insn may cause the
> asm
> + operand to be generated unexpectly.  */
> +
> +  if (REG_P (src) && REG_USERVAR_P (src))
> +return 0;
> +
>/* If INSN contains anything volatile, or is an `asm' (whether volatile
>   or not), reject, unless nothing volatile comes between it and I3 */


> diff --git a/gcc/testsuite/gcc.target/arm/pr46164.c
> b/gcc/testsuite/gcc.target/arm/pr46164.c
> new file mode 100644
> index 000..ad3b7cb
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pr46164.c
> @@ -0,0 +1,26 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mcpu=cortex-m3 -mthumb -O1" } */

Just "-O1" reproduces the problem here, FWIW.


Could you try this patch please?


Segher


diff --git a/gcc/combine.c b/gcc/combine.c
index 58de157..10c3b0e 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1928,6 +1928,10 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn 
*pred ATTRIBUTE_UNUSED,
   set = expand_field_assignment (set);
   src = SET_SRC (set), dest = SET_DEST (set);
 
+  /* Don't eliminate a register variable.  */
+  if (REG_P (dest) && REG_USERVAR_P (dest))
+return 0;
+
   /* Don't eliminate a store in the stack pointer.  */
   if (dest == stack_pointer_rtx
   /* Don't combine with an insn that sets a register to itself if it has

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Allan Sandfeld Jensen]

On Monday 26 January 2015, H.J. Lu wrote:
> On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
> 
>  wrote:
> >> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu
> >> >> >> part in gcc/config/i386/i386.c, and mv17.C test didn't compile at
> >> >> >> all due to missing parenthesis).
> >> >> > 
> >> >> > ... and now with committed ChangeLog and patch.
> >> >> > 
> >> >> > gcc/ChangeLog:
> >> >> > * config/i386/i386.c (get_builtin_code_for_version): Add
> >> >> > support for BMI and BMI2 multiversion functions.
> >> >> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
> >> >> > 
> >> >> > libgcc/ChangeLog:
> >> >> > * config/i386/cpuinfo.c (enum processor_features): Add
> >> >> > FEATURE_BMI and FEATURE_BMI2.
> >> >> > (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
> >> >> > 
> >> >> > testsuite/ChangeLog:
> >> >> > * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
> >> >> > * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
> >> >> 
> >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> >> >> index 9ec40cb..441911d 100644
> >> >> --- a/gcc/config/i386/i386.c
> >> >> +++ b/gcc/config/i386/i386.c
> >> >> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl,
> >> >> tree *predica te_list)
> >> >> 
> >> >>  P_PROC_SSE4_A,
> >> >>  P_SSE4_1,
> >> >>  P_SSE4_2,
> >> >> 
> >> >> -P_PROC_SSE4_2,
> >> >> 
> >> >>  P_POPCNT,
> >> >> 
> >> >> +P_PROC_SSE4_2,
> >> >> 
> >> >>  P_AVX,
> >> >>  P_PROC_AVX,
> >> >> 
> >> >> +P_BMI,
> >> >> +P_PROC_BMI,
> >> >> 
> >> >>  P_FMA4,
> >> >>  P_XOP,
> >> >>  P_PROC_XOP,
> >> >>  P_FMA,
> >> >>  P_PROC_FMA,
> >> >> 
> >> >> +P_BMI2,
> >> >> 
> >> >>  P_AVX2,
> >> >>  P_PROC_AVX2,
> >> >>  P_AVX512F,
> >> >> 
> >> >> This changed the priority of P_POPCNT and caused
> >> >> 
> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
> >> >> 
> >> >> on Nehalem and Westmere machines:
> >> >> 
> >> >> mv1.exe:
> >> >> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51:
> >> >> int main(): Assertion `val == 5' failed.
> >> >> 
> >> >> since "val" is 6 now.
> >> > 
> >> > Right. I am not sure why popcnt was prioritized below arch=corei7. The
> >> > logic is supposed to be that any target that includes an extension is
> >> > prioritized
> >> 
> >> I don't understand your question.  popcnt feature is separate from
> >> -march. Its priority has nothing to do with -march=corei7.
> > 
> > arch=corei7 implies popcnt. See PTA_NEHALEM in i386.c. The test would
> > probably work with -march=core2.
> > 
> > AFAIK The logic of the priorities in multiversioning is that architecture
> > specific functions are chosen over feature specific, unless the feature
> > is one that isn't required by the architecture.
> 
> On SSE4.2 machines, we should choose
> 
> int __attribute__ ((target("arch=corei7"))) foo ();
> 
> over
> 
> int __attribute__ ((target("popcnt"))) foo ();
> 
> But we shouldn't choose
> 
> int __attribute__ ((target("arch=corei7"))) foo ();
> 
> over
> 
> int __attribute__ ((target("arch=corei7,popcnt"))) foo ();

I guess since they represent the exact same effective ISA, they would have 
equal priority, so that it would likely chose whatever comes last. 

`Allan

Re: [doc, committed] copy-edit documentation for -fisolate-erroneous-paths-*

[Joseph Myers]

On Mon, 26 Jan 2015, Gerald Pfeifer wrote:

> On Saturday 2015-01-03 17:59, Sandra Loosemore wrote:
> > * most places in the manual use "null" or more rarely "@code{NULL}" 
> > rather than "NULL"
> 
> So, should this be documented in gcc.gnu.org/codingconventions.html?

Expanding / revising where it says "NULL should be written as 
@code{NULL}" (to exclude use of plain un-marked-up NULL)?

(I think natural logic is something like: "null" as an adjective, e.g. 
"null pointer", @code{NULL} (or e.g. @code{NULL_TREE}) if naming a 
specific value, no use of un-marked-up "NULL".  But I'm not sure there's a 
real distinction between e.g. "the value is non-null" and "the value is 
non-@code{NULL}", so that doesn't actually say which to use in such 
cases.)

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

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[H.J. Lu]

On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen
 wrote:
> On Monday 26 January 2015, H.J. Lu wrote:
>> On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
>>
>>  wrote:
>> >> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu
>> >> >> >> part in gcc/config/i386/i386.c, and mv17.C test didn't compile at
>> >> >> >> all due to missing parenthesis).
>> >> >> >
>> >> >> > ... and now with committed ChangeLog and patch.
>> >> >> >
>> >> >> > gcc/ChangeLog:
>> >> >> > * config/i386/i386.c (get_builtin_code_for_version): Add
>> >> >> > support for BMI and BMI2 multiversion functions.
>> >> >> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
>> >> >> >
>> >> >> > libgcc/ChangeLog:
>> >> >> > * config/i386/cpuinfo.c (enum processor_features): Add
>> >> >> > FEATURE_BMI and FEATURE_BMI2.
>> >> >> > (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>> >> >> >
>> >> >> > testsuite/ChangeLog:
>> >> >> > * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>> >> >> > * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>> >> >>
>> >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> >> >> index 9ec40cb..441911d 100644
>> >> >> --- a/gcc/config/i386/i386.c
>> >> >> +++ b/gcc/config/i386/i386.c
>> >> >> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl,
>> >> >> tree *predica te_list)
>> >> >>
>> >> >>  P_PROC_SSE4_A,
>> >> >>  P_SSE4_1,
>> >> >>  P_SSE4_2,
>> >> >>
>> >> >> -P_PROC_SSE4_2,
>> >> >>
>> >> >>  P_POPCNT,
>> >> >>
>> >> >> +P_PROC_SSE4_2,
>> >> >>
>> >> >>  P_AVX,
>> >> >>  P_PROC_AVX,
>> >> >>
>> >> >> +P_BMI,
>> >> >> +P_PROC_BMI,
>> >> >>
>> >> >>  P_FMA4,
>> >> >>  P_XOP,
>> >> >>  P_PROC_XOP,
>> >> >>  P_FMA,
>> >> >>  P_PROC_FMA,
>> >> >>
>> >> >> +P_BMI2,
>> >> >>
>> >> >>  P_AVX2,
>> >> >>  P_PROC_AVX2,
>> >> >>  P_AVX512F,
>> >> >>
>> >> >> This changed the priority of P_POPCNT and caused
>> >> >>
>> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
>> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
>> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
>> >> >>
>> >> >> on Nehalem and Westmere machines:
>> >> >>
>> >> >> mv1.exe:
>> >> >> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51:
>> >> >> int main(): Assertion `val == 5' failed.
>> >> >>
>> >> >> since "val" is 6 now.
>> >> >
>> >> > Right. I am not sure why popcnt was prioritized below arch=corei7. The
>> >> > logic is supposed to be that any target that includes an extension is
>> >> > prioritized
>> >>
>> >> I don't understand your question.  popcnt feature is separate from
>> >> -march. Its priority has nothing to do with -march=corei7.
>> >
>> > arch=corei7 implies popcnt. See PTA_NEHALEM in i386.c. The test would
>> > probably work with -march=core2.
>> >
>> > AFAIK The logic of the priorities in multiversioning is that architecture
>> > specific functions are chosen over feature specific, unless the feature
>> > is one that isn't required by the architecture.
>>
>> On SSE4.2 machines, we should choose
>>
>> int __attribute__ ((target("arch=corei7"))) foo ();
>>
>> over
>>
>> int __attribute__ ((target("popcnt"))) foo ();
>>
>> But we shouldn't choose
>>
>> int __attribute__ ((target("arch=corei7"))) foo ();
>>
>> over
>>
>> int __attribute__ ((target("arch=corei7,popcnt"))) foo ();
>
> I guess since they represent the exact same effective ISA, they would have
> equal priority, so that it would likely chose whatever comes last.

I have no strong opinion on this.  But this is a user visible compiler
behavior change.  We should issue a warning/note here.


-- 
H.J.

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Uros Bizjak]

On Mon, Jan 26, 2015 at 8:15 PM, H.J. Lu  wrote:
> On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen
>  wrote:
>> On Monday 26 January 2015, H.J. Lu wrote:
>>> On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
>>>
>>>  wrote:
>>> >> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu
>>> >> >> >> part in gcc/config/i386/i386.c, and mv17.C test didn't compile at
>>> >> >> >> all due to missing parenthesis).
>>> >> >> >
>>> >> >> > ... and now with committed ChangeLog and patch.
>>> >> >> >
>>> >> >> > gcc/ChangeLog:
>>> >> >> > * config/i386/i386.c (get_builtin_code_for_version): Add
>>> >> >> > support for BMI and BMI2 multiversion functions.
>>> >> >> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
>>> >> >> >
>>> >> >> > libgcc/ChangeLog:
>>> >> >> > * config/i386/cpuinfo.c (enum processor_features): Add
>>> >> >> > FEATURE_BMI and FEATURE_BMI2.
>>> >> >> > (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>>> >> >> >
>>> >> >> > testsuite/ChangeLog:
>>> >> >> > * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>>> >> >> > * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>>> >> >>
>>> >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>>> >> >> index 9ec40cb..441911d 100644
>>> >> >> --- a/gcc/config/i386/i386.c
>>> >> >> +++ b/gcc/config/i386/i386.c
>>> >> >> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl,
>>> >> >> tree *predica te_list)
>>> >> >>
>>> >> >>  P_PROC_SSE4_A,
>>> >> >>  P_SSE4_1,
>>> >> >>  P_SSE4_2,
>>> >> >>
>>> >> >> -P_PROC_SSE4_2,
>>> >> >>
>>> >> >>  P_POPCNT,
>>> >> >>
>>> >> >> +P_PROC_SSE4_2,
>>> >> >>
>>> >> >>  P_AVX,
>>> >> >>  P_PROC_AVX,
>>> >> >>
>>> >> >> +P_BMI,
>>> >> >> +P_PROC_BMI,
>>> >> >>
>>> >> >>  P_FMA4,
>>> >> >>  P_XOP,
>>> >> >>  P_PROC_XOP,
>>> >> >>  P_FMA,
>>> >> >>  P_PROC_FMA,
>>> >> >>
>>> >> >> +P_BMI2,
>>> >> >>
>>> >> >>  P_AVX2,
>>> >> >>  P_PROC_AVX2,
>>> >> >>  P_AVX512F,
>>> >> >>
>>> >> >> This changed the priority of P_POPCNT and caused
>>> >> >>
>>> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
>>> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
>>> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
>>> >> >>
>>> >> >> on Nehalem and Westmere machines:
>>> >> >>
>>> >> >> mv1.exe:
>>> >> >> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:51:
>>> >> >> int main(): Assertion `val == 5' failed.
>>> >> >>
>>> >> >> since "val" is 6 now.
>>> >> >
>>> >> > Right. I am not sure why popcnt was prioritized below arch=corei7. The
>>> >> > logic is supposed to be that any target that includes an extension is
>>> >> > prioritized
>>> >>
>>> >> I don't understand your question.  popcnt feature is separate from
>>> >> -march. Its priority has nothing to do with -march=corei7.
>>> >
>>> > arch=corei7 implies popcnt. See PTA_NEHALEM in i386.c. The test would
>>> > probably work with -march=core2.
>>> >
>>> > AFAIK The logic of the priorities in multiversioning is that architecture
>>> > specific functions are chosen over feature specific, unless the feature
>>> > is one that isn't required by the architecture.
>>>
>>> On SSE4.2 machines, we should choose
>>>
>>> int __attribute__ ((target("arch=corei7"))) foo ();
>>>
>>> over
>>>
>>> int __attribute__ ((target("popcnt"))) foo ();
>>>
>>> But we shouldn't choose
>>>
>>> int __attribute__ ((target("arch=corei7"))) foo ();
>>>
>>> over
>>>
>>> int __attribute__ ((target("arch=corei7,popcnt"))) foo ();
>>
>> I guess since they represent the exact same effective ISA, they would have
>> equal priority, so that it would likely chose whatever comes last.
>
> I have no strong opinion on this.  But this is a user visible compiler
> behavior change.  We should issue a warning/note here.

IMO, this is such a small (but useful) change, that we can get away
without warning.

Uros.

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Allan Sandfeld Jensen]

On Monday 26 January 2015, H.J. Lu wrote:
> On Mon, Jan 26, 2015 at 11:08 AM, Allan Sandfeld Jensen
> 
>  wrote:
> > On Monday 26 January 2015, H.J. Lu wrote:
> >> On Mon, Jan 26, 2015 at 10:53 AM, Allan Sandfeld Jensen
> >> 
> >>  wrote:
> >> >> >> >> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu
> >> >> >> >> part in gcc/config/i386/i386.c, and mv17.C test didn't compile
> >> >> >> >> at all due to missing parenthesis).
> >> >> >> > 
> >> >> >> > ... and now with committed ChangeLog and patch.
> >> >> >> > 
> >> >> >> > gcc/ChangeLog:
> >> >> >> > * config/i386/i386.c (get_builtin_code_for_version): Add
> >> >> >> > support for BMI and BMI2 multiversion functions.
> >> >> >> > (fold_builtin_cpu): Add F_BMI and F_BMI2.
> >> >> >> > 
> >> >> >> > libgcc/ChangeLog:
> >> >> >> > * config/i386/cpuinfo.c (enum processor_features): Add
> >> >> >> > FEATURE_BMI and FEATURE_BMI2.
> >> >> >> > (get_available_features): Detect FEATURE_BMI and
> >> >> >> > FEATURE_BMI2.
> >> >> >> > 
> >> >> >> > testsuite/ChangeLog:
> >> >> >> > * gcc.target/i386/funcspec-5.c: Test new multiversion
> >> >> >> > targets. * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion
> >> >> >> > dispatcher.
> >> >> >> 
> >> >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> >> >> >> index 9ec40cb..441911d 100644
> >> >> >> --- a/gcc/config/i386/i386.c
> >> >> >> +++ b/gcc/config/i386/i386.c
> >> >> >> @@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl,
> >> >> >> tree *predica te_list)
> >> >> >> 
> >> >> >>  P_PROC_SSE4_A,
> >> >> >>  P_SSE4_1,
> >> >> >>  P_SSE4_2,
> >> >> >> 
> >> >> >> -P_PROC_SSE4_2,
> >> >> >> 
> >> >> >>  P_POPCNT,
> >> >> >> 
> >> >> >> +P_PROC_SSE4_2,
> >> >> >> 
> >> >> >>  P_AVX,
> >> >> >>  P_PROC_AVX,
> >> >> >> 
> >> >> >> +P_BMI,
> >> >> >> +P_PROC_BMI,
> >> >> >> 
> >> >> >>  P_FMA4,
> >> >> >>  P_XOP,
> >> >> >>  P_PROC_XOP,
> >> >> >>  P_FMA,
> >> >> >>  P_PROC_FMA,
> >> >> >> 
> >> >> >> +P_BMI2,
> >> >> >> 
> >> >> >>  P_AVX2,
> >> >> >>  P_PROC_AVX2,
> >> >> >>  P_AVX512F,
> >> >> >> 
> >> >> >> This changed the priority of P_POPCNT and caused
> >> >> >> 
> >> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++98 execution test
> >> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++11 execution test
> >> >> >> FAIL: g++.dg/ext/mv1.C  -std=gnu++14 execution test
> >> >> >> 
> >> >> >> on Nehalem and Westmere machines:
> >> >> >> 
> >> >> >> mv1.exe:
> >> >> >> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/ext/mv1.C:
> >> >> >> 51: int main(): Assertion `val == 5' failed.
> >> >> >> 
> >> >> >> since "val" is 6 now.
> >> >> > 
> >> >> > Right. I am not sure why popcnt was prioritized below arch=corei7.
> >> >> > The logic is supposed to be that any target that includes an
> >> >> > extension is prioritized
> >> >> 
> >> >> I don't understand your question.  popcnt feature is separate from
> >> >> -march. Its priority has nothing to do with -march=corei7.
> >> > 
> >> > arch=corei7 implies popcnt. See PTA_NEHALEM in i386.c. The test would
> >> > probably work with -march=core2.
> >> > 
> >> > AFAIK The logic of the priorities in multiversioning is that
> >> > architecture specific functions are chosen over feature specific,
> >> > unless the feature is one that isn't required by the architecture.
> >> 
> >> On SSE4.2 machines, we should choose
> >> 
> >> int __attribute__ ((target("arch=corei7"))) foo ();
> >> 
> >> over
> >> 
> >> int __attribute__ ((target("popcnt"))) foo ();
> >> 
> >> But we shouldn't choose
> >> 
> >> int __attribute__ ((target("arch=corei7"))) foo ();
> >> 
> >> over
> >> 
> >> int __attribute__ ((target("arch=corei7,popcnt"))) foo ();
> > 
> > I guess since they represent the exact same effective ISA, they would
> > have equal priority, so that it would likely chose whatever comes last.
> 
> I have no strong opinion on this.  But this is a user visible compiler
> behavior change.  We should issue a warning/note here.

Yes, or revert that part of the patch. It should have been a separate patch 
anyway.

`Allan

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Uros Bizjak]

On Mon, Jan 26, 2015 at 8:22 PM, Allan Sandfeld Jensen
 wrote:

>> > I guess since they represent the exact same effective ISA, they would
>> > have equal priority, so that it would likely chose whatever comes last.
>>
>> I have no strong opinion on this.  But this is a user visible compiler
>> behavior change.  We should issue a warning/note here.
>
> Yes, or revert that part of the patch. It should have been a separate patch
> anyway.

Agreed.

HJ, can you please revert this part? The patch from PR is OK.

Thanks,
Uros.

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[H.J. Lu]

---On Mon, Jan 26, 2015 at 11:25 AM, Uros Bizjak  wrote:
> On Mon, Jan 26, 2015 at 8:22 PM, Allan Sandfeld Jensen
>  wrote:
>
>>> > I guess since they represent the exact same effective ISA, they would
>>> > have equal priority, so that it would likely chose whatever comes last.
>>>
>>> I have no strong opinion on this.  But this is a user visible compiler
>>> behavior change.  We should issue a warning/note here.
>>
>> Yes, or revert that part of the patch. It should have been a separate patch
>> anyway.
>
> Agreed.
>
> HJ, can you please revert this part? The patch from PR is OK.
>

I checked in this patch.  I agree we should improve get_builtin_code_for_version
to better handle overlapping ISAs.   Let's open a bug report to track it.

Thanks.

-- 
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 220130)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2015-01-26  H.J. Lu  
+
+ PR target/64806
+ * config/i386/i386 (feature_priority): Revert the last P_POPCNT
+ order change.
+
 2015-01-26  Uros Bizjak  

 PR target/64795
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 220130)
+++ config/i386/i386.c (working copy)
@@ -34289,8 +34289,8 @@ get_builtin_code_for_version (tree decl,
 P_PROC_SSE4_A,
 P_SSE4_1,
 P_SSE4_2,
-P_POPCNT,
 P_PROC_SSE4_2,
+P_POPCNT,
 P_AVX,
 P_PROC_AVX,
 P_BMI,

Re: #pragma GCC unroll support

[Mike Stump]

Jason, Joseph, this is stage 1 material (unless someone else wants to try and 
make an argument for it sooner), if you could review the parser (frontend) 
bits, that would be wonderful.  The mid-end, and back-end bits Richard was 
reviewing.

On Jan 8, 2015, at 4:45 AM, Richard Biener  wrote:
> But I'd make the 2nd operand optional (thus use NULL_TREE,
> not integer_zero_node for existing builds).

Fixed.

> You also need to check that 'unroll' fits in the target integer_type_node
> (consider AVR!) and otherwise diagnose it.

Yeah, I’ve tightened this down.

> The 'unroll' member in struct loop should be unsigned

Fixed.

> (or you need to document what negative values are supposed to mean).

Fixed.

> It also should be smaller than int (struct loop may be heavily used), possibly
> short or even (un)signed char(?).

We talked around here, and we felt unsigned short would be a good choice.  
Seems to be more in the GNU spirit as well.  Cray’s documentation has a limit 
of 64.

> @@ -341,7 +341,10 @@ tree_estimate_loop_size (struct loop *lo
>  if (likely_eliminated || likely_eliminated_last)
>size->last_iteration_eliminated_by_peeling += num;
>}
> - if ((size->overall * 3 / 2 - size->eliminated_by_peeling
> + /* A loop that we want to unroll is never too large.  */
> + if (loop->unroll > 0)
> +   ;
> 
> but if we end up unrolling more than loop->unroll then it may be too large?
> That is this check should be in the caller, not here.

Fixed.

> I think you miss updating copy_loop_info (and places where we don't
> use that but still copy loops somehow).

I’ve fixed up copy_loop_info.  I searched for other routines based upon that 
other members, and found two, first one is:

/* Allocates and returns new loop structure.  */

struct loop *
alloc_loop (void)

and I thought about adding code to initialize it:

  loop->unroll = 0;

but after tracing to ensure that ggc_cleared_alloc meant what I thought it 
mean, that would be redundant, so I did not.

I missed print_loop, which I added:

+  if (loop->unroll)
+fprintf (file, ", unroll = %d", loop->unroll);

I didn’t find any other hits.

>> I didn’t engineer ivdeps and unroll together.  Does it sound reasonable to 
>> allow both to be used at the same time on the same loop?  If so, I can add 
>> the two other cases, presently I just handle one of them then the loop.
> 
> Yes.

Fixed.

>> Does unroll 8 mean that the loop is repeated 8 times?
> 
> Up to you to define - what do other compilers do for #pragma unroll 0
> and #pragma unroll 1?

I googled for cray pragma unroll and found it.  They have a pragma unroll and 
it takes a numeric argument.  They have 0 and 1 mean don’t unroll.  That 
mirrors roughly with what I was thinking those two numbers meant, so I pushed 
the code in that direction and got rid of the -1.  I don’t see any compelling 
reason to deviate from what they did, and this should make the compiler more 
predictable by people in this space.  I’m happier now having read the Cray 
documentation about the mapping.

>> Can I turn on peeling in try_peel_loop by simply wanted to do it for 1 loop?
> 
> ?

So, after fixing up all the other code to unroll, it seems sufficient to rely 
upon it and not have the peeler do anything.  This allows me to not use the 
peeler, so this question is now moot.

> #pragma unroll 0
> 
> or
> 
> #pragma nounroll
> 
> what do other compilers do?

Good question.  I googled for a hypothetical pragma unroll and found it.  :-)  
They support 0 and 1 as don’t unroll the loop.  I’ve adjusted the patch to do 
the same.

>> Yes, I’m aware that this isn’t the right phase for this, but such are 
>> business cycles.  It would not go in until we reenter stage 1.  I see no 
>> value in trying to squeeze it in past stage 1.

> the middle-end bits look fine apart from the above issues (it feels like you 
> need to add too many
> checks for loop->unroll in the peeler…)

I did a cleanup pass to collapse down what tests I could from the entire patch 
set.  I also was able to engineer out the peeler from doing the unrolling.  
Should be nicer now.

Tested on x86_64-unknown-linux-gnu.

Back-end/mid-end bits Ok?

C front-end bits Ok?

C++ front-end bits Ok?

Index: gcc/ada/gcc-interface/trans.c
===
--- gcc/ada/gcc-interface/trans.c   (revision 220084)
+++ gcc/ada/gcc-interface/trans.c   (working copy)
@@ -7870,17 +7870,20 @@ gnat_gimplify_stmt (tree *stmt_p)
  {
/* Deal with the optimization hints.  */
if (LOOP_STMT_IVDEP (stmt))
- gnu_cond = build2 (ANNOTATE_EXPR, TREE_TYPE (gnu_cond), gnu_cond,
+ gnu_cond = build3 (ANNOTATE_EXPR, TREE_TYPE (gnu_cond), gnu_cond,
 build_int_cst (integer_type_node,
-   annot_expr_ivdep_kind));
+ 

Re: #pragma GCC unroll support

[Mike Stump]

I missed including the documentation patch in the last set.  :-(  Here it is:

Index: extend.texi
===
--- extend.texi (revision 220084)
+++ extend.texi (working copy)
@@ -17881,6 +17881,17 @@ void ignore_vec_dep (int *a, int k, int
 @}
 @end smallexample
 
+@table @code
+@item #pragma GCC unroll @var{"n"}
+@cindex pragma GCC unroll @var{"n"}
+
+With this pragma, the programmer informs the optimizer how many times
+a loop should be unrolled.  A 0 or 1 informs the compiler to not
+perform any loop unrolling.  The pragma must be immediately before
+@samp{#pragma ivdep} or a @code{for}, @code{while} or @code{do} loop
+and applies only to the loop that follows.
+
+@end table
 
 @node Unnamed Fields
 @section Unnamed struct/union fields within structs/unions

Re: RFA: patch to fix a bad code generation for PR64110 -- new constraints addition

[Jeff Law]

On 01/24/15 04:29, Richard Sandiford wrote:


Yeah.  I expect in practice most people who used "?" and "!" attached
them to a particular operand for a reason.  From a quick scan through
386.exp it looked like almost all uses would either want this behaviour
or wouldn't care.  An interesting exception is:

(define_insn "extendsidi2_1"
   [(set (match_operand:DI 0 "nonimmediate_operand" "=*A,r,?r,?*o")
(sign_extend:DI (match_operand:SI 1 "register_operand" "0,0,r,r")))
(clobber (reg:CC FLAGS_REG))
(clobber (match_scratch:SI 2 "=X,X,X,&r"))]
   "!TARGET_64BIT"
   "#")

I don't know how effective the third alternative is with LRA.  Surely
a "r<-0" alternative is by definition a case where "r<-r" is possible
only with a "?"-cost reload?  Seems to me we could just delete it.
But assuming it does some good, I suppose the "?" really does apply to
the alternative as a whole.  If we had to reload operand 1 or operand 0,
there's an extra cost if it can't use the same register as the other
operand.

Wouldn't it be better to make "?" and "!" behave the new way and only
add new constraints if it turns out that the old behaviour really is
useful in some cases?

Maybe stage 4 isn't the time to be making that kind of change.
Still, it'd be great if someone who's set up do x86_64 benchmarking
could measure the effect of making "?" and "!" behave like the
new constraints.
My worry isn't the x86_64 port, but all the others that folks don't test 
as regularly.


I'd rather go the other direction, have folks familiar with the port go 
through it changing the constraints where it makes sense.  That just 
seems a hell of a lot safer.


A port maintainer could certainly hack something together for testing 
purposes to guide them as to whether or not there's something to be 
gained by converting many/most of the ?! to the new constraints.


jeff

[PATCH, committed] PR jit/64708: remove libgccjit.so from COMPILERS

[David Malcolm]

libgccjit.so is installed by jit/Make-lang.in's jit.install-common,
into $(DESTDIR)/$(libdir).

jit/config-lang.in listed "compilers" as "libgccjit.so", leading
to the makefile variable COMPILERS containing libgccjit.so.  This in
turn led to gcc/Makefile's install-common installing a redundant
copy of the library into $(DESTDIR)$(libexecsubdir).

Drop the entry from jit/config-lang.in, eliminating the duplicate copy
of the library.

Tested with a clean rebuild; "make check-jit" and "make install"
continue to work.

Committed to trunk as r220133.

gcc/jit/ChangeLog:
PR jit/64708
* config-lang.in (compilers): Drop "libgccjit.so".
---
 gcc/jit/config-lang.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/jit/config-lang.in b/gcc/jit/config-lang.in
index e4eb060..875a194 100644
--- a/gcc/jit/config-lang.in
+++ b/gcc/jit/config-lang.in
@@ -25,7 +25,7 @@
 
 language="jit"
 
-compilers="libgccjit.so"
+compilers=""
 
 target_libs=""
 
-- 
1.8.5.3

Re: [4.8] backport PR57748 fixes (wrong-code and ICE regression)

[Mikael Pettersson]

Richard Biener writes:
 > On Sun, Jan 25, 2015 at 3:25 PM, Mikael Pettersson  
 > wrote:
 > > This backports the fixes for PR middle-end/57748, a wrong-code and ICE
 > > regression, to the 4.8 branch.
 > >
 > > Tested extensively on x86_64, powerpc64, sparc64, ARMv{5,7}, and m68k.
 > >
 > > Ok for 4.8?
 > 
 > Ok - I assume you have checked that all relevant patches in this area have
 > been backported already?

I'm not aware of any dependencies for this PR to patches other than the two
being backported here (r202778 and r206437).  I've now re-tested 4.8 vanilla on
x86_64 and ARM, and this combined patch is enough to fix this PR's test cases.

Thanks,

/Mikael

 > Thanks,
 > Richard.
 > 
 > > (I don't have commit rights.)
 > >
 > > /Mikael
 > >
 > > gcc/
 > >
 > > 2015-01-25  Mikael Pettersson  
 > >
 > > Backport from mainline
 > >
 > > 2013-09-20  Bernd Edlinger  
 > >
 > > PR middle-end/57748
 > > * expr.c (expand_assignment): Remove misalignp code path.
 > >
 > > 2014-01-08  Bernd Edlinger  
 > >
 > > PR middle-end/57748
 > > * expr.h (expand_expr_real, expand_expr_real_1): Add new parameter
 > > inner_reference_p.
 > > (expand_expr, expand_normal): Adjust.
 > > * expr.c (expand_expr_real, expand_expr_real_1): Add new parameter
 > > inner_reference_p. Use inner_reference_p to expand inner 
 > > references.
 > > (store_expr): Adjust.
 > > * cfgexpand.c (expand_call_stmt): Adjust.
 > >
 > > gcc/testsuite/
 > >
 > > 2015-01-25  Mikael Pettersson  
 > >
 > > Backport from mainline
 > >
 > > 2013-09-20  Bernd Edlinger  
 > >
 > > PR middle-end/57748
 > > * gcc.dg/torture/pr57748-1.c: New test.
 > > * gcc.dg/torture/pr57748-2.c: New test.
 > >
 > > 2014-01-08  Bernd Edlinger  
 > >
 > > PR middle-end/57748
 > > * gcc.dg/torture/pr57748-3.c: New test.
 > > * gcc.dg/torture/pr57748-4.c: New test.
 > >
 > > diff -rupN gcc-4.8-20150122/gcc/cfgexpand.c 
 > > gcc-4.8-20150122.pr57748/gcc/cfgexpand.c
 > > --- gcc-4.8-20150122/gcc/cfgexpand.c2014-01-07 17:49:22.0 +0100
 > > +++ gcc-4.8-20150122.pr57748/gcc/cfgexpand.c2015-01-25 
 > > 15:00:35.240949368 +0100
 > > @@ -2111,7 +2111,7 @@ expand_call_stmt (gimple stmt)
 > >if (lhs)
 > >  expand_assignment (lhs, exp, false);
 > >else
 > > -expand_expr_real_1 (exp, const0_rtx, VOIDmode, EXPAND_NORMAL, NULL);
 > > +expand_expr (exp, const0_rtx, VOIDmode, EXPAND_NORMAL);
 > >
 > >mark_transaction_restart_calls (stmt);
 > >  }
 > > diff -rupN gcc-4.8-20150122/gcc/expr.c gcc-4.8-20150122.pr57748/gcc/expr.c
 > > --- gcc-4.8-20150122/gcc/expr.c 2014-11-28 18:06:23.0 +0100
 > > +++ gcc-4.8-20150122.pr57748/gcc/expr.c 2015-01-25 15:00:35.240949368 +0100
 > > @@ -4708,8 +4708,6 @@ expand_assignment (tree to, tree from, b
 > >int unsignedp;
 > >int volatilep = 0;
 > >tree tem;
 > > -  bool misalignp;
 > > -  rtx mem = NULL_RTX;
 > >
 > >push_temp_slots ();
 > >tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
 > > @@ -4728,40 +4726,7 @@ expand_assignment (tree to, tree from, b
 > >   && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
 > > get_bit_range (&bitregion_start, &bitregion_end, to, &bitpos, 
 > > &offset);
 > >
 > > -  /* If we are going to use store_bit_field and extract_bit_field,
 > > -make sure to_rtx will be safe for multiple use.  */
 > > -  mode = TYPE_MODE (TREE_TYPE (tem));
 > > -  if (TREE_CODE (tem) == MEM_REF
 > > - && mode != BLKmode
 > > - && ((align = get_object_alignment (tem))
 > > - < GET_MODE_ALIGNMENT (mode))
 > > - && ((icode = optab_handler (movmisalign_optab, mode))
 > > - != CODE_FOR_nothing))
 > > -   {
 > > - struct expand_operand ops[2];
 > > -
 > > - misalignp = true;
 > > - to_rtx = gen_reg_rtx (mode);
 > > - mem = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
 > > -
 > > - /* If the misaligned store doesn't overwrite all bits, perform
 > > -rmw cycle on MEM.  */
 > > - if (bitsize != GET_MODE_BITSIZE (mode))
 > > -   {
 > > - create_input_operand (&ops[0], to_rtx, mode);
 > > - create_fixed_operand (&ops[1], mem);
 > > - /* The movmisalign pattern cannot fail, else the 
 > > assignment
 > > -would silently be omitted.  */
 > > - expand_insn (icode, 2, ops);
 > > -
 > > - mem = copy_rtx (mem);
 > > -   }
 > > -   }
 > > -  else
 > > -   {
 > > - misalignp = false;
 > > - to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
 > > -   }
 > > +  to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
 > >
 > >/* If the bitfield is volatile, we want to access it in the
 

[Patch, Fortran, committed] Minor follow up patch for the recent io.c change

[Tobias Burnus]

This patch replaces the hard-wired -1 of patch 
https://gcc.gnu.org/ml/fortran/2015-01/msg00046.html by the later-added 
#define.


Committed as obvious as Rev. 220135.

Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 220134)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2015-01-26  Tobias Burnus  
+
+	* io.c (gfc_match_inquire): Replace "-1" by a defined constant.
+
 2015-01-26  Janus Weil  
 
 	PR fortran/64230
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c	(Revision 220134)
+++ gcc/fortran/io.c	(Arbeitskopie)
@@ -4000,7 +4000,7 @@ gfc_match_inquire (void)
 
   if (inquire->unit != NULL && inquire->unit->expr_type == EXPR_CONSTANT
   && inquire->unit->ts.type == BT_INTEGER
-  && mpz_get_si (inquire->unit->value.integer) == -1)
+  && mpz_get_si (inquire->unit->value.integer) == GFC_INTERNAL_UNIT)
 {
   gfc_error ("UNIT number in INQUIRE statement at %L can not be -1", &loc);
   goto cleanup;

[C PATCH] Fix ICE with invalid function call (PR c/64778)

[Jakub Jelinek]

Hi!

On the following testcase we ICE, because we end up with a CALL_EXPR
with error_mark_node argument and gimplification can't cope with that.

Normally, if one or more arguments are error_mark_node we return -1
and drop the whole call, but if we also report too many arguments,
we failed to do so.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2015-01-26  Jakub Jelinek  

PR c/64778
* c-typeck.c (convert_arguments): Return -1 if there are
error_args, even if we've diagnosed too many arguments.

* gcc.dg/pr64778.c: New test.

--- gcc/c/c-typeck.c.jj 2015-01-15 23:39:03.0 +0100
+++ gcc/c/c-typeck.c2015-01-26 12:09:57.151820878 +0100
@@ -3143,7 +3143,7 @@ convert_arguments (location_t loc, vec 2)
--- gcc/testsuite/gcc.dg/pr64778.c.jj   2015-01-26 12:18:12.216366230 +0100
+++ gcc/testsuite/gcc.dg/pr64778.c  2015-01-26 12:17:58.0 +0100
@@ -0,0 +1,10 @@
+/* PR c/64778 */
+/* { dg-do compile } */
+
+int
+foo (int p)
+{
+  int a;
+  a ^= foo (,);/* { dg-error "expected expression before|too many 
arguments" } */
+  return a;
+}

Jakub