Re: [PATCH 0/3] use rtx_insn * more

[Trevor Saunders]

On Mon, Oct 31, 2016 at 07:37:54AM -0600, Jeff Law wrote:
> On 10/28/2016 01:13 PM, tbsaunde+...@tbsaunde.org wrote:
> > From: Trevor Saunders 
> > 
> > HI,
> > 
> > This series changes various variables type from rtx to rtx_insn * so that 
> > the
> > remaining patches in this series
> > http://gcc.gnu.org/ml/gcc-patches/2016-10/msg01353.html can be applied.
> > 
> > patches bootstrapped and regtested on x86_64-linux-gnu, and run through 
> > config-list.mk, ok?
> > 
> > Thanks!
> > 
> > Trev
> > 
> > Trevor Saunders (3):
> >   use rtx_insn * in various places where it is obvious
> >   split up the trial variable in reorg.c:relax_delay_slots to use
> > rtx_insn * more
> >   split up some variables to use rtx_insn * more
> All 3 patches in this series are fine.

Thanks for the reviews.

Can I trouble you to look at http://gcc.gnu.org/ml/gcc-patches/2016-10/
now that it is tested on aarch64?

Trev

> 
> Thanks,
> Jeff
> 

Re: [Aarch64] Variant field

[Andrew Pinski]

On Fri, Oct 28, 2016 at 10:56 AM, Andrew Pinski  wrote:
> On Fri, Oct 28, 2016 at 10:50 AM, Benedikt Huber
>  wrote:
>> Hi,
>>
>> In the aarch64 backend we would need VARIANT field in AARCH64_CORE to 
>> specify and detect
>> variants of xgene.
>>
>> I found this patch of Andrew Pinski
>> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02148.html
>>
>> However it did not find its way to trunk.
>> Why was that the case?
>
> Because the full patch set has not been reviewed   Parts of it was
> reviewed back and parts in the last few weeks :).
>
>> What is the correct way to proceed when (re)using this patch for submission?
>> Is that possible at all?
>
> I was in the process of resubmitting that patch set.  In fact I was
> able to commit patches 1, 2 and 4 already.  patch 3 was resubmitted 5
> days ago:
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01855.html
>
> I hope someone will approve it and then I will resubmit the last patch
> which adds the variant portion.
>
> The patch set does not apply directly any more as one variable name has 
> changed.


I committed that one and submitted the final patch which you pointed
out was not committed yet:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00072.html

Thanks,
Andrew

>
> Thanks,
> Andrew
>
>
>>
>> Thank you and best regards,
>> Benedikt
>>

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

[Martin Sebor]

On 11/01/2016 01:14 PM, Jakub Jelinek wrote:

On Tue, Nov 01, 2016 at 01:12:55PM -0600, Jeff Law wrote:

On 11/01/2016 08:10 AM, Jakub Jelinek wrote:

On Mon, Oct 31, 2016 at 08:39:15PM -0600, Martin Sebor wrote:

Attached is an updated patch that works around the problem with
the definition of the NOTE_DATA macro discussed below.  I've
raised bug 78174 for it and temporarily worked around it in
the patch.  I'll see if I can come up with a patch to fix the
macro the "right way" but would prefer to do that separately.
The NOTE_DATA macro is implemented in terms of the RTL_CHECK1
macro that will need to change and that macro is used in many
others, so I would rather not mess around with those as part
of this patch.


No, you just shouldn't use __bos (*, 1) in the warning code
for mem* like builtins.

Can you explain to Martin why so that he can adjust accordingly?


I've tried to explain that in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174#c7


I'm not sure I understand the concern you raised there.  I would
find specific examples helpful.  My concern is that with bos 0
GCC doesn't point out or protect against far too many cases of
even obvious buffer overflows.  See the example below.

I'm also not convinced by the argument that this sort of code is
so common and safe and that warning about it would cause too many
false positives.  The patch found just one instance of such code
in GCC and it's a real bug.  It points out 8 issues in the Linux
kernel at least some of which look suspicious to me.  It found
nothing in Binutils.  (There, however, GCC complains about dozens
of fallthrough cases, making me wonder why the same concern about
false positives doesn't apply to that warning.)

In any event, I've enhanced the patch to both accept an argument
to -Wstringop-overflow=N, and add another option for raw memory
functions like memcpy, -Wrawmem-overflow=N, and to treat (N - 1)
as the object size type.  While the defaults for the patch are
what I understand you would be comfortable with I would prefer
to go with bos 1 for both instead.  I understand and agree that
the checking functions enabled by _FORTIFY_SOURCE need to be
conservative to avoid aborting on benign code.  But this patch
only issues warnings and does not cause aborts.  In my view,
it's not only acceptable but appropriate for the warnings to
be more strict.  That said, if you can suggest a code base that
you're worried about might be adversely affected by the warnings
I'm happy to verify whether it is or not and tweak the patch to
minimize its impact.

Martin

For instance, in the test case below only the second memset is
diagnosed (with bos type 1), but not the first (bos 0).  That
seems like such a gaping hole that it must make _FORTIFY_SOURCE
for the raw memory functions like memcpy and memset virtually
useless for structs accessed by pointers.

$ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic  b.c
struct S {
  int a, b, c, d;
};

#define bos(p, t) __builtin_object_size (p, t)
#define memset0(p, i, n) __builtin___memset_chk (p, i, n, bos (p, 0))
#define memset1(p, i, n) __builtin___memset_chk (p, i, n, bos (p, 1))

void f0 (struct S *s)
{
  memset0 (>d, 0, 1024);   // no warning here (bos 0)
}

void f1 (struct S *s)
{
  memset1 (>d, 0, 1024);
}


b.c: In function ‘f1’:
b.c:7:26: warning: call to __builtin___memset_chk will always overflow 
destination buffer

 #define memset1(p, i, n) __builtin___memset_chk (p, i, n, bos (p, 1))
  ^~~~
b.c:16:3: note: in expansion of macro ‘memset1’
   memset1 (>d, 0, 1024);
   ^~~

Even with bos 1 the following isn't diagnosed.  IMO, this code is
suspicious to say the least and deserves a warning.  It may not
actually be a bug so it may not call for an abort but GCC could
warn on it without emitting a checking call.

struct A {
  int a, b;
};

struct B {
  int a, b, c, d;
};

void f (struct A *a, struct B *b)
{
  __builtin___memcpy_chk (a, b, sizeof *b, __builtin_object_size (a, 1));
}

PR c/53562 - Add -Werror= support for -D_FORTIFY_SOURCE / __builtin___memcpy_chk
PR middle-end/78149 - missing warning on strncpy buffer overflow due to an excessive bound
PR middle-end/78138 - missing warnings on buffer overflow with non-constant source length

gcc/c-family/ChangeLog:
2016-10-30  Martin Sebor  

	PR c/53562
	* c.opt (-Wstringop-overflow): New option.

gcc/ChangeLog:
2016-10-30  Martin Sebor  

	PR c/53562
	PR middle-end/78149
	PR middle-end/78138
	* builtins.c (expand_builtin_strcat, expand_builtin_strncat): New
	functions.
	(get_size_range, check_sizes, check_strncat_sizes): Same.
	(expand_builtin_memcpy): Call check sizes.
	(expand_builtin_mempcpy): Same.
	(expand_builtin_strcpy): Same.
	(expand_builtin_strncpy): Same.
	(expand_builtin_memset): Same,
	(expand_builtin_bzero): Same.
	(expand_builtin_memory_chk): Same.
	(maybe_emit_sprintf_chk_warning): Same.
	(expand_builtin): Handle strcat and 

[PATCH] Update my email address in MAINTAINERS

[Josh Conner]

Glad to be back.

- Josh


2016-11-01  Josh Conner  


* MAINTAINERS (Write After Approval): Update email address.


MAINTAINERS.patch
Description: Binary data

[PATCH, rs6000] Fold vector addition built-ins in GIMPLE

[Bill Schmidt]

Hi,

As Jakub suggested in response to my *ahem* ornate patch for overloaded
function built-ins, a much better approach is to use the existing
machinery for overloading and then immediately fold the specific
functions during gimplification.  There is a target hook available for
this purpose that we have not previously used.  This patch demonstrates
this functionality by implementing the target hook and folding vector
addition built-ins within it.  Future patches will fold other such
operations, improving the optimization available for many vector
intrinsics.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Is this ok for trunk?

Thanks,
Bill


[gcc]

2016-11-01  Bill Schmidt  

* config/rs6000/rs6000.c (gimple-ssa.h): New #include.
(TARGET_GIMPLE_FOLD_BUILTIN): Define as
rs6000_gimple_fold_builtin.
(rs6000_gimple_fold_builtin): New function.  Add handling for
early expansion of vector addition builtins.


[gcc/testsuite]

2016-11-01  Bill Schmidt  

* gcc.target/powerpc/fold-vec-add-1.c: New.
* gcc.target/powerpc/fold-vec-add-2.c: New.
* gcc.target/powerpc/fold-vec-add-3.c: New.
* gcc.target/powerpc/fold-vec-add-4.c: New.
* gcc.target/powerpc/fold-vec-add-5.c: New.
* gcc.target/powerpc/fold-vec-add-6.c: New.
* gcc.target/powerpc/fold-vec-add-7.c: New.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 241624)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -56,6 +56,7 @@
 #include "sched-int.h"
 #include "gimplify.h"
 #include "gimple-iterator.h"
+#include "gimple-ssa.h"
 #include "gimple-walk.h"
 #include "intl.h"
 #include "params.h"
@@ -1632,6 +1633,8 @@ static const struct attribute_spec rs6000_attribut
 
 #undef TARGET_FOLD_BUILTIN
 #define TARGET_FOLD_BUILTIN rs6000_fold_builtin
+#undef TARGET_GIMPLE_FOLD_BUILTIN
+#define TARGET_GIMPLE_FOLD_BUILTIN rs6000_gimple_fold_builtin
 
 #undef TARGET_EXPAND_BUILTIN
 #define TARGET_EXPAND_BUILTIN rs6000_expand_builtin
@@ -16337,6 +16340,46 @@ rs6000_fold_builtin (tree fndecl, int n_args ATTRI
 #endif
 }
 
+/* Fold a machine-dependent built-in in GIMPLE.  (For folding into
+   a constant, use rs6000_fold_builtin.)  */
+
+bool
+rs6000_gimple_fold_builtin (gimple_stmt_iterator *gsi)
+{
+  gimple *stmt = gsi_stmt (*gsi);
+  tree fndecl = gimple_call_fndecl (stmt);
+  gcc_checking_assert (fndecl && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD);
+  enum rs6000_builtins fn_code
+= (enum rs6000_builtins) DECL_FUNCTION_CODE (fndecl);
+  tree arg0, arg1, lhs;
+
+  switch (fn_code)
+{
+/* Flavors of vec_add.  We deliberately don't expand
+   P8V_BUILTIN_VADDUQM as it gets lowered from V1TImode to
+   TImode, resulting in much poorer code generation.  */
+case ALTIVEC_BUILTIN_VADDUBM:
+case ALTIVEC_BUILTIN_VADDUHM:
+case ALTIVEC_BUILTIN_VADDUWM:
+case P8V_BUILTIN_VADDUDM:
+case ALTIVEC_BUILTIN_VADDFP:
+case VSX_BUILTIN_XVADDDP:
+  {
+   arg0 = gimple_call_arg (stmt, 0);
+   arg1 = gimple_call_arg (stmt, 1);
+   lhs = gimple_call_lhs (stmt);
+   gimple *g = gimple_build_assign (lhs, PLUS_EXPR, arg0, arg1);
+   gimple_set_location (g, gimple_location (stmt));
+   gsi_replace (gsi, g, true);
+   return true;
+  }
+default:
+  break;
+}
+
+  return false;
+}
+
 /* Expand an expression EXP that calls a built-in function,
with result going to TARGET if that's convenient
(and in mode MODE if that's convenient).
Index: gcc/testsuite/gcc.target/powerpc/fold-vec-add-1.c
===
--- gcc/testsuite/gcc.target/powerpc/fold-vec-add-1.c   (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/fold-vec-add-1.c   (working copy)
@@ -0,0 +1,46 @@
+/* Verify that overloaded built-ins for vec_add with char
+   inputs produce the right results.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-additional-options "-std=gnu11" } */
+
+#include 
+
+vector signed char
+test1 (vector bool char x, vector signed char y)
+{
+  return vec_add (x, y);
+}
+
+vector signed char
+test2 (vector signed char x, vector bool char y)
+{
+  return vec_add (x, y);
+}
+
+vector signed char
+test3 (vector signed char x, vector signed char y)
+{
+  return vec_add (x, y);
+}
+
+vector unsigned char
+test4 (vector bool char x, vector unsigned char y)
+{
+  return vec_add (x, y);
+}
+
+vector unsigned char
+test5 (vector unsigned char x, vector bool char y)
+{
+  return vec_add (x, y);
+}
+
+vector unsigned char
+test6 (vector unsigned char x, vector unsigned char y)
+{
+  return vec_add (x, y);
+}
+
+/* { dg-final { scan-assembler-times "vaddubm" 6 } } */
Index: gcc/testsuite/gcc.target/powerpc/fold-vec-add-2.c

Re: [PATCH, Fortran] New warning flag -Wargument-mismatch to control argument mismatch warnings

[Jerry DeLisle]

On 11/01/2016 12:38 PM, Fritz Reese wrote:

See attached...




Good to go.


---
Fritz Reese


On Tue, Nov 1, 2016 at 11:24 AM, Fritz Reese  wrote:

All,

Here I propose a new warning flag -Wargument-mismatch to control
warnings emitted when the type, rank, or some other property of actual
arguments does not match that of a function's formal parameters
according to its declaration or interface specification. The warnings
are of course enabled by default, as they should be. Note also with
-Wno-argument-mismatch, only _warnings_ are suppressed. In such cases
where an argument mismatch is an error, the error is still properly
emitted.

This simple patch depends on the recently-submitted patch [1] "Allow
warnings given through gfc_error to associate with warning flags".
Since the argument mismatch warnings are sometimes errors, they are
currently emitted through gfc_error with `warnings_not_errors` set.
Without the solution in [1], awkward code changes may be required to
work around this fact.

The new flag is supplied for the benefit of those users which believe
that suppression of any given warning generated by a compiler should
be possible. Such users may be frustrated with the current GNU Fortran
front-end, in which there is no way to suppress this class of
warnings, even if the user "knows what he is doing" and refuses to
change his/her code.

[1] https://gcc.gnu.org/ml/fortran/2016-11/msg3.html

Bootstraps and regtests on x86_64-redhat-linux.

if (gfc_accepted ([1]))
  {
gfc_ask_ok_for_trunk ($0);
  }

---
Fritz Reese

Re: [PATCH] Emit DW_AT_inline for C++17 inline variables (take 2)

[Mark Wielaard]

On Wed, 2016-11-02 at 00:08 +0100, Mark Wielaard wrote:
> That seemed to have been the last usage of origin_die in gen_variable_die.
> So removing that caused:
> 
> /home/mark/src/gcc/gcc/dwarf2out.c: In function ‘void gen_variable_die(tree, 
> tree, dw_die_ref)’:
> /home/mark/src/gcc/gcc/dwarf2out.c:22454:14: error: variable ‘origin_die’ set 
> but not used [-Werror=unused-but-set-variable]
>dw_die_ref origin_die = NULL;
>   ^~
> cc1plus: all warnings being treated as errors
> make[3]: *** [dwarf2out.o] Error 1
> 
> The following seems to work around that and makes things build again for me:

Which is precisely what Jakub checked in 5 minutes before I sent that
email.

Sorry for the noise. Everything builds again.

Thanks,

Mark

Re: [PATCH] Emit DW_AT_inline for C++17 inline variables (take 2)

[Mark Wielaard]

On Tue, Nov 01, 2016 at 01:20:23PM -0400, Jason Merrill wrote:
> On Tue, Nov 1, 2016@12:10 PM, Jakub Jelinek  wrote:
> > + && !get_AT (var_die, DW_AT_inline)
> > + && (origin_die == NULL || get_AT (origin_die, DW_AT_inline) == 
> > NULL)
> 
> Can we drop this repetition (here and for DW_AT_const_expr)?  get_AT
> should look through DW_AT_abstract_origin, and we should have added
> that earlier in gen_variable_die.
> 
> OK with that change.

That seemed to have been the last usage of origin_die in gen_variable_die.
So removing that caused:

/home/mark/src/gcc/gcc/dwarf2out.c: In function ‘void gen_variable_die(tree, 
tree, dw_die_ref)’:
/home/mark/src/gcc/gcc/dwarf2out.c:22454:14: error: variable ‘origin_die’ set 
but not used [-Werror=unused-but-set-variable]
   dw_die_ref origin_die = NULL;
  ^~
cc1plus: all warnings being treated as errors
make[3]: *** [dwarf2out.o] Error 1

The following seems to work around that and makes things build again for me:

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 5ff6f97..24b85c1 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -22451,7 +22451,6 @@ gen_variable_die (tree decl, tree origin, dw_die_ref 
context_die)
   tree ultimate_origin;
   dw_die_ref var_die;
   dw_die_ref old_die = decl ? lookup_decl_die (decl) : NULL;
-  dw_die_ref origin_die = NULL;
   bool declaration = (DECL_EXTERNAL (decl_or_origin)
  || class_or_namespace_scope_p (context_die));
   bool specialization_p = false;
@@ -22627,7 +22626,7 @@ gen_variable_die (tree decl, tree origin, dw_die_ref 
context_die)
 var_die = new_die (DW_TAG_variable, context_die, decl);
 
   if (origin != NULL)
-origin_die = add_abstract_origin_attribute (var_die, origin);
+add_abstract_origin_attribute (var_die, origin);
 
   /* Loop unrolling can create multiple blocks that refer to the same
  static variable, so we must test for the DW_AT_declaration flag.

Cheers,

Mark

Re: [BUILDROBOT] dwarf2out.c:22452:14: error: variable ‘origin_die’ set but not used [-Werror=unused-but-set-variable]

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 11:34:08PM +0100, Jan-Benedict Glaw wrote:
> Hi Jakub!
> 
> Seems this patch caused some breakage when building via
> config-list.mk with a recent compiler (ie. with itself) :
> 
> +2016-11-01  Jakub Jelinek  
> +
> +   * dwarf2out.c (add_name_and_src_coords_attributes): Add 
> NO_LINKAGE_NAME
> +   argument, don't call add_linkage_name if it is true.
> +   (gen_variable_die): For C++ inline static data members, consider the
> +   initial call when old_die is NULL to be declaration and call
> +   add_name_and_src_coords_attributes in that case with true as
> +   NO_LINKAGE_NAME.  Add DW_AT_inline attribute if needed.
> +   (gen_member_die): For C++ inline static data members, emit a
> +   definition DIE right away in DW_TAG_compile_unit context.

Sorry, fixed thusly, committed as obvious:

2016-11-01  Jakub Jelinek  

* dwarf2out.c (gen_variable_die): Remove again origin_die variable
and its initialization.

--- gcc/dwarf2out.c (revision 241758)
+++ gcc/dwarf2out.c (working copy)
@@ -22451,7 +22451,6 @@ gen_variable_die (tree decl, tree origin
   tree ultimate_origin;
   dw_die_ref var_die;
   dw_die_ref old_die = decl ? lookup_decl_die (decl) : NULL;
-  dw_die_ref origin_die = NULL;
   bool declaration = (DECL_EXTERNAL (decl_or_origin)
  || class_or_namespace_scope_p (context_die));
   bool specialization_p = false;
@@ -22627,7 +22626,7 @@ gen_variable_die (tree decl, tree origin
 var_die = new_die (DW_TAG_variable, context_die, decl);
 
   if (origin != NULL)
-origin_die = add_abstract_origin_attribute (var_die, origin);
+add_abstract_origin_attribute (var_die, origin);
 
   /* Loop unrolling can create multiple blocks that refer to the same
  static variable, so we must test for the DW_AT_declaration flag.

Jakub

Re: [PATCH] libiberty: Fix memory leak in ada_demangle when symbol cannot be demangled.

[Ian Lance Taylor]

On Mon, Oct 31, 2016 at 2:57 AM, Mark Wielaard  wrote:
>
> libiberty/ChangeLog:
>
> * cplus-dem.c (ada_demangle): Initialize demangled to NULL and
> XDELETEVEC demangled when unknown.

This is OK.

Thanks.

Ian

[PATCH 2/2, expand] make expand_builtin_strncmp more general

[Aaron Sawdey]

This patch adds code to expand_builtin_strncmp so it also attempts
expansion via cmpstrnsi in the case where c_strlen() returns NULL for
both string arguments, meaning that neither one is a constant.

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC ToolchainIndex: builtins.c
===
--- builtins.c	(revision 241743)
+++ builtins.c	(working copy)
@@ -3929,61 +3929,85 @@
 unsigned int arg1_align = get_pointer_alignment (arg1) / BITS_PER_UNIT;
 unsigned int arg2_align = get_pointer_alignment (arg2) / BITS_PER_UNIT;
 
+/* If we don't have POINTER_TYPE, call the function.  */
+if (arg1_align == 0 || arg2_align == 0)
+  return NULL_RTX;
+
 len1 = c_strlen (arg1, 1);
 len2 = c_strlen (arg2, 1);
 
-if (len1)
-  len1 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len1);
-if (len2)
-  len2 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len2);
+if (!len1 && !len2)
+  {
+	/* If neither arg1 nor arg2 are constant strings.  */
+	/* Stabilize the arguments in case gen_cmpstrnsi fails.  */
+	arg1 = builtin_save_expr (arg1);
+	arg2 = builtin_save_expr (arg2);
+	/* Use save_expr here because cmpstrnsi may modify arg3
+	   and builtin_save_expr() doesn't force the save to happen.  */
+	len = save_expr (arg3);
+	len = fold_convert_loc (loc, sizetype, len);
+  }
+else
+  {
+	if (len1)
+	  len1 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len1);
+	if (len2)
+	  len2 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len2);
 
-/* If we don't have a constant length for the first, use the length
-   of the second, if we know it.  We don't require a constant for
-   this case; some cost analysis could be done if both are available
-   but neither is constant.  For now, assume they're equally cheap,
-   unless one has side effects.  If both strings have constant lengths,
-   use the smaller.  */
+	/* If we don't have a constant length for the first, use the length
+	   of the second, if we know it.  We don't require a constant for
+	   this case; some cost analysis could be done if both are available
+	   but neither is constant.  For now, assume they're equally cheap,
+	   unless one has side effects.  If both strings have constant lengths,
+	   use the smaller.  */
 
-if (!len1)
-  len = len2;
-else if (!len2)
-  len = len1;
-else if (TREE_SIDE_EFFECTS (len1))
-  len = len2;
-else if (TREE_SIDE_EFFECTS (len2))
-  len = len1;
-else if (TREE_CODE (len1) != INTEGER_CST)
-  len = len2;
-else if (TREE_CODE (len2) != INTEGER_CST)
-  len = len1;
-else if (tree_int_cst_lt (len1, len2))
-  len = len1;
-else
-  len = len2;
+	if (!len1)
+	  len = len2;
+	else if (!len2)
+	  len = len1;
+	else if (TREE_SIDE_EFFECTS (len1))
+	  len = len2;
+	else if (TREE_SIDE_EFFECTS (len2))
+	  len = len1;
+	else if (TREE_CODE (len1) != INTEGER_CST)
+	  len = len2;
+	else if (TREE_CODE (len2) != INTEGER_CST)
+	  len = len1;
+	else if (tree_int_cst_lt (len1, len2))
+	  len = len1;
+	else
+	  len = len2;
 
-/* If both arguments have side effects, we cannot optimize.  */
-if (!len || TREE_SIDE_EFFECTS (len))
-  return NULL_RTX;
+	/* If both arguments have side effects, we cannot optimize.  */
+	if (TREE_SIDE_EFFECTS (len))
+	  return NULL_RTX;
 
-/* The actual new length parameter is MIN(len,arg3).  */
-len = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (len), len,
-		   fold_convert_loc (loc, TREE_TYPE (len), arg3));
+	/* The actual new length parameter is MIN(len,arg3).  */
+	len = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (len), len,
+			   fold_convert_loc (loc, TREE_TYPE (len), arg3));
 
-/* If we don't have POINTER_TYPE, call the function.  */
-if (arg1_align == 0 || arg2_align == 0)
-  return NULL_RTX;
+	/* Stabilize the arguments in case gen_cmpstrnsi fails.  */
+	arg1 = builtin_save_expr (arg1);
+	arg2 = builtin_save_expr (arg2);
+	len = builtin_save_expr (len);
+  }
 
-/* Stabilize the arguments in case gen_cmpstrnsi fails.  */
-arg1 = builtin_save_expr (arg1);
-arg2 = builtin_save_expr (arg2);
-len = builtin_save_expr (len);
-
 arg1_rtx = get_memory_rtx (arg1, len);
 arg2_rtx = get_memory_rtx (arg2, len);
 arg3_rtx = expand_normal (len);
+
+/* Set MEM_SIZE as appropriate.  This will only happen in 
+   the case where incoming arg3 is constant and arg1/arg2 are not.  */
+if (CONST_INT_P (arg3_rtx))
+  {
+	set_mem_size (arg1_rtx, INTVAL (arg3_rtx));
+	set_mem_size (arg2_rtx, INTVAL (arg3_rtx));
+  }
+
 result = expand_cmpstrn_or_cmpmem (cmpstrn_icode, target, arg1_rtx,
    arg2_rtx, TREE_TYPE (len), arg3_rtx,
    MIN (arg1_align, arg2_align));
+
 if (result)
   {
 	/* Return the value in the proper mode for this function.  */

[PATCH 1/2, i386] cmpstrnsi needs string length

[Aaron Sawdey]

This patch adds a test to the cmpstrnsi pattern in i386.md so that it
will bail out (FAIL) if neither of the strings is a constant string. It
can only work as a proper strncmp if the length is not longer than both
of the strings. This change is required if expand_builtin_strncmp is
going to try expansion of strncmp when neither string argument is
constant.

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC ToolchainIndex: config/i386/i386.md
===
--- config/i386/i386.md	(revision 241743)
+++ config/i386/i386.md	(working copy)
@@ -16909,6 +16909,21 @@
   if (fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])
 FAIL;
 
+  /* One of the strings must be a constant.  If so, expand_builtin_strncmp()
+ will have rewritten the length arg to be the minimum of the const string
+ length and the actual length arg.  If both strings are the same and
+ shorter than the length arg, repz cmpsb will not stop at the 0 byte and
+ will incorrectly base the results on chars past the 0 byte.  */
+  tree t1 = MEM_EXPR (operands[1]);
+  tree t2 = MEM_EXPR (operands[2]);
+  if (!((t1 && TREE_CODE (t1) == MEM_REF
+ && TREE_CODE (TREE_OPERAND (t1, 0)) == ADDR_EXPR
+ && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t1, 0), 0)) == STRING_CST)
+  || (t2 && TREE_CODE (t2) == MEM_REF
+  && TREE_CODE (TREE_OPERAND (t2, 0)) == ADDR_EXPR
+  && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t2, 0), 0)) == STRING_CST)))
+FAIL;
+
   out = operands[0];
   if (!REG_P (out))
 out = gen_reg_rtx (SImode);

[PATCH 0/2] strncmp builtin expansion improvement

[Aaron Sawdey]

Builtin expansion of strncmp currently only happens when at least one
of the string arguments is a constant string. I'd like to make it also
attempt expansion of the cmpstrnsi pattern in the case where neither
argument is a constant string, as is already done with cmpstrsi in
expand_builtin_strcmp.

There are two parts to this patch:

1) The i386 pattern for cmpstrnsi uses repz cmpsb which does not test
for the zero byte ending the string. At present this relies on the fact
that expand_builtin_strncmp and expand_builtin_strcmp make sure that
there is one string that is constant and the length passed is no longer
than this string. This keeps it out of the failure case: when the
strings are identical but the length is longer so repz cmpsb continues
comparing past the zero byte and produces incorrect results.

2) The actual change to expand_builtin_strncmp. This attempts expansion
via cmpstrnsi in the case where c_strlen() return null for both
strings.

With these two patches bootstrap passes on x86_64 linux, currently
checking regtest. If clean, ok for trunk?

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain

Re: RFA (tree-inline): PATCH for C++ inheriting constructors overhaul

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 05:33:17PM -0400, Jason Merrill wrote:
> Like so?

LGTM, thanks.

> diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
> index de5e575..6899d2a 100644
> --- a/gcc/tree-inline.c
> +++ b/gcc/tree-inline.c
> @@ -1045,6 +1045,7 @@ copy_tree_body_r (tree *tp, int *walk_subtrees, void 
> *data)
>copy_body_data *id = (copy_body_data *) data;
>tree fn = id->src_fn;
>tree new_block;
> +  bool copied = false;
>  
>/* Begin by recognizing trees that we'll completely rewrite for the
>   inlining context.  Our output for these trees is completely
> @@ -1241,10 +1242,40 @@ copy_tree_body_r (tree *tp, int *walk_subtrees, void 
> *data)
> *walk_subtrees = 0;
> return NULL;
>   }
> +  else if (TREE_CODE (*tp) == COND_EXPR)
> + {
> +   tree cond = TREE_OPERAND (*tp, 0);
> +   walk_tree (, copy_tree_body_r, data, NULL);
> +   tree folded = fold (cond);
> +   if (TREE_CODE (folded) == INTEGER_CST)
> + {
> +   /* Only copy the taken branch; for a C++ base constructor clone
> +  inherited from a virtual base, copying the other branch leads
> +  to references to parameters that were optimized away.  */
> +   tree branch = (integer_nonzerop (folded)
> +  ? TREE_OPERAND (*tp, 1)
> +  : TREE_OPERAND (*tp, 2));
> +   tree type = TREE_TYPE (*tp);
> +   if (VOID_TYPE_P (type)
> +   || type == TREE_TYPE (branch))
> + {
> +   *tp = branch;
> +   return copy_tree_body_r (tp, walk_subtrees, data);
> + }
> + }
> +   /* Avoid copying the condition twice.  */
> +   copy_tree_r (tp, walk_subtrees, NULL);
> +   TREE_OPERAND (*tp, 0) = cond;
> +   walk_tree (_OPERAND (*tp, 1), copy_tree_body_r, data, NULL);
> +   walk_tree (_OPERAND (*tp, 2), copy_tree_body_r, data, NULL);
> +   *walk_subtrees = 0;
> +   copied = true;
> + }
>  
>/* Here is the "usual case".  Copy this tree node, and then
>tweak some special cases.  */
> -  copy_tree_r (tp, walk_subtrees, NULL);
> +  if (!copied)
> + copy_tree_r (tp, walk_subtrees, NULL);
>  
>/* If EXPR has block defined, map it to newly constructed block.
>   When inlining we want EXPRs without block appear in the block


Jakub

Re: libgo: Fix GOARCH_PHYSPAGESIZE for ia64

[Ian Lance Taylor]

On Mon, Oct 31, 2016 at 2:02 AM, Andreas Schwab  wrote:
> diff --git a/libgo/configure b/libgo/configure
> index 3c866f7f21..7a9df58c21 100755
> --- a/libgo/configure
> +++ b/libgo/configure
> @@ -13677,7 +13677,7 @@ rm -f core conftest.err conftest.$ac_objext 
> conftest.$ac_ext
>  GOARCH=ia64
>  GOARCH_FAMILY=IA64
>  GOARCH_CACHELINESIZE=16384
> -GOARCH_PHYSPAGESIZE=8192
> +GOARCH_PHYSPAGESIZE=65536
>  ;;
>m68k*-*-*)
>  GOARCH=m68k
> diff --git a/libgo/configure.ac b/libgo/configure.ac
> index 2951392ed1..ed2edd3b69 100644
> --- a/libgo/configure.ac
> +++ b/libgo/configure.ac
> @@ -254,7 +254,7 @@ GOARCH_HUGEPAGESIZE="1 << 21"
>  GOARCH=ia64
>  GOARCH_FAMILY=IA64
>  GOARCH_CACHELINESIZE=16384
> -GOARCH_PHYSPAGESIZE=8192
> +GOARCH_PHYSPAGESIZE=65536
>  ;;
>m68k*-*-*)
>  GOARCH=m68k

Thanks.

Committed.

Ian

Re: [RFC][PATCH] Remove a bad use of SLOW_UNALIGNED_ACCESS

[Wilco Dijkstra]

 Jeff Law  wrote:

> I think you'll need to look at bz61320 before this could go in.

I had a look, but there is nothing there that is related - eventually
a latent alignment bug was fixed in IVOpt. Note that the bswap phase
currently inserts unaligned accesses irrespectively of STRICT_ALIGNMENT
or SLOW_UNALIGNED_ACCESS:

-  if (bswap
 - && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
 - && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
 -   return false;

If bswap is false no byte swap is needed, so we found a native endian load
and it will always perform the optimization by inserting an unaligned load.
This apparently works on all targets, and doesn't cause alignment traps or
huge slowdowns via trap emulation claimed by SLOW_UNALIGNED_ACCESS.
So I'm at a loss what these macros are supposed to mean and how I can query
whether a backend supports fast unaligned access for a particular mode.

What I actually want to write is something like:

 if (!FAST_UNALIGNED_LOAD (mode, align)) return false;

And know that it only accepts unaligned accesses that are efficient on the 
target.
Maybe we need a new hook like this and get rid of the old one?

Wilco

Re: RFA (tree-inline): PATCH for C++ inheriting constructors overhaul

[Jason Merrill]

On Tue, Nov 1, 2016 at 4:20 PM, Jakub Jelinek  wrote:
> On Mon, Oct 31, 2016 at 11:45:08AM -0400, Jason Merrill wrote:
>> Is the tree-inline.c patch OK for trunk?
>
>> --- a/gcc/tree-inline.c
>> +++ b/gcc/tree-inline.c
>> @@ -1241,6 +1241,28 @@ copy_tree_body_r (tree *tp, int *walk_subtrees, void 
>> *data)
>> *walk_subtrees = 0;
>> return NULL;
>>   }
>> +  else if (TREE_CODE (*tp) == COND_EXPR)
>> + {
>> +   tree cond = TREE_OPERAND (*tp, 0);
>> +   walk_tree (, copy_tree_body_r, data, NULL);
>> +   cond = fold (cond);
>> +   if (TREE_CODE (cond) == INTEGER_CST)
>> + {
>> +   /* Only copy the taken branch; for a C++ base constructor clone
>> +  inherited from a virtual base, copying the other branch leads
>> +  to references to parameters that were optimized away.  */
>> +   tree branch = (integer_nonzerop (cond)
>> +  ? TREE_OPERAND (*tp, 1)
>> +  : TREE_OPERAND (*tp, 2));
>> +   tree type = TREE_TYPE (*tp);
>> +   if (VOID_TYPE_P (type)
>> +   || type == TREE_TYPE (branch))
>> + {
>> +   *tp = branch;
>> +   return copy_tree_body_r (tp, walk_subtrees, data);
>> + }
>> + }
>> + }
>
> This doesn't look right to me.  I believe if we walk_tree copy_tree_body_r
> any operand, we have to walk all of them and *walk_subtrees = 0;, otherwise
> we'll effectively walk and copy possibly huge condition twice (which can
> have very bad compile time / memory effects if the condition has many
> COND_EXPRs in it).
> So I think if you don't return copy_tree_body_r (tp, walk_subtrees, data);,
> you should do something like:
> copy_tree_r (tp, walk_subtrees, NULL);
> TREE_OPERAND (*tp, 0) = cond;
> walk_tree (_OPERAND (*tp, 1), copy_tree_body_r, data, NULL);
> walk_tree (_OPERAND (*tp, 2), copy_tree_body_r, data, NULL);
> *walk_subtrees = 0;
> and then somehow arrange to continue after the
> copy_tree_r (tp, walk_subtrees, NULL);
> a few lines later, in particular the TREE_SET_BLOCK stuff, and
> remap_type stuff (dunno if goto, or conditionalize the copy_tree_r there
> on *walk_subtrees != 0, or what).
> The case of a constant cond is likely ok, tp should already initially
> point to an operand of a newly copied tree, just with the old COND_EXPR,
> so if we replace it with a branch and recurse that should handle all the
> copying/remapping etc.

Like so?
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index de5e575..6899d2a 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1045,6 +1045,7 @@ copy_tree_body_r (tree *tp, int *walk_subtrees, void 
*data)
   copy_body_data *id = (copy_body_data *) data;
   tree fn = id->src_fn;
   tree new_block;
+  bool copied = false;
 
   /* Begin by recognizing trees that we'll completely rewrite for the
  inlining context.  Our output for these trees is completely
@@ -1241,10 +1242,40 @@ copy_tree_body_r (tree *tp, int *walk_subtrees, void 
*data)
  *walk_subtrees = 0;
  return NULL;
}
+  else if (TREE_CODE (*tp) == COND_EXPR)
+   {
+ tree cond = TREE_OPERAND (*tp, 0);
+ walk_tree (, copy_tree_body_r, data, NULL);
+ tree folded = fold (cond);
+ if (TREE_CODE (folded) == INTEGER_CST)
+   {
+ /* Only copy the taken branch; for a C++ base constructor clone
+inherited from a virtual base, copying the other branch leads
+to references to parameters that were optimized away.  */
+ tree branch = (integer_nonzerop (folded)
+? TREE_OPERAND (*tp, 1)
+: TREE_OPERAND (*tp, 2));
+ tree type = TREE_TYPE (*tp);
+ if (VOID_TYPE_P (type)
+ || type == TREE_TYPE (branch))
+   {
+ *tp = branch;
+ return copy_tree_body_r (tp, walk_subtrees, data);
+   }
+   }
+ /* Avoid copying the condition twice.  */
+ copy_tree_r (tp, walk_subtrees, NULL);
+ TREE_OPERAND (*tp, 0) = cond;
+ walk_tree (_OPERAND (*tp, 1), copy_tree_body_r, data, NULL);
+ walk_tree (_OPERAND (*tp, 2), copy_tree_body_r, data, NULL);
+ *walk_subtrees = 0;
+ copied = true;
+   }
 
   /* Here is the "usual case".  Copy this tree node, and then
 tweak some special cases.  */
-  copy_tree_r (tp, walk_subtrees, NULL);
+  if (!copied)
+   copy_tree_r (tp, walk_subtrees, NULL);
 
   /* If EXPR has block defined, map it to newly constructed block.
  When inlining we want EXPRs without block appear in the block

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Jason Merrill]

On Tue, Nov 1, 2016 at 4:00 PM, Bernd Edlinger
 wrote:
> On 11/01/16 20:48, Jason Merrill wrote:
>>>   else if ((DECL_EXTERN_C_P (newdecl)
>>> && DECL_EXTERN_C_P (olddecl))
>>>|| compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
>>>  TYPE_ARG_TYPES (TREE_TYPE (olddecl

 So I was thinking to drop the "else" and the compparms test.
>>>
>>> Yes.  But then we must somehow avoid:
>>>
>>>else
>>>  /* Discard the old built-in function.  */
>>>  return NULL_TREE;

>>> It maybe easier, just to copy the warning to the DECL_ANTICIPATED case?
>>
>> Or even move it there; removing the existing warning doesn't change
>> anything in the testsuite, and I'm having trouble imagining how to
>> trigger it.
>>
>
> Nice.  It must be something, which does not anticipate a declaration.
>
> like:
>
> cat test.cc
> int __builtin_abort(void*);
>
> g++ -c test.cc
> test.cc:1:5: warning: new declaration 'int __builtin_abort(void*)'
> ambiguates built-in declaration 'void __builtin_abort()'
>   int __builtin_abort(void*);
>   ^~~
>
> Intersting, the warning comes even though I forgot to add the
> extern "C".

Looks like anything starting with __builtin is implicitly extern "C"
(set in grokfndecl).

If we remove the DECL_ANTICIPATED check, I see some failures in
builtin* tests due to missing extern "C".  That seems appropriate at
file scope, but I'm not sure it's right for namespace std.

Jason

Re: [RFC][PATCH] Remove a bad use of SLOW_UNALIGNED_ACCESS

[Jeff Law]

On 11/01/2016 11:36 AM, Wilco Dijkstra wrote:

Looking at PR77308, one of the issues is that the bswap optimization
phase doesn't work on ARM.  This is due to an odd check that uses
SLOW_UNALIGNED_ACCESS (which is always true on ARM).  Since the testcase
in PR77308 generates much better code with this patch (~13% fewer
instructions), it seems best to remove this odd check.

This exposes a problem with SLOW_UNALIGNED_ACCESS - what is it supposed
to mean or do? According to its current definition, it means we should
never emit an unaligned access for a given mode as it would lead to a
trap.  However that is not what happens, for example all integer modes on
ARM support really fast unaligned access and we generate unaligned instructions
without any issues.  Some Thumb-1 targets automatically expand unaligned
accesses if necessary.  So this macro clearly doesn't stop unaligned accesses
from being generated.

So I want to set it to false for most modes on ARM as they are not slow.
However doing so causes incorrect code generation and unaligned traps.
How can we differentiate between modes that support fast unaligned access
in hardware, modes that get expanded and modes that should never be used in
an unaligned access?

Bootstrap & regress OK.

ChangeLog:
2015-11-01  Wilco Dijkstra  

gcc/
* tree-ssa-math-opts.c (bswap_replace): Remove test
of SLOW_UNALIGNED_ACCESS.

testsuite/
* gcc.dg/optimize-bswapdi-3.c: Remove xfail.
* gcc.dg/optimize-bswaphi-1.c: Likewise.
* gcc.dg/optimize-bswapsi-2.c: Likewise.

I think you'll need to look at bz61320 before this could go in.

jeff

Re: [PATCH] DWARF5 .debug_rnglists support

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 09:44:27PM +0100, Rainer Orth wrote:
> this patch broke Solaris bootstrap with /bin/as:
> 
> /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c: In function 'void 
> output_rnglists()':
> /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11055:8: error: unused variable 
> 'basebuf' [-Werror=unused-variable]
>char basebuf[MAX_ARTIFICIAL_LABEL_BYTES];
> ^~~
> /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11088:16: error: unused variable 
> 'len' [-Werror=unused-variable]
>unsigned int len = vec_safe_length (ranges_table);
> ^~~
> 
> Fixed as follows; will commit as obvious once i386-pc-solaris2.12 and
> sparc-sun-solaris2.12 bootstrap have finished successfully.

> 2016-11-01  Rainer Orth  
> 
>   * dwarf2out.c (output_rnglists): Wrap basebuf, len in
>   HAVE_AS_LEB128.

Thanks, sorry for not testing it without HAVE_AS_LEB128
(the loclists patch I've tested by temporarily changing
HAVE_AS_LEB128 to HAVE_AS_LEB128X, but forgot to do that
with this patch).

> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -11052,7 +11052,9 @@ output_rnglists (void)
>dw_ranges *r;
>char l1[MAX_ARTIFICIAL_LABEL_BYTES];
>char l2[MAX_ARTIFICIAL_LABEL_BYTES];
> +#ifdef HAVE_AS_LEB128
>char basebuf[MAX_ARTIFICIAL_LABEL_BYTES];
> +#endif
>  
>switch_to_section (debug_ranges_section);
>ASM_OUTPUT_LABEL (asm_out_file, ranges_section_label);
> @@ -11085,9 +11087,9 @@ output_rnglists (void)
>   ranges_base_label, NULL);
>  }
>  
> -  unsigned int len = vec_safe_length (ranges_table);
>const char *lab = "";
>  #ifdef HAVE_AS_LEB128
> +  unsigned int len = vec_safe_length (ranges_table);
>const char *base = NULL;
>  #endif
>FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)


Jakub

Re: [PATCH] DWARF5 .debug_rnglists support

[Rainer Orth]

Hi Jakub,

> 2016-11-01  Jakub Jelinek  
>
>   * tree.h (BLOCK_IN_COLD_SECTION_P): Define.
>   * final.c (final_scan_insn): Set BLOCK_IN_COLD_SECTION_P.
>   * dwarf2out.c (rnglist_idx): New variable.
>   (struct dw_ranges): Add label, idx and maybe_new_sec fields.
>   (DEBUG_RNGLISTS_SECTION): Define.
>   (ranges_base_label): New variable.
>   (size_of_die) : If using
>   DW_FORM_rnglistx, count size of uleb128 of range list index.
>   (value_format) : For
>   -gdwarf-5 -gsplit-dwarf return DW_FORM_rnglistx.
>   (output_range_list_offset): Handle -gdwarf-5 .debug_rnglists
>   offsets.  Multiply dwarf < 5 offsets by 2 * DWARF_ADDR_SIZE.
>   (add_ranges_num): Remove useless prototype.  Don't multiply
>   by 2 * DWARF2_ADDR_SIZE.  Add maybe_new_sec argument, adjust
>   for new fields added to dw_ranges struct.
>   (add_ranges): Add maybe_new_sec argument and pass it
>   through to add_ranges_num.
>   (note_rnglist_head): New function.
>   (add_ranges_by_labels): Pass true as maybe_new_sec to
>   add_ranges_num, call note_rnglist_head on the head of the list.
>   (output_ranges): Add function comment.  Switch to
>   .debug_ranges section here and emit .Ldebug_ranges0 label.
>   (index_rnglists, output_rnglists): New functions.
>   (gen_subprogram_die): Formatting fixes.
>   (add_high_low_attributes): Don't divide offsets
>   by 2 * DWARF2_ADDR_SIZE.  Call note_rnglist_head on the
>   first list element or when pointing into the middle of
>   a list.  Pass true as second argument to add_ranges on the
>   first block fragment after cold/hot section switch.
>   (init_sections_and_labels): For -gdwarf-5 use .debug_rnglists
>   section instead of .debug_ranges.  Initialize
>   ranges_base_label if -gdwarf-5 -gsplit-dwarf.
>   (dwarf2out_finish): For -gdwarf-5 -gsplit-dwarf call
>   index_rnglists and add DW_AT_rnglists_base attr.  Don't switch
>   to dwarf_ranges_section here or emit .Ldebug_ranges0 label.
>   Call output_rnglists for -gdwarf-5.
>   (dwarf2out_c_finalize): Clear rnglist_idx.

this patch broke Solaris bootstrap with /bin/as:

/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c: In function 'void 
output_rnglists()':
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11055:8: error: unused variable 
'basebuf' [-Werror=unused-variable]
   char basebuf[MAX_ARTIFICIAL_LABEL_BYTES];
^~~
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11088:16: error: unused variable 
'len' [-Werror=unused-variable]
   unsigned int len = vec_safe_length (ranges_table);
^~~

Fixed as follows; will commit as obvious once i386-pc-solaris2.12 and
sparc-sun-solaris2.12 bootstrap have finished successfully.

Rainer

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


2016-11-01  Rainer Orth  

* dwarf2out.c (output_rnglists): Wrap basebuf, len in
HAVE_AS_LEB128.

# HG changeset patch
# Parent  82d985a9e114ce85dac367da31077070f40d7ab8
Fix dwarf2out.c non-leb128 bootstrap failure

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -11052,7 +11052,9 @@ output_rnglists (void)
   dw_ranges *r;
   char l1[MAX_ARTIFICIAL_LABEL_BYTES];
   char l2[MAX_ARTIFICIAL_LABEL_BYTES];
+#ifdef HAVE_AS_LEB128
   char basebuf[MAX_ARTIFICIAL_LABEL_BYTES];
+#endif
 
   switch_to_section (debug_ranges_section);
   ASM_OUTPUT_LABEL (asm_out_file, ranges_section_label);
@@ -11085,9 +11087,9 @@ output_rnglists (void)
 ranges_base_label, NULL);
 }
 
-  unsigned int len = vec_safe_length (ranges_table);
   const char *lab = "";
 #ifdef HAVE_AS_LEB128
+  unsigned int len = vec_safe_length (ranges_table);
   const char *base = NULL;
 #endif
   FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)

Re: RFA (tree-inline): PATCH for C++ inheriting constructors overhaul

[Jakub Jelinek]

On Mon, Oct 31, 2016 at 11:45:08AM -0400, Jason Merrill wrote:
> Is the tree-inline.c patch OK for trunk?

> --- a/gcc/tree-inline.c
> +++ b/gcc/tree-inline.c
> @@ -1241,6 +1241,28 @@ copy_tree_body_r (tree *tp, int *walk_subtrees, void 
> *data)
> *walk_subtrees = 0;
> return NULL;
>   }
> +  else if (TREE_CODE (*tp) == COND_EXPR)
> + {
> +   tree cond = TREE_OPERAND (*tp, 0);
> +   walk_tree (, copy_tree_body_r, data, NULL);
> +   cond = fold (cond);
> +   if (TREE_CODE (cond) == INTEGER_CST)
> + {
> +   /* Only copy the taken branch; for a C++ base constructor clone
> +  inherited from a virtual base, copying the other branch leads
> +  to references to parameters that were optimized away.  */
> +   tree branch = (integer_nonzerop (cond)
> +  ? TREE_OPERAND (*tp, 1)
> +  : TREE_OPERAND (*tp, 2));
> +   tree type = TREE_TYPE (*tp);
> +   if (VOID_TYPE_P (type)
> +   || type == TREE_TYPE (branch))
> + {
> +   *tp = branch;
> +   return copy_tree_body_r (tp, walk_subtrees, data);
> + }
> + }
> + }

This doesn't look right to me.  I believe if we walk_tree copy_tree_body_r
any operand, we have to walk all of them and *walk_subtrees = 0;, otherwise
we'll effectively walk and copy possibly huge condition twice (which can
have very bad compile time / memory effects if the condition has many
COND_EXPRs in it).
So I think if you don't return copy_tree_body_r (tp, walk_subtrees, data);,
you should do something like:
copy_tree_r (tp, walk_subtrees, NULL);
TREE_OPERAND (*tp, 0) = cond;
walk_tree (_OPERAND (*tp, 1), copy_tree_body_r, data, NULL);
walk_tree (_OPERAND (*tp, 2), copy_tree_body_r, data, NULL);
*walk_subtrees = 0;
and then somehow arrange to continue after the
copy_tree_r (tp, walk_subtrees, NULL);
a few lines later, in particular the TREE_SET_BLOCK stuff, and
remap_type stuff (dunno if goto, or conditionalize the copy_tree_r there
on *walk_subtrees != 0, or what).
The case of a constant cond is likely ok, tp should already initially
point to an operand of a newly copied tree, just with the old COND_EXPR,
so if we replace it with a branch and recurse that should handle all the
copying/remapping etc.

Jakub

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Bernd Edlinger]

On 11/01/16 20:48, Jason Merrill wrote:
>>   else if ((DECL_EXTERN_C_P (newdecl)
>> && DECL_EXTERN_C_P (olddecl))
>>|| compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
>>  TYPE_ARG_TYPES (TREE_TYPE (olddecl
>>>
>>> So I was thinking to drop the "else" and the compparms test.
>>
>> Yes.  But then we must somehow avoid:
>>
>>else
>>  /* Discard the old built-in function.  */
>>  return NULL_TREE;
>>
>> It maybe easier, just to copy the warning to the DECL_ANTICIPATED case?
>
> Or even move it there; removing the existing warning doesn't change
> anything in the testsuite, and I'm having trouble imagining how to
> trigger it.
>

Nice.  It must be something, which does not anticipate a declaration.

like:

cat test.cc
int __builtin_abort(void*);

g++ -c test.cc
test.cc:1:5: warning: new declaration 'int __builtin_abort(void*)' 
ambiguates built-in declaration 'void __builtin_abort()'
  int __builtin_abort(void*);
  ^~~

Intersting, the warning comes even though I forgot to add the
extern "C".


Bernd.

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Jason Merrill]

On Tue, Nov 1, 2016 at 2:15 PM, Bernd Edlinger
 wrote:
> On 11/01/16 18:11, Jason Merrill wrote:
>> On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger
>>  wrote:
>>> On 11/01/16 16:20, Jason Merrill wrote:
 On 10/17/2016 03:18 PM, Bernd Edlinger wrote:
 I'm not even sure we need a new warning.  Can we combine this warning
 with the block that currently follows?
>>>
>>> After 20 years of not having a warning on that,
>>> an implicitly enabled warning would at least break lots of bogus
>>> test cases.
>>
>> Would it, though?  Which test cases still break with the current patch?
>
> Less than before, but there are still at least a few of them.
>
> I can make a list and send it tomorrow.
>
>>> Of course in C we have an implicitly enabled warning,
>>> so I would like to at least enable the warning on -Wall, thus
>>> -Wshadow is too weak IMO.
>>
>> Right.  The -Wshadow warning is for file-local declarations, so that
>> doesn't apply to your testcase; I was thinking that we should hit the
>> first (currently unconditional) warning.
>>
>   else if ((DECL_EXTERN_C_P (newdecl)
> && DECL_EXTERN_C_P (olddecl))
>|| compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
>  TYPE_ARG_TYPES (TREE_TYPE (olddecl
>>
>> So I was thinking to drop the "else" and the compparms test.
>
> Yes.  But then we must somehow avoid:
>
>else
>  /* Discard the old built-in function.  */
>  return NULL_TREE;
>
> It maybe easier, just to copy the warning to the DECL_ANTICIPATED case?

Or even move it there; removing the existing warning doesn't change
anything in the testsuite, and I'm having trouble imagining how to
trigger it.

Jason

[PATCH] xtensa: don't xfail gcc.c-torture/compile/20001226-1.c

[Max Filippov]

With jump trampolines implemented in binutils since 2.25 and enabled by
default this test no longer fails on xtensa.

2016-11-01  Max Filippov  
gcc/testsuite/
* gcc.c-torture/compile/20001226-1.c: Don't xfail on xtensa.
---
 gcc/testsuite/gcc.c-torture/compile/20001226-1.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c 
b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
index 127c4da..687b43a 100644
--- a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
@@ -1,7 +1,6 @@
 /* { dg-do assemble } */
 /* { dg-skip-if "too much code for avr" { "avr-*-*" } { "*" } { "" } } */
 /* { dg-skip-if "too much code for pdp11" { "pdp11-*-*" } { "*" } { "" } } */
-/* { dg-xfail-if "jump beyond 128K not supported" { xtensa*-*-* } { "-O0" } { 
"" } } */
 /* { dg-xfail-if "PR36698" { spu-*-* } { "-O0" } { "" } } */
 /* { dg-skip-if "" { m32c-*-* } { "*" } { "" } } */
 /* { dg-timeout-factor 4.0 } */
-- 
2.1.4

Re: [PATCH, Fortran] New warning flag -Wargument-mismatch to control argument mismatch warnings

[Fritz Reese]

And changelog


From: Fritz O. Reese 
Date: Tue, 1 Nov 2016 10:54:39 -0400
Subject: [PATCH] New warning -Wargument-mismatch for function argument
mismatches.

gcc/fortran/
* lang.opt, invoke.texi: New argument -Wargument-mismatch.
* interface.c (compare_parameter, compare_actual_formal,
gfc_check_typebound_override, argument_rank_mismatch): Control argument
mismatch warnings with -Wargument-mismatch.
* resolve.c (resolve_structure_cons, resolve_global_procedure): Ditto.

gcc/testsuite/gfortran.dg/
* warn_argument_mismatch_1.f90: New test.

---
Fritz Reese


On Tue, Nov 1, 2016 at 3:38 PM, Fritz Reese  wrote:
> See attached...
>
> ---
> Fritz Reese
>
>
> On Tue, Nov 1, 2016 at 11:24 AM, Fritz Reese  wrote:
>> All,
>>
>> Here I propose a new warning flag -Wargument-mismatch to control
>> warnings emitted when the type, rank, or some other property of actual
>> arguments does not match that of a function's formal parameters
>> according to its declaration or interface specification. The warnings
>> are of course enabled by default, as they should be. Note also with
>> -Wno-argument-mismatch, only _warnings_ are suppressed. In such cases
>> where an argument mismatch is an error, the error is still properly
>> emitted.
>>
>> This simple patch depends on the recently-submitted patch [1] "Allow
>> warnings given through gfc_error to associate with warning flags".
>> Since the argument mismatch warnings are sometimes errors, they are
>> currently emitted through gfc_error with `warnings_not_errors` set.
>> Without the solution in [1], awkward code changes may be required to
>> work around this fact.
>>
>> The new flag is supplied for the benefit of those users which believe
>> that suppression of any given warning generated by a compiler should
>> be possible. Such users may be frustrated with the current GNU Fortran
>> front-end, in which there is no way to suppress this class of
>> warnings, even if the user "knows what he is doing" and refuses to
>> change his/her code.
>>
>> [1] https://gcc.gnu.org/ml/fortran/2016-11/msg3.html
>>
>> Bootstraps and regtests on x86_64-redhat-linux.
>>
>> if (gfc_accepted ([1]))
>>   {
>> gfc_ask_ok_for_trunk ($0);
>>   }
>>
>> ---
>> Fritz Reese

Re: [PATCH, Fortran] New warning flag -Wargument-mismatch to control argument mismatch warnings

[Fritz Reese]

See attached...

---
Fritz Reese


On Tue, Nov 1, 2016 at 11:24 AM, Fritz Reese  wrote:
> All,
>
> Here I propose a new warning flag -Wargument-mismatch to control
> warnings emitted when the type, rank, or some other property of actual
> arguments does not match that of a function's formal parameters
> according to its declaration or interface specification. The warnings
> are of course enabled by default, as they should be. Note also with
> -Wno-argument-mismatch, only _warnings_ are suppressed. In such cases
> where an argument mismatch is an error, the error is still properly
> emitted.
>
> This simple patch depends on the recently-submitted patch [1] "Allow
> warnings given through gfc_error to associate with warning flags".
> Since the argument mismatch warnings are sometimes errors, they are
> currently emitted through gfc_error with `warnings_not_errors` set.
> Without the solution in [1], awkward code changes may be required to
> work around this fact.
>
> The new flag is supplied for the benefit of those users which believe
> that suppression of any given warning generated by a compiler should
> be possible. Such users may be frustrated with the current GNU Fortran
> front-end, in which there is no way to suppress this class of
> warnings, even if the user "knows what he is doing" and refuses to
> change his/her code.
>
> [1] https://gcc.gnu.org/ml/fortran/2016-11/msg3.html
>
> Bootstraps and regtests on x86_64-redhat-linux.
>
> if (gfc_accepted ([1]))
>   {
> gfc_ask_ok_for_trunk ($0);
>   }
>
> ---
> Fritz Reese
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index b851d5a..4dd432e 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2139,17 +2139,17 @@ argument_rank_mismatch (const char *name, locus *where,
 }
   else if (rank1 == 0)
 {
-  gfc_error ("Rank mismatch in argument %qs at %L "
+  gfc_error (OPT_Wargument_mismatch, "Rank mismatch in argument %qs at %L "
 "(scalar and rank-%d)", name, where, rank2);
 }
   else if (rank2 == 0)
 {
-  gfc_error ("Rank mismatch in argument %qs at %L "
+  gfc_error (OPT_Wargument_mismatch, "Rank mismatch in argument %qs at %L "
 "(rank-%d and scalar)", name, where, rank1);
 }
   else
 {
-  gfc_error ("Rank mismatch in argument %qs at %L "
+  gfc_error (OPT_Wargument_mismatch, "Rank mismatch in argument %qs at %L "
 "(rank-%d and rank-%d)", name, where, rank1, rank2);
 }
 }
@@ -2200,7 +2200,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   sizeof(err), NULL, NULL))
{
  if (where)
-   gfc_error ("Interface mismatch in dummy procedure %qs at %L: %s",
+   gfc_error (OPT_Wargument_mismatch,
+  "Interface mismatch in dummy procedure %qs at %L: %s",
   formal->name, >where, err);
  return 0;
}
@@ -2227,7 +2228,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   err, sizeof(err), NULL, NULL))
{
  if (where)
-   gfc_error ("Interface mismatch in dummy procedure %qs at %L: %s",
+   gfc_error (OPT_Wargument_mismatch,
+  "Interface mismatch in dummy procedure %qs at %L: %s",
   formal->name, >where, err);
  return 0;
}
@@ -2253,7 +2255,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
 CLASS_DATA (actual)->ts.u.derived)))
 {
   if (where)
-   gfc_error ("Type mismatch in argument %qs at %L; passed %s to %s",
+   gfc_error (OPT_Wargument_mismatch,
+  "Type mismatch in argument %qs at %L; passed %s to %s",
   formal->name, where, gfc_typename (>ts),
   gfc_typename (>ts));
   return 0;
@@ -2957,7 +2960,7 @@ compare_actual_formal (gfc_actual_arglist **ap, 
gfc_formal_arglist *formal,
f->sym->ts.u.cl->length->value.integer) != 0))
 {
   if (where && (f->sym->attr.pointer || f->sym->attr.allocatable))
-gfc_warning (0,
+gfc_warning (OPT_Wargument_mismatch,
  "Character length mismatch (%ld/%ld) between actual "
  "argument and pointer or allocatable dummy argument "
  "%qs at %L",
@@ -2965,7 +2968,7 @@ compare_actual_formal (gfc_actual_arglist **ap, 
gfc_formal_arglist *formal,
  mpz_get_si (f->sym->ts.u.cl->length->value.integer),
  f->sym->name, >expr->where);
   else if (where)
-gfc_warning (0,
+gfc_warning (OPT_Wargument_mismatch,
  "Character length mismatch (%ld/%ld) between actual "
  "argument and assumed-shape dummy argument %qs "
  

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 01:12:55PM -0600, Jeff Law wrote:
> On 11/01/2016 08:10 AM, Jakub Jelinek wrote:
> >On Mon, Oct 31, 2016 at 08:39:15PM -0600, Martin Sebor wrote:
> >>Attached is an updated patch that works around the problem with
> >>the definition of the NOTE_DATA macro discussed below.  I've
> >>raised bug 78174 for it and temporarily worked around it in
> >>the patch.  I'll see if I can come up with a patch to fix the
> >>macro the "right way" but would prefer to do that separately.
> >>The NOTE_DATA macro is implemented in terms of the RTL_CHECK1
> >>macro that will need to change and that macro is used in many
> >>others, so I would rather not mess around with those as part
> >>of this patch.
> >
> >No, you just shouldn't use __bos (*, 1) in the warning code
> >for mem* like builtins.
> Can you explain to Martin why so that he can adjust accordingly?

I've tried to explain that in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174#c7

Jakub

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

[Jeff Law]

On 11/01/2016 08:10 AM, Jakub Jelinek wrote:

On Mon, Oct 31, 2016 at 08:39:15PM -0600, Martin Sebor wrote:

Attached is an updated patch that works around the problem with
the definition of the NOTE_DATA macro discussed below.  I've
raised bug 78174 for it and temporarily worked around it in
the patch.  I'll see if I can come up with a patch to fix the
macro the "right way" but would prefer to do that separately.
The NOTE_DATA macro is implemented in terms of the RTL_CHECK1
macro that will need to change and that macro is used in many
others, so I would rather not mess around with those as part
of this patch.


No, you just shouldn't use __bos (*, 1) in the warning code
for mem* like builtins.

Can you explain to Martin why so that he can adjust accordingly?

jeff

[PATCH] xtensa: fix ICE on pr59037.c test

[Max Filippov]

xtensa gcc gets ICE on pr59037.c test because its xtensa_output_literal
function cannot handle integer literals of sizes other than 4 and 8,
whereas the test uses 16-byte int vector.
Split integer literal formatting into the recursive function
xtensa_output_integer_literal_parts capable of handling literals of any
power of 2 size not less than 4.

2016-11-01  Max Filippov  
gcc/
* config/xtensa/xtensa.c (xtensa_output_integer_literal_parts):
New function.
(xtensa_output_literal): Use xtensa_output_integer_literal_parts
to format MODE_INT and MODE_PARTIAL_INT literals.
---
 gcc/config/xtensa/xtensa.c | 44 +++-
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index 2115b57..6e8a25d 100644
--- a/gcc/config/xtensa/xtensa.c
+++ b/gcc/config/xtensa/xtensa.c
@@ -2535,13 +2535,32 @@ xtensa_output_addr_const_extra (FILE *fp, rtx x)
   return false;
 }
 
+static void
+xtensa_output_integer_literal_parts (FILE *file, rtx x, int size)
+{
+  if (size > 4 && !(size & (size - 1)))
+{
+  rtx first, second;
+
+  split_double (x, , );
+  xtensa_output_integer_literal_parts (file, first, size / 2);
+  fputs (", ", file);
+  xtensa_output_integer_literal_parts (file, second, size / 2);
+}
+  else if (size == 4)
+{
+  output_addr_const (file, x);
+}
+  else
+{
+  gcc_unreachable();
+}
+}
 
 void
 xtensa_output_literal (FILE *file, rtx x, machine_mode mode, int labelno)
 {
   long value_long[2];
-  int size;
-  rtx first, second;
 
   fprintf (file, "\t.literal .LC%u, ", (unsigned) labelno);
 
@@ -2580,25 +2599,8 @@ xtensa_output_literal (FILE *file, rtx x, machine_mode 
mode, int labelno)
 
 case MODE_INT:
 case MODE_PARTIAL_INT:
-  size = GET_MODE_SIZE (mode);
-  switch (size)
-   {
-   case 4:
- output_addr_const (file, x);
- fputs ("\n", file);
- break;
-
-   case 8:
- split_double (x, , );
- output_addr_const (file, first);
- fputs (", ", file);
- output_addr_const (file, second);
- fputs ("\n", file);
- break;
-
-   default:
- gcc_unreachable ();
-   }
+  xtensa_output_integer_literal_parts (file, x, GET_MODE_SIZE (mode));
+  fputs ("\n", file);
   break;
 
 default:
-- 
2.1.4

Re: [PATCH] Emit DWARF5 DW_AT_reference and DW_AT_rvalue_reference

[Jason Merrill]

On Tue, Nov 1, 2016 at 2:04 PM, Jason Merrill  wrote:
> On Tue, Nov 1, 2016 at 9:56 AM, Jakub Jelinek  wrote:
>> On Mon, Oct 31, 2016 at 09:56:28AM -0400, Jason Merrill wrote:
>>> >Or by changing get_qualified_die (in particular check_base_type) to use a
>>> >langhook, we could at least for DW_AT_{reference,rvalue_reference} just use
>>> >equate_type_number_to_die/lookup_type_die reliably (DW_AT_endianity issue
>>> >remains).
>>>
>>> Yeah, I think that adding a langhook is the right way to go.  The generic
>>> code clobbering C++ qualifiers is a frequent headache.
>>
>> I've tried to implement that, but am getting some TYPE_CANONICAL differences
>> because of that, and am really lost what the problem is and how to fix it.
>> Furthermore, I bet the exception specification also should be considered in
>> that langhook.
>
> Yes.  I'll take a look.

This patch on top of yours passes regtest and seems to DTRT with your
testcase on brief inspection.
commit d11a8a96689cc81c71fc48b16653aff2227b6fff
Author: Jason Merrill 
Date:   Tue Nov 1 14:13:00 2016 -0400

fix

diff --git a/gcc/cp/cp-objcp-common.h b/gcc/cp/cp-objcp-common.h
index 986821d..0ef7e1e 100644
--- a/gcc/cp/cp-objcp-common.h
+++ b/gcc/cp/cp-objcp-common.h
@@ -135,8 +135,6 @@ extern void cp_common_init_ts (void);
 #define LANG_HOOKS_DECL_DWARF_ATTRIBUTE cp_decl_dwarf_attribute
 #undef LANG_HOOKS_TYPE_DWARF_ATTRIBUTE
 #define LANG_HOOKS_TYPE_DWARF_ATTRIBUTE cp_type_dwarf_attribute
-#undef LANG_HOOKS_CHECK_BASE_TYPE
-#define LANG_HOOKS_CHECK_BASE_TYPE cp_check_base_type
 #undef LANG_HOOKS_OMP_PREDETERMINED_SHARING
 #define LANG_HOOKS_OMP_PREDETERMINED_SHARING cxx_omp_predetermined_sharing
 #undef LANG_HOOKS_OMP_CLAUSE_DEFAULT_CTOR
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index ac15d67..4dc6e22 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1980,7 +1980,8 @@ static bool
 cp_check_qualified_type (const_tree cand, const_tree base, int type_quals,
 cp_ref_qualifier rqual, tree raises)
 {
-  return (check_qualified_type (cand, base, type_quals)
+  return (TYPE_QUALS (cand) == type_quals
+ && check_base_type (cand, base)
  && comp_except_specs (raises, TYPE_RAISES_EXCEPTIONS (cand),
ce_exact)
  && type_memfn_rqual (cand) == rqual);
@@ -4080,9 +4081,7 @@ cp_build_type_attribute_variant (tree type, tree 
attributes)
 }
 
 /* Return TRUE if TYPE1 and TYPE2 are identical for type hashing purposes.
-   Called only after doing all language independent checks.  Only
-   to check TYPE_RAISES_EXCEPTIONS for FUNCTION_TYPE, the rest is already
-   compared in type_hash_eq.  */
+   Called only after doing all language independent checks.  */
 
 bool
 cxx_type_hash_eq (const_tree typea, const_tree typeb)
@@ -4090,6 +4089,8 @@ cxx_type_hash_eq (const_tree typea, const_tree typeb)
   gcc_assert (TREE_CODE (typea) == FUNCTION_TYPE
  || TREE_CODE (typea) == METHOD_TYPE);
 
+  if (type_memfn_rqual (typea) != type_memfn_rqual (typeb))
+return false;
   return comp_except_specs (TYPE_RAISES_EXCEPTIONS (typea),
TYPE_RAISES_EXCEPTIONS (typeb), ce_exact);
 }
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index c823fdb..21b5380 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -12336,12 +12336,14 @@ modified_type_die (tree type, int cv_quals, bool 
reverse,
   if (TREE_CODE (type) == FUNCTION_TYPE
  || TREE_CODE (type) == METHOD_TYPE)
{
- /* For function/method types, can't use type_main_variant here,
+ /* For function/method types, can't just use type_main_variant here,
 because that can have different ref-qualifiers for C++,
 but try to canonicalize.  */
- for (tree t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
-   if (check_qualified_type (t, type, TYPE_QUALS (type)))
- type = t;
+ tree main = TYPE_MAIN_VARIANT (type);
+ for (tree t = main; t; t = TYPE_NEXT_VARIANT (t))
+   if (check_base_type (t, main)
+   && check_lang_type (t, type))
+ return lookup_type_die (t);
  return lookup_type_die (type);
}
   else if (TREE_CODE (type) != VECTOR_TYPE
diff --git a/gcc/hooks.c b/gcc/hooks.c
index 24f6c99..3995786 100644
--- a/gcc/hooks.c
+++ b/gcc/hooks.c
@@ -293,12 +293,6 @@ hook_bool_tree_tree_true (tree, tree)
 }
 
 bool
-hook_bool_const_tree_const_tree_true (const_tree, const_tree)
-{
-  return true;
-}
-
-bool
 hook_bool_tree_bool_false (tree, bool)
 {
   return false;
diff --git a/gcc/hooks.h b/gcc/hooks.h
index 7965603..a1d6776 100644
--- a/gcc/hooks.h
+++ b/gcc/hooks.h
@@ -59,7 +59,6 @@ extern bool hook_bool_rtx_mode_int_int_intp_bool_false (rtx, 
machine_mode,
int, int, int *, bool);
 extern bool hook_bool_tree_tree_false (tree, tree);
 extern bool 

Re: [patch, fortran] Fix PR 69544

[Dominique d'Humières]

gfortran regtested without regression with the patch

--- ../_clean/gcc/fortran/match.c   2016-11-01 17:24:32.0 +0100
+++ gcc/fortran/match.c 2016-11-01 16:21:31.0 +0100
@@ -6219,6 +6219,7 @@ match_simple_where (void)
 
   c->next = XCNEW (gfc_code);
   *c->next = new_st;
+  c->next->loc = gfc_current_locus;
   gfc_clear_new_st ();
 
   new_st.op = EXEC_WHERE;

Dominique

> Le 1 nov. 2016 à 18:15, Thomas Koenig  a écrit :
> 
> Hi Dominique,
> 
>> The patch fixes the ICE due to the missing gfc_current_locus in the
>> last one, but the same should be applied to match_simple_where,
>> otherwise one gets an ICE for statements such as
>> 
>> if (n==10) where (txt(1:3) /= ''   )  y(1:3,i,j) = txt(1:3)
> 
> I can confirm that the bug exists.  Because the obvious and simple fix
> caused a boatload of regressions for reasons I cannot yet understand, I
> have opened PR 78178 for the other test case, and committed the existing
> fix to trunk so far.
> 
> Am rebuilding my tree at the moment, maybe this will help.
> 
> Regards
> 
>   Thomas

[committed] hppa: Add new shift/add patterns

[John David Anglin]

The attached change fixes an obscure reload problem compiling hash.c in 
racket-6.7.  This occurs
when we to load the address of a DFmode MEM with a scaled-indexed address to 
integer registers.
Although we prefer ASHIFT to MULT, MULT is still used in memory addresses and 
we need to handle
this form either directly as an insn pattern or as a secondary reload.

Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11.  Committed to trunk 
and gcc-6 branch.

Dave
--
John David Anglin   dave.ang...@bell.net


2016-11-01  John David Anglin  

PR target/78166
* config/pa/pa.md: Add new shift/add patterns to handle
(plus (mult (reg) (mem_shadd_operand)) (reg)) source operand.

Index: config/pa/pa.md
===
--- config/pa/pa.md (revision 241690)
+++ config/pa/pa.md (working copy)
@@ -6249,6 +6249,21 @@
(set_attr "length" "4")])
 
 (define_insn ""
+  [(set (match_operand:SI 0 "register_operand" "=r")
+   (plus:SI (mult:SI (match_operand:SI 2 "register_operand" "r")
+ (match_operand:SI 3 "mem_shadd_operand" ""))
+(match_operand:SI 1 "register_operand" "r")))]
+  ""
+  "*
+{
+  int shift_val = exact_log2 (INTVAL (operands[3]));
+  operands[3] = GEN_INT (shift_val);
+  return \"{sh%o3addl %2,%1,%0|shladd,l %2,%o3,%1,%0}\";
+}"
+  [(set_attr "type" "binary")
+   (set_attr "length" "4")])
+
+(define_insn ""
   [(set (match_operand:DI 0 "register_operand" "=r")
(plus:DI (ashift:DI (match_operand:DI 2 "register_operand" "r")
(match_operand:DI 3 "shadd_operand" ""))
@@ -6258,6 +6273,21 @@
   [(set_attr "type" "binary")
(set_attr "length" "4")])
 
+(define_insn ""
+  [(set (match_operand:DI 0 "register_operand" "=r")
+   (plus:DI (mult:DI (match_operand:DI 2 "register_operand" "r")
+ (match_operand:DI 3 "mem_shadd_operand" ""))
+(match_operand:DI 1 "register_operand" "r")))]
+  "TARGET_64BIT"
+  "*
+{
+  int shift_val = exact_log2 (INTVAL (operands[3]));
+  operands[3] = GEN_INT (shift_val);
+  return \"shladd,l %2,%o3,%1,%0\";
+}"
+  [(set_attr "type" "binary")
+   (set_attr "length" "4")])
+
 (define_expand "ashlsi3"
   [(set (match_operand:SI 0 "register_operand" "")
(ashift:SI (match_operand:SI 1 "lhs_lshift_operand" "")

Re: [PATCH][AArch64] Add function comments to some prologue/epilogue helpers

[James Greenhalgh]

On Tue, Nov 01, 2016 at 10:49:10AM +, Jiong Wang wrote:
> >>>Is this ok for trunk?
> >>>
> >>>Thanks,
> >>>Kyrill
> >>>
> >>>2016-10-12  Kyrylo Tkachov  
> >>>
> >>>* config/aarch64/aarch64.c (aarch64_register_saved_on_entry): Add
> >>>function comment.
> >>>(aarch64_next_callee_save): Likewise.
> >>>(aarch64_pushwb_single_reg): Likewise.
> >>>(aarch64_gen_storewb_pair): Likewise.
> >>>(aarch64_push_regs): Likewise.
> >>>(aarch64_gen_loadwb_pair): Likewise.
> >>>(aarch64_pop_regs): Likewise.
> >>>(aarch64_gen_store_pair): Likewise.
> >>>(aarch64_gen_load_pair): Likewise.
> >>>(aarch64_save_callee_saves): Likewise.
> >>>(aarch64_restore_callee_saves): Likewise.
> 
> I "contributed" some of these functions without comments...
> The new added comments looks good to me though I can't approve.
> 
> Thanks for fixing these.

Thanks Jiong, I appreciate you taking the time to look.

This is OK based on Jiong's technical review and after a glance to ensure the
comments made sense to me.

Thanks,
James

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Bernd Edlinger]

On 11/01/16 18:11, Jason Merrill wrote:
> On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger
>  wrote:
>> On 11/01/16 16:20, Jason Merrill wrote:
>>> On 10/17/2016 03:18 PM, Bernd Edlinger wrote:
>>> I'm not even sure we need a new warning.  Can we combine this warning
>>> with the block that currently follows?
>>
>> After 20 years of not having a warning on that,
>> an implicitly enabled warning would at least break lots of bogus
>> test cases.
>
> Would it, though?  Which test cases still break with the current patch?
>

Less than before, but there are still at least a few of them.

I can make a list and send it tomorrow.

>> Of course in C we have an implicitly enabled warning,
>> so I would like to at least enable the warning on -Wall, thus
>> -Wshadow is too weak IMO.
>
> Right.  The -Wshadow warning is for file-local declarations, so that
> doesn't apply to your testcase; I was thinking that we should hit the
> first (currently unconditional) warning.
>
   else if ((DECL_EXTERN_C_P (newdecl)
 && DECL_EXTERN_C_P (olddecl))
|| compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
  TYPE_ARG_TYPES (TREE_TYPE (olddecl
>
> So I was thinking to drop the "else" and the compparms test.
>

Yes.  But then we must somehow avoid:

   else
 /* Discard the old built-in function.  */
 return NULL_TREE;

It maybe easier, just to copy the warning to the DECL_ANTICIPATED case?

 {
   /* A near match; override the builtin.  */

   if (TREE_PUBLIC (newdecl))
 warning_at (DECL_SOURCE_LOCATION (newdecl), 0,
 "new declaration %q#D ambiguates built-in "
 "declaration %q#D", newdecl, olddecl);
>
> So we would hit this warning.  And change the message to remove
> "ambiguates", since we're removing the compparms.
>
>> This started because I wanted to add builtin functions for some
>> special_function_p names.  And I wanted to warn the user if he uses a
>> name that is recognized by special_function_p, but the parameters
>> don't match.  Now I think we need to teach special_function_p to
>> distinguish "C" functions from "C++" functions, which it currently
>> cannot do, because that knowledge is only in the C++ FE.
>
> It could look at DECL_ASSEMBLER_NAME rather than DECL_NAME?
>

Yes.  I think previously special_function_p must have used the
DECL_ASSEMBLER_NAME, at least the comments still mention that.

Also for a "C" function there are target specific naming rules,
some prepend an underscore, some don't, and more, especially
W..DOS has special conventions IIRC.

Maybe a language callback would be good to have for this task.
So that special_function_p can easily check if something is a
C++ function, then it is immediately clear that it is not a
special function.



Bernd.

Re: [PATCH][AArch64] Cleanup add expander

[James Greenhalgh]

On Mon, Oct 24, 2016 at 04:19:47PM +, Wilco Dijkstra wrote:
> The add expander still contains some expansion code that was required for the
> previous prolog/epilog code, but which is no longer needed.  I also noticed 
> that
> the current version splits off immediates from frame addressing instructions,
> which doesn't seem a good idea.  Avoiding this resulted in small codesize 
> improvements.


OK, but...

> ChangeLog:
> 2016-10-24  Wilco Dijkstra  
> 
> gcc/
>   * config/aarch64/aarch64.md (add3): Remove
>   redundant code.  Don't split frame based additions.


> +  /* If the constant is too large for a single instruction and isn't frame
> + based, split off the immediate so it is available for CSE.  */
> +  if (!aarch64_plus_immediate (operands[2], mode)
> +  && can_create_pseudo_p () && !REGNO_PTR_FRAME_P (REGNO (operands[1])))

Split the second && on to a newline:

> +  if (!aarch64_plus_immediate (operands[2], mode)
> +  && can_create_pseudo_p ()
> +  && !REGNO_PTR_FRAME_P (REGNO (operands[1])))

As so.

Thanks,
James

Re: [PATCH 5/5] [AARCH64] Add variant support to -m="native"and add thunderxt88p1.

[Andrew Pinski]

On Tue, Nov 17, 2015 at 2:10 PM, Andrew Pinski  wrote:
> Since ThunderX T88 pass 1 (variant 0) is a ARMv8 part while pass 2 (variant 1)
> is an ARMv8.1 part, I needed to add detecting of the variant also for this
> difference. Also I simplify a little bit and combined the single core and
> arch detecting cases so it would be easier to add variant.

Actually it is a bit more complex than what I said here, see below for
the full table of options and what are enabled/disabled now.

> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> Tested -mcpu=native on both T88 pass 1 and T88 pass 2 to make sure it is
> deecting the two seperately.


Here is the final patch in this series updated; I changed the cpu name
slightly and made sure I updated invoke.texi too.

The names are going to match the names in LLVM (worked with our LLVM
engineer here at Cavium about the names).
Here are the names recorded and
-mpcu=thunderx:
*Matches part num 0xA0 (reserved for ThunderX 8x series)
*T88 Pass 2 scheduling
*Hardware prefetching (software prefetching disabled)
*LSE enabled
*no v8.1

-mcpu=thunderxt88:
*Matches part num 0xA1
*T88 Pass 2 scheduling
*software prefetching enabled
*LSE enabled
*no v8.1

-mcpu=thunderxt88p1 (only for GCC):
*Matches part num 0xA1, variant 0
*T88 Pass 1 scheduling
*software prefetching enabled
*no LSE enabled
*no v8.1

-mcpu=thunderxt81 and -mcpu=thunderxt83:
*Matches part num 0xA2/0xA3
*T88 Pass 2 scheduling
*Hardware prefetching (software prefetching disabled)
*LSE enabled
*v8.1


I have not hooked up software vs hardware prefetching and the
scheduler parts (the next patch will do part of that); both ARMv8.1-a
and LSE parts are hooked up as those parts are only in
aarch64-cores.def.

OK?  Bootstrapped and tested on ThunderX T88 and ThunderX T81
(aarch64-linux-gnu).

Thanks,
Andrew Pinski

* config/aarch64/aarch64-cores.def: Add -1 as the variant to all of the cores.
(thunderx): Update to include LSE by default.
(thunderxt88p1): New core.
(thunderxt88): New core.
(thunderxt81): New core.
(thunderxt83): New core.
* config/aarch64/driver-aarch64.c (struct aarch64_core_data): Add variant field.
(ALL_VARIANTS): New define.
(AARCH64_CORE): Support VARIANT operand.
(cpu_data): Likewise.
(host_detect_local_cpu): Parse variant field of /proc/cpuinfo.  Combine the arch
and single core case and support variant searching.
* common/config/aarch64/aarch64-common.c (AARCH64_CORE): Add VARIANT operand.
* config/aarch64/aarch64-opts.h (AARCH64_CORE): Likewise.
* config/aarch64/aarch64.c (AARCH64_CORE): Likewise.
* config/aarch64/aarch64.h (AARCH64_CORE): Likewise.
* config/aarch64/aarch64-tune.md: Regenerate.

* doc/invoke.texi (AARCH64/mtune): Document thunderxt88,
thunderxt88p1, thunderxt81, thunderxt83 as available options.


>
> Thanks,
> Andrew Pinski
>
>
> * config/aarch64/aarch64-cores.def: Add -1 as the variant to all of the cores.
> (thunderxt88pass1): New core.
> * config/aarch64/driver-aarch64.c (struct aarch64_core_data): Add variant 
> field.
> (ALL_VARIANTS): New define.
> (AARCH64_CORE): Support VARIANT operand.
> (cpu_data): Likewise.
> (host_detect_local_cpu): Parse variant field of /proc/cpuinfo.  Combine the 
> arch
> and single core case and support variant searching.
> * common/config/aarch64/aarch64-common.c (AARCH64_CORE): Add VARIANT operand.
> * config/aarch64/aarch64-opts.h (AARCH64_CORE): Likewise.
> * config/aarch64/aarch64.c (AARCH64_CORE): Likewise.
> * config/aarch64/aarch64.h (AARCH64_CORE): Likewise.
> * config/aarch64/aarch64-tune.md: Regernate.
> ---
>  gcc/common/config/aarch64/aarch64-common.c |  2 +-
>  gcc/config/aarch64/aarch64-cores.def   | 27 ++-
>  gcc/config/aarch64/aarch64-opts.h  |  2 +-
>  gcc/config/aarch64/aarch64-tune.md |  2 +-
>  gcc/config/aarch64/aarch64.c   |  2 +-
>  gcc/config/aarch64/aarch64.h   |  2 +-
>  gcc/config/aarch64/driver-aarch64.c| 78 
> --
>  7 files changed, 64 insertions(+), 51 deletions(-)
>
> diff --git a/gcc/common/config/aarch64/aarch64-common.c 
> b/gcc/common/config/aarch64/aarch64-common.c
> index e312bbc..f6fd7e7 100644
> --- a/gcc/common/config/aarch64/aarch64-common.c
> +++ b/gcc/common/config/aarch64/aarch64-common.c
> @@ -141,7 +141,7 @@ struct arch_to_arch_name
> the default set of architectural feature flags they support.  */
>  static const struct processor_name_to_arch all_cores[] =
>  {
> -#define AARCH64_CORE(NAME, X, IDENT, ARCH_IDENT, FLAGS, COSTS, IMP, PART) \
> +#define AARCH64_CORE(NAME, X, IDENT, ARCH_IDENT, FLAGS, COSTS, IMP, PART, 
> VARIANT) \
>{NAME, AARCH64_ARCH_##ARCH_IDENT, FLAGS},
>  #include "config/aarch64/aarch64-cores.def"
>{"generic", AARCH64_ARCH_8A, AARCH64_FL_FOR_ARCH8},
> diff --git 

Re: [PATCH, testsuite]: Cleanup lib/target-supports.exp, ...

[Uros Bizjak]

On Tue, Nov 1, 2016 at 5:05 PM, Jakub Jelinek  wrote:
> On Tue, Nov 01, 2016 at 10:05:22AM +0100, Uros Bizjak wrote:
>> ... simplify some conditions and add i?86-*-* target where missing.
>>
>> 2016-11-01  Uros Bizjak  
>>
>> * lib/target-supports.exp: Normalize order of i?86 and x86_64 targets.
>> Whitespace fixes.
> ...
>> (check_effective_target_divmod): Add i?86-*-* target.
>
> This part likely broke
> +FAIL: gcc.dg/divmod-1.c scan-tree-dump-times widening_mul "DIVMOD" 7
> +FAIL: gcc.dg/divmod-2.c scan-tree-dump-times widening_mul "DIVMOD" 7
> +FAIL: gcc.dg/divmod-3.c scan-tree-dump-times widening_mul "DIVMOD" 7
> +FAIL: gcc.dg/divmod-4.c scan-tree-dump-times widening_mul "DIVMOD" 7
> +FAIL: gcc.dg/divmod-6.c scan-tree-dump-times widening_mul "DIVMOD" 7
> on i686-linux (i.e. 32-bit).

No, this is expected (these tests already fail with x86_64 -m32
multilib). These will be fixed by [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02483.html

Uros.

> Dunno what exactly the tests are meant to test, most likely they just
> need extra guards or something.  Can be reproduced even on x86_64-linux
> with
> make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp=divmod*'
>
>> @@ -8110,7 +8090,7 @@
>>  #TODO: Add checks for all targets that have either hardware divmod insn
>>  # or define libfunc for divmod.
>>  if { [istarget arm*-*-*]
>> -  || [istarget x86_64-*-*] } {
>> +  || [istarget i?86-*-*] || [istarget x86_64-*-*] } {
>>   return 1
>>  }
>>  return 0
>
>
> Jakub

Re: [PATCH] Emit DWARF5 DW_AT_reference and DW_AT_rvalue_reference

[Jason Merrill]

On Tue, Nov 1, 2016 at 9:56 AM, Jakub Jelinek  wrote:
> On Mon, Oct 31, 2016 at 09:56:28AM -0400, Jason Merrill wrote:
>> >Or by changing get_qualified_die (in particular check_base_type) to use a
>> >langhook, we could at least for DW_AT_{reference,rvalue_reference} just use
>> >equate_type_number_to_die/lookup_type_die reliably (DW_AT_endianity issue
>> >remains).
>>
>> Yeah, I think that adding a langhook is the right way to go.  The generic
>> code clobbering C++ qualifiers is a frequent headache.
>
> I've tried to implement that, but am getting some TYPE_CANONICAL differences
> because of that, and am really lost what the problem is and how to fix it.
> Furthermore, I bet the exception specification also should be considered in
> that langhook.

Yes.  I'll take a look.

Jason

[RFC][PATCH] Remove a bad use of SLOW_UNALIGNED_ACCESS

[Wilco Dijkstra]

Looking at PR77308, one of the issues is that the bswap optimization 
phase doesn't work on ARM.  This is due to an odd check that uses
SLOW_UNALIGNED_ACCESS (which is always true on ARM).  Since the testcase
in PR77308 generates much better code with this patch (~13% fewer
instructions), it seems best to remove this odd check.

This exposes a problem with SLOW_UNALIGNED_ACCESS - what is it supposed
to mean or do? According to its current definition, it means we should
never emit an unaligned access for a given mode as it would lead to a
trap.  However that is not what happens, for example all integer modes on
ARM support really fast unaligned access and we generate unaligned instructions
without any issues.  Some Thumb-1 targets automatically expand unaligned
accesses if necessary.  So this macro clearly doesn't stop unaligned accesses
from being generated.

So I want to set it to false for most modes on ARM as they are not slow. 
However doing so causes incorrect code generation and unaligned traps.
How can we differentiate between modes that support fast unaligned access
in hardware, modes that get expanded and modes that should never be used in
an unaligned access?

Bootstrap & regress OK.

ChangeLog:
2015-11-01  Wilco Dijkstra  

gcc/
* tree-ssa-math-opts.c (bswap_replace): Remove test
of SLOW_UNALIGNED_ACCESS.

testsuite/
* gcc.dg/optimize-bswapdi-3.c: Remove xfail.
* gcc.dg/optimize-bswaphi-1.c: Likewise.
* gcc.dg/optimize-bswapsi-2.c: Likewise.

--

diff --git a/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c 
b/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c
index 
273b4bc622cb32564533e1352b5fc8ad52054f8b..6f682014622ab79e541cdf26d13f16a7d87f158d
 100644
--- a/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c
+++ b/gcc/testsuite/gcc.dg/optimize-bswapdi-3.c
@@ -61,4 +61,4 @@ uint64_t read_be64_3 (unsigned char *data)
 }
 
 /* { dg-final { scan-tree-dump-times "64 bit load in target endianness found 
at" 3 "bswap" } } */
-/* { dg-final { scan-tree-dump-times "64 bit bswap implementation found at" 3 
"bswap" { xfail alpha*-*-* arm*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "64 bit bswap implementation found at" 3 
"bswap" } } */
diff --git a/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c 
b/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c
index 
c18ca6174d12a786a71252dfe47cfe78ca58750a..852ccfe5c1acd519f2cf340cc55f3ea74b1ec21f
 100644
--- a/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c
+++ b/gcc/testsuite/gcc.dg/optimize-bswaphi-1.c
@@ -55,5 +55,4 @@ swap16 (HItype in)
 }
 
 /* { dg-final { scan-tree-dump-times "16 bit load in target endianness found 
at" 3 "bswap" } } */
-/* { dg-final { scan-tree-dump-times "16 bit bswap implementation found at" 1 
"bswap" { target alpha*-*-* arm*-*-* } } } */
-/* { dg-final { scan-tree-dump-times "16 bit bswap implementation found at" 4 
"bswap" { xfail alpha*-*-* arm*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "16 bit bswap implementation found at" 4 
"bswap" } } */
diff --git a/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c 
b/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c
index 
a1558af2cc74adde439d42223b00977d9eeb9639..01ae3776ed3f44fbc300d001f8c67ec11625d03b
 100644
--- a/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c
+++ b/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c
@@ -45,4 +45,4 @@ uint32_t read_be32_3 (unsigned char *data)
 }
 
 /* { dg-final { scan-tree-dump-times "32 bit load in target endianness found 
at" 3 "bswap" } } */
-/* { dg-final { scan-tree-dump-times "32 bit bswap implementation found at" 3 
"bswap" { xfail alpha*-*-* arm*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "32 bit bswap implementation found at" 3 
"bswap" } } */
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index 
0cea1a8472d5d9c4f0e4a7bd82930e201948c4ec..cbb2f9367a287ad8cfcfc5740c0e49b2c83bafd0
 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -2651,11 +2651,6 @@ bswap_replace (gimple *cur_stmt, gimple *src_stmt, tree 
fndecl,
}
}
 
-  if (bswap
- && align < GET_MODE_ALIGNMENT (TYPE_MODE (load_type))
- && SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align))
-   return false;
-
   /* Move cur_stmt just before  one of the load of the original
 to ensure it has the same VUSE.  See PR61517 for what could
 go wrong.  */

Re: [PATCH] Emit DW_AT_inline for C++17 inline variables (take 2)

[Jason Merrill]

On Tue, Nov 1, 2016 at 12:10 PM, Jakub Jelinek  wrote:
> + && !get_AT (var_die, DW_AT_inline)
> + && (origin_die == NULL || get_AT (origin_die, DW_AT_inline) == NULL)

Can we drop this repetition (here and for DW_AT_const_expr)?  get_AT
should look through DW_AT_abstract_origin, and we should have added
that earlier in gen_variable_die.

OK with that change.

Jason

Re: [PATCH] xtensa: Fix PR target/78118

[Max Filippov]

On Tue, Nov 1, 2016 at 9:28 AM, augustine.sterl...@gmail.com
 wrote:
> On Mon, Oct 31, 2016 at 11:32 PM, Max Filippov  wrote:
>> 2016-10-26  Max Filippov  
>> gcc/
>> * config/xtensa/xtensa-protos.h
>> (xtensa_use_return_instruction_p): New prototype.
>> * config/xtensa/xtensa.c (xtensa_current_frame_size,
>> xtensa_callee_save_size): Remove.
>> (struct machine_function): Add new fields: current_frame_size,
>> callee_save_size, frame_laid_out and epilogue_done.
>> (compute_frame_size, xtensa_expand_prologue,
>> xtensa_expand_epilogue): Replace xtensa_callee_save_size with
>> cfun->machine->callee_save_size and xtensa_current_frame_size
>> with cfun->machine->current_frame_size.
>> (compute_frame_size): Update cfun->machine->frame_laid_out and
>> don't update frame layout after reload completion.
>> (xtensa_expand_epilogue): Set cfun->machine->epilogue_done
>> instead of zeroing xtensa_current_frame_size.
>> (xtensa_use_return_instruction_p): New function.
>> * config/xtensa/xtensa.h (xtensa_current_frame_size): Remove
>> declaration.
>> (INITIAL_ELIMINATION_OFFSET): Use return value of
>> compute_frame_size instead of xtensa_current_frame_size value.
>> * config/xtensa/xtensa.md ("return" pattern): Use new predicate
>> function xtensa_use_return_instruction_p instead of inline code.
>
> Approved. Please apply.

Applied to trunk. Thank you!

-- Max

Re: [patch, fortran] Fix PR 69544

[Thomas Koenig]

Hi Dominique,


 The patch fixes the ICE due to the missing gfc_current_locus in the
last one, but the same should be applied to match_simple_where,
otherwise one gets an ICE for statements such as

if (n==10) where (txt(1:3) /= ''   )  y(1:3,i,j) = txt(1:3)


I can confirm that the bug exists.  Because the obvious and simple fix
caused a boatload of regressions for reasons I cannot yet understand, I
have opened PR 78178 for the other test case, and committed the existing
fix to trunk so far.

Am rebuilding my tree at the moment, maybe this will help.

Regards

Thomas

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

[Jason Merrill]

On Tue, Nov 1, 2016 at 1:02 PM, Jiong Wang  wrote:
> Besides this issue, do you think the PARALLEL + UNSPEC based approach to
> represent DWARF RAW expression is acceptable?

Yes.

Jason

[PATCH][ARM][2/2] Remove old rtx costs

[Kyrill Tkachov]

Hi all,

This is the big removal patch that removes the old costs functions, the 
function pointer
field in tune_params, and the transitional options -mold-rtx-costs and 
-mnew-generic-costs.
The diff stats come in at:
3 files changed, 61 insertions(+), 1275 deletions(-)

Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk?

Thanks,
Kyrill

2016-11-01  Kyrylo Tkachov  

* config/arm/arm.opt (mold-rtx-costs): Delete.
(mnew-generic-costs): Delete.
* config/arm/arm-protos.h (struct tune_params): Delete rtx_costs field.
* config/arm/arm.c (arm_rtx_costs_1): Delete.
(arm_size_rtx_costs): Likewise.
(arm_slowmul_rtx_costs): Likewise.
(arm_fastmul_rtx_costs): Likewise.
(arm_xscale_rtx_costs): Likewise.
(arm_9e_rtx_costs): Likewise.
(arm_slowmul_tune, arm_fastmul_tune, arm_strongarm_tune,
arm_xscale_tune, arm_9e_tune, arm_v6t2_tune, arm_cortex_tune,
arm_cortex_a8_tune, arm_cortex_a7_tune, arm_cortex_a15_tune,
arm_cortex_a53_tune, arm_cortex_a57_tune, arm_cortex_a9_tune,
arm_cortex_a12_tune, arm_v7m_tune, arm_v6m_tune, arm_fa726te_tune
arm_cortex_a5_tune, arm_xgene1_tune, arm_marvell_pj4_tune,
arm_cortex_a35_tune, arm_exynosm1_tune, arm_cortex_a73_tune,
arm_cortex_m7_tune):
Delete rtx_costs field.
(arm_new_rtx_costs): Rename to...
(arm_rtx_costs_internal): ... This.
(arm_rtx_costs): Remove old way of doing rtx costs.
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 374836cbdd52533237b81903c602117dc10ada22..9e0427720487549b99429c816e02295e72f8713a 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -260,7 +260,6 @@ struct cpu_cost_table;
 
 struct tune_params
 {
-  bool (*rtx_costs) (rtx, RTX_CODE, RTX_CODE, int *, bool);
   const struct cpu_cost_table *insn_extra_cost;
   bool (*sched_adjust_cost) (rtx_insn *, int, rtx_insn *, int *);
   int (*branch_cost) (bool, bool);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 6bc588f7993979659ffe69646d8606f0f72cf608..f4a91e08c496f419742f3bd90ebf31b1b195c090 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -163,12 +163,6 @@ static void arm_output_mi_thunk (FILE *, tree, HOST_WIDE_INT, HOST_WIDE_INT,
 static bool arm_have_conditional_execution (void);
 static bool arm_cannot_force_const_mem (machine_mode, rtx);
 static bool arm_legitimate_constant_p (machine_mode, rtx);
-static bool arm_rtx_costs_1 (rtx, enum rtx_code, int*, bool);
-static bool arm_size_rtx_costs (rtx, enum rtx_code, enum rtx_code, int *);
-static bool arm_slowmul_rtx_costs (rtx, enum rtx_code, enum rtx_code, int *, bool);
-static bool arm_fastmul_rtx_costs (rtx, enum rtx_code, enum rtx_code, int *, bool);
-static bool arm_xscale_rtx_costs (rtx, enum rtx_code, enum rtx_code, int *, bool);
-static bool arm_9e_rtx_costs (rtx, enum rtx_code, enum rtx_code, int *, bool);
 static bool arm_rtx_costs (rtx, machine_mode, int, int, int *, bool);
 static int arm_address_cost (rtx, machine_mode, addr_space_t, bool);
 static int arm_register_move_cost (machine_mode, reg_class_t, reg_class_t);
@@ -1681,7 +1675,6 @@ const struct cpu_cost_table v7m_extra_costs =
 
 const struct tune_params arm_slowmul_tune =
 {
-  arm_slowmul_rtx_costs,
   _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
@@ -1704,7 +1697,6 @@ const struct tune_params arm_slowmul_tune =
 
 const struct tune_params arm_fastmul_tune =
 {
-  arm_fastmul_rtx_costs,
   _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
@@ -1730,7 +1722,6 @@ const struct tune_params arm_fastmul_tune =
 
 const struct tune_params arm_strongarm_tune =
 {
-  arm_fastmul_rtx_costs,
   _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
@@ -1753,7 +1744,6 @@ const struct tune_params arm_strongarm_tune =
 
 const struct tune_params arm_xscale_tune =
 {
-  arm_xscale_rtx_costs,
   _extra_costs,			/* Insn extra costs.  */
   xscale_sched_adjust_cost,
   arm_default_branch_cost,
@@ -1776,7 +1766,6 @@ const struct tune_params arm_xscale_tune =
 
 const struct tune_params arm_9e_tune =
 {
-  arm_9e_rtx_costs,
   _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
@@ -1799,7 +1788,6 @@ const struct tune_params arm_9e_tune =
 
 const struct tune_params arm_marvell_pj4_tune =
 {
-  arm_9e_rtx_costs,
   _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
@@ -1822,7 +1810,6 @@ const struct tune_params arm_marvell_pj4_tune =
 
 const struct tune_params arm_v6t2_tune =
 {
-  arm_9e_rtx_costs,
   _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
@@ -1847,7 +1834,6 @@ const struct tune_params arm_v6t2_tune =
 /* Generic Cortex tuning.  Use more specific tunings if appropriate.  

[PATCH][ARM][1/2] Use generic_extra_costs in all remaining tuning structs

[Kyrill Tkachov]

Hi all,

This is the first of two patches to do away with the transitional 
-mold-rtx-costs option and finalise
the transition to the table-based RTX costs approach.

This first patch switches the remaining tuning structs to use 
generic_extra_costs so that the 2nd
patch can remove the rtx_costs function pointer in tune_params. This 
essentially makes the transitional
option -mnew-generic-costs the default (though it will be removed in the second 
patch).

Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk?

Thanks,
Kyrill

2016-11-01  Kyrylo Tkachov  kyrylo.tkac...@arm.com

* config/arm/arm.c (arm_slowmul_tune): Use generic_extra_costs.
(arm_fastmul_tune): Likewise.
(arm_strongarm_tune): Likewise.
(arm_xscale_tune): Likewise.
(arm_9e_tune): Likewise.
(arm_marvell_pj4_tune): Likewise.
(arm_v6t2_tune): Likewise.
(arm_v6m_tune): Likewise.
(arm_fa726te_tune): Likewise.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 74c4041a5f5173714dec36a3ad37b8b63cd5cc49..6bc588f7993979659ffe69646d8606f0f72cf608 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -1682,7 +1682,7 @@ const struct cpu_cost_table v7m_extra_costs =
 const struct tune_params arm_slowmul_tune =
 {
   arm_slowmul_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
   _default_vec_cost,
@@ -1705,7 +1705,7 @@ const struct tune_params arm_slowmul_tune =
 const struct tune_params arm_fastmul_tune =
 {
   arm_fastmul_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
   _default_vec_cost,
@@ -1731,7 +1731,7 @@ const struct tune_params arm_fastmul_tune =
 const struct tune_params arm_strongarm_tune =
 {
   arm_fastmul_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
   _default_vec_cost,
@@ -1754,7 +1754,7 @@ const struct tune_params arm_strongarm_tune =
 const struct tune_params arm_xscale_tune =
 {
   arm_xscale_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   xscale_sched_adjust_cost,
   arm_default_branch_cost,
   _default_vec_cost,
@@ -1777,7 +1777,7 @@ const struct tune_params arm_xscale_tune =
 const struct tune_params arm_9e_tune =
 {
   arm_9e_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
   _default_vec_cost,
@@ -1800,7 +1800,7 @@ const struct tune_params arm_9e_tune =
 const struct tune_params arm_marvell_pj4_tune =
 {
   arm_9e_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
   _default_vec_cost,
@@ -1823,7 +1823,7 @@ const struct tune_params arm_marvell_pj4_tune =
 const struct tune_params arm_v6t2_tune =
 {
   arm_9e_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
   _default_vec_cost,
@@ -2230,7 +2230,7 @@ const struct tune_params arm_cortex_m7_tune =
 const struct tune_params arm_v6m_tune =
 {
   arm_9e_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,			/* Insn extra costs.  */
   NULL,	/* Sched adj cost.  */
   arm_default_branch_cost,
   _default_vec_cost,/* Vectorizer costs.  */
@@ -2253,7 +2253,7 @@ const struct tune_params arm_v6m_tune =
 const struct tune_params arm_fa726te_tune =
 {
   arm_9e_rtx_costs,
-  NULL,	/* Insn extra costs.  */
+  _extra_costs,/* Insn extra costs.  */
   fa726te_sched_adjust_cost,
   arm_default_branch_cost,
   _default_vec_cost,

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Jason Merrill]

On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger
 wrote:
> On 11/01/16 16:20, Jason Merrill wrote:
>> On 10/17/2016 03:18 PM, Bernd Edlinger wrote:
>> I'm not even sure we need a new warning.  Can we combine this warning
>> with the block that currently follows?
>
> After 20 years of not having a warning on that,
> an implicitly enabled warning would at least break lots of bogus
> test cases.

Would it, though?  Which test cases still break with the current patch?

> Of course in C we have an implicitly enabled warning,
> so I would like to at least enable the warning on -Wall, thus
> -Wshadow is too weak IMO.

Right.  The -Wshadow warning is for file-local declarations, so that
doesn't apply to your testcase; I was thinking that we should hit the
first (currently unconditional) warning.

>>>   else if ((DECL_EXTERN_C_P (newdecl)
>>> && DECL_EXTERN_C_P (olddecl))
>>>|| compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
>>>  TYPE_ARG_TYPES (TREE_TYPE (olddecl

So I was thinking to drop the "else" and the compparms test.

>>> {
>>>   /* A near match; override the builtin.  */
>>>
>>>   if (TREE_PUBLIC (newdecl))
>>> warning_at (DECL_SOURCE_LOCATION (newdecl), 0,
>>> "new declaration %q#D ambiguates built-in "
>>> "declaration %q#D", newdecl, olddecl);

So we would hit this warning.  And change the message to remove
"ambiguates", since we're removing the compparms.

> This started because I wanted to add builtin functions for some
> special_function_p names.  And I wanted to warn the user if he uses a
> name that is recognized by special_function_p, but the parameters
> don't match.  Now I think we need to teach special_function_p to
> distinguish "C" functions from "C++" functions, which it currently
> cannot do, because that knowledge is only in the C++ FE.

It could look at DECL_ASSEMBLER_NAME rather than DECL_NAME?

Jason

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

[Jiong Wang]

On 01/11/16 16:48, Jason Merrill wrote:

On Tue, Nov 1, 2016 at 11:59 AM, Jiong Wang  wrote:

On 01/11/16 15:24, Jason Merrill wrote:

On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang  wrote:

On 31/10/16 19:50, Jason Merrill wrote:

On 10/21/2016 04:30 AM, Jiong Wang wrote:

All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't have RTL mapping are wrapped by
UNSPEC.  The parsing algorithm is simply something like:

foreach elem inside PARALLEL
  if (UNSPEC)
{
  dw_op_code = INTVAL (XVECEXP (elem, 0, 0));
  oprnd1 = INTVAL (XVECEXP (elem, 0, 1));
  oprnd2 = INTVAL (XVECEXP (elem, 0, 2));
}
  else
call standard RTL parser.

Any comments on the approach?

If you're going to use UNSPEC, why not put the DWARF operator in the
second operand?

Thanks for the review, but I still don't understand your meaning.

Do you mean I should simply put the DWARF operator at XVECEXP
(UNSPEC_RTX, 0, 2) instead of at XVECEXP (UNSPEC_RTX, 0, 0)

No, at XINT (UNSPEC_RTX, 1).  The documentation of UNSPEC says,

/* A machine-specific operation.
 1st operand is a vector of operands being used by the operation so
that any needed reloads can be done.
 2nd operand is a unique value saying which of a number of
machine-specific operations is to be performed.

Aha, understood now, thanks for the clarification.

You mean we simply reuse the UNSPEC number field, so the RTX will be

   (UNSPEC
  [((reg) (reg)]
DW_OP_XXX)

Yeah, I do have tried to do that, but later give up, one reason I remember is 
suppose we
want to push two value on the stack, the second value is an address, which we 
want a
follow up DW_OP_deref to operate on that. then the value expression will be

(set (reg A)
 (parallel
   [(reg A)

 (UNSPEC
   [DW_OP_deref, const0_rtx, const0_rtx]
 UNSPEC_PRIVATE_DW);

(UNSPEC
  [DW_OP_XXX (const0_rtx) (const0_rtx)]
 UNSPEC_PRIVATE_DW))

And there might be some other expressions we need some complex RAW encoding,

Why can't you do this putting the OP in the number field of both UNSPECs?


I was demoing the RTX based on my current approach, and simplfy want to 
say we only need to
define one unspec number (UNSPEC_PRIVATE_DW), while if we putting the OP 
in the number field
of both UNSPECs, we need two unspec number, and we might need more for 
other similar expressions.


If we don't need to worry about the conflicts, then your suggestion is 
definitely better.  I will do more tests

on this.

Besides this issue, do you think the PARALLEL + UNSPEC based approach to 
represent DWARF RAW expression is acceptable?


Thanks.

Regards,
Jiong




so it seems to me if we want to offer user the most general way to do this, 
then it's
better to encode the DWARF operation inside UNSPEC as reuse the UNSPEC number 
then you need to make
sure there is no overlap with other backend UNSPEC enumeration number.

It seems to me that a CFA_*expression note would never use target
UNSPEC codes, and a DWARF UNSPEC would never appear outside of such a
note, so we don't need to worry about conflicts.

Jason

[committed] Fix up libgomp/hashtab.h license

[Jakub Jelinek]

Hi!

libgomp is GPLv3 + runtime exception licensed, hashtab.h has been copied
and adjusted from include/ similarly how splay-tree.c has been changed,
the latter got the GPLv3 + runtime exception boiler plate, but not
hashtab.h.

Fixed thusly, committed to trunk.  Shall I backport to release branches?

2016-11-01  Jakub Jelinek  

* hashtab.h: Use standard GPLv3 with runtime exception
boilerplate.

--- libgomp/hashtab.h   (revision 241744)
+++ libgomp/hashtab.h   (working copy)
@@ -2,19 +2,27 @@
Copyright (C) 1999-2016 Free Software Foundation, Inc.
Contributed by Vladimir Makarov .
 
-This program is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This program is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this program; if not, write to the Free Software
-Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, 
USA.  */
+   This file is part of the GNU Offloading and Multi Processing Library
+   (libgomp).
+
+   Libgomp is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   Libgomp is distributed in the hope that it will be useful, but WITHOUT ANY
+   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+   FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+   more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
 
 /* The hash table code copied from include/hashtab.[hc] and adjusted,
so that the hash table entries are in the flexible array at the end

Jakub

Re: [PATCH] DWARF5 .debug_rnglists support

[Jason Merrill]

On Tue, Nov 1, 2016 at 12:14 PM, Jakub Jelinek  wrote:
> On Mon, Oct 31, 2016 at 05:03:12PM -0400, Jason Merrill wrote:
>> > Ok.  Another option would be to call value_format in size_of_die
>> > in this case and put the comment into value_format.
>>
>> That works, too.
>
> Done.
>>
>> >> In general there's a lot of code duplication between the existing ranges
>> >> support and the new rnglist support; even the new vector is a superset of
>> >> the old one.  Why duplicate the code rather than modify it?
>> >
>> > The point was to conserve memory for the -gdwarf-{2,3,4} case.
>> > The old table needs just 4 bytes per entry, the new one 16 bytes per entry.
>> > The code duplication because of that is mainly in
>> > add_high_low_attributes - 24 lines duplicated.
>>
>> I was also thinking of the output_rnglists function.
>
> I'm afraid there is nothing that can be shared between output_ranges and
> output_rnglists, except for
>   FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)
> {
>   int block_num = r->num;
> and
>   if (block_num > 0)
> {
>   char blabel[MAX_ARTIFICIAL_LABEL_BYTES];
>   char elabel[MAX_ARTIFICIAL_LABEL_BYTES];
>
>   ASM_GENERATE_INTERNAL_LABEL (blabel, BLOCK_BEGIN_LABEL, block_num);
>   ASM_GENERATE_INTERNAL_LABEL (elabel, BLOCK_END_LABEL, block_num);
> so I'd prefer to keep them separate instead of having one function with
> various dwarf_version >= 5 checks (at least 4).
>
>>
>> > At least while -gdwarf-4 is the default that looked to me like acceptable
>> > cost, but if you disagree, I can surely try to just grow the original
>> > table and use it for all versions.
>>
>> Please.  I think if we're going in this direction we should just go
>> ahead with it; if the memory consumption is going to be a problem it
>> would be good to find that out so we can address it.
>
> Here it is.  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

OK.

Jason

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

[Jason Merrill]

On Tue, Nov 1, 2016 at 11:59 AM, Jiong Wang  wrote:
> On 01/11/16 15:24, Jason Merrill wrote:
>> On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang  wrote:
>>> On 31/10/16 19:50, Jason Merrill wrote:
 On 10/21/2016 04:30 AM, Jiong Wang wrote:
>
> All DW_OP_* of the expression are grouped together inside the PARALLEL,
> and those operations which don't have RTL mapping are wrapped by
> UNSPEC.  The parsing algorithm is simply something like:
>
>foreach elem inside PARALLEL
>  if (UNSPEC)
>{
>  dw_op_code = INTVAL (XVECEXP (elem, 0, 0));
>  oprnd1 = INTVAL (XVECEXP (elem, 0, 1));
>  oprnd2 = INTVAL (XVECEXP (elem, 0, 2));
>}
>  else
>call standard RTL parser.
>
> Any comments on the approach?

 If you're going to use UNSPEC, why not put the DWARF operator in the
 second operand?
>>>
>>>Thanks for the review, but I still don't understand your meaning.
>>>
>>>Do you mean I should simply put the DWARF operator at XVECEXP
>>> (UNSPEC_RTX, 0, 2) instead of at XVECEXP (UNSPEC_RTX, 0, 0)
>>
>> No, at XINT (UNSPEC_RTX, 1).  The documentation of UNSPEC says,
>>
>> /* A machine-specific operation.
>> 1st operand is a vector of operands being used by the operation so
>> that any needed reloads can be done.
>> 2nd operand is a unique value saying which of a number of
>> machine-specific operations is to be performed.
>
> Aha, understood now, thanks for the clarification.
>
> You mean we simply reuse the UNSPEC number field, so the RTX will be
>
>   (UNSPEC
>  [((reg) (reg)]
>DW_OP_XXX)
>
> Yeah, I do have tried to do that, but later give up, one reason I remember is 
> suppose we
> want to push two value on the stack, the second value is an address, which we 
> want a
> follow up DW_OP_deref to operate on that. then the value expression will be
>
>(set (reg A)
> (parallel
>   [(reg A)
>
> (UNSPEC
>   [DW_OP_deref, const0_rtx, const0_rtx]
> UNSPEC_PRIVATE_DW);
>
>(UNSPEC
>  [DW_OP_XXX (const0_rtx) (const0_rtx)]
> UNSPEC_PRIVATE_DW))
>
> And there might be some other expressions we need some complex RAW encoding,

Why can't you do this putting the OP in the number field of both UNSPECs?

> so it seems to me if we want to offer user the most general way to do this, 
> then it's
> better to encode the DWARF operation inside UNSPEC as reuse the UNSPEC number 
> then you need to make
> sure there is no overlap with other backend UNSPEC enumeration number.

It seems to me that a CFA_*expression note would never use target
UNSPEC codes, and a DWARF UNSPEC would never appear outside of such a
note, so we don't need to worry about conflicts.

Jason

Re: [PATCH] xtensa: Fix PR target/78118

[augustine.sterl...@gmail.com]

On Mon, Oct 31, 2016 at 11:32 PM, Max Filippov  wrote:
> 2016-10-26  Max Filippov  
> gcc/
> * config/xtensa/xtensa-protos.h
> (xtensa_use_return_instruction_p): New prototype.
> * config/xtensa/xtensa.c (xtensa_current_frame_size,
> xtensa_callee_save_size): Remove.
> (struct machine_function): Add new fields: current_frame_size,
> callee_save_size, frame_laid_out and epilogue_done.
> (compute_frame_size, xtensa_expand_prologue,
> xtensa_expand_epilogue): Replace xtensa_callee_save_size with
> cfun->machine->callee_save_size and xtensa_current_frame_size
> with cfun->machine->current_frame_size.
> (compute_frame_size): Update cfun->machine->frame_laid_out and
> don't update frame layout after reload completion.
> (xtensa_expand_epilogue): Set cfun->machine->epilogue_done
> instead of zeroing xtensa_current_frame_size.
> (xtensa_use_return_instruction_p): New function.
> * config/xtensa/xtensa.h (xtensa_current_frame_size): Remove
> declaration.
> (INITIAL_ELIMINATION_OFFSET): Use return value of
> compute_frame_size instead of xtensa_current_frame_size value.
> * config/xtensa/xtensa.md ("return" pattern): Use new predicate
> function xtensa_use_return_instruction_p instead of inline code.

Approved. Please apply.

[PATCH v2] bb-reorder: Improve compgotos pass (PR71785)

[Segher Boessenkool]

For code like the testcase in PR71785 GCC factors all the indirect branches
to a single dispatcher that then everything jumps to.  This is because
having many indirect branches with each many jump targets does not scale
in large parts of the compiler.  Very late in the pass pipeline (right
before peephole2) the indirect branches are then unfactored again, by
the duplicate_computed_gotos pass.

This pass works by replacing branches to such a common dispatcher by a
copy of the dispatcher.  For code like this testcase this does not work
so well: most cases do a single addition instruction right before the
dispatcher, but not all, and we end up with only two indirect jumps: the
one without the addition, and the one with the addition in its own basic
block, and now everything else jumps _there_.

This patch solves this problem by simply running the core of the
duplicate_computed_gotos pass again, as long as it does any work.  The
patch looks much bigger than it is, because I factored out two routines
to simplify the control flow.

Tested on powerpc64-linux {-m32,-m64}, and on the testcase, and on a version
of the testcase that has 2000 cases instead of 4.  Is this okay for trunk?


Segher


2016-10-30  Segher Boessenkool  

PR rtl-optimization/71785
* bb-reorder.c (duplicate_computed_gotos_find_candidates): New
function, factored out from pass_duplicate_computed_gotos::execute.
(duplicate_computed_gotos_do_duplicate): Ditto.  Don't use BB_VISITED.
(pass_duplicate_computed_gotos::execute): Rewrite.  Rerun the pass as
long as it makes changes.

---
 gcc/bb-reorder.c | 219 +++
 1 file changed, 123 insertions(+), 96 deletions(-)

diff --git a/gcc/bb-reorder.c b/gcc/bb-reorder.c
index 85bc569..f93d684 100644
--- a/gcc/bb-reorder.c
+++ b/gcc/bb-reorder.c
@@ -2593,6 +2593,102 @@ make_pass_reorder_blocks (gcc::context *ctxt)
which can seriously pessimize code with many computed jumps in the source
code, such as interpreters.  See e.g. PR15242.  */
 
+/* Look for blocks that end in a computed jump in function FUN, and see if
+   such blocks are suitable for unfactoring.  If a block is a candidate for
+   unfactoring, mark it in the CANDIDATES.  A block bigger than MAX_SIZE is
+   not suitable.  */
+static void
+duplicate_computed_gotos_find_candidates (function *fun, bitmap candidates,
+ int max_size)
+{
+  basic_block bb;
+  FOR_EACH_BB_FN (bb, fun)
+{
+  /* Obviously the block has to end in a computed jump.  */
+  if (!computed_jump_p (BB_END (bb)))
+   continue;
+
+  /* Only consider blocks that can be duplicated.  */
+  if (CROSSING_JUMP_P (BB_END (bb))
+ || !can_duplicate_block_p (bb))
+   continue;
+
+  /* Make sure that the block is small enough.  */
+  int size = 0;
+  rtx_insn *insn;
+  FOR_BB_INSNS (bb, insn)
+   if (INSN_P (insn))
+ {
+   size += get_attr_min_length (insn);
+   if (size > max_size)
+  break;
+ }
+  if (size > max_size)
+   continue;
+
+  /* Final check: there must not be any incoming abnormal edges.  */
+  int all_flags = 0;
+  edge e;
+  edge_iterator ei;
+  FOR_EACH_EDGE (e, ei, bb->preds)
+   all_flags |= e->flags;
+  if (all_flags & EDGE_COMPLEX)
+   continue;
+
+  bitmap_set_bit (candidates, bb->index);
+}
+}
+
+/* For every jump in FUN to a block in CANDIDATES try to unfactor that block
+   (i.e. duplicate it and jump to the copy instead).  Return whether any
+   change is made.  */
+static bool
+duplicate_computed_gotos_do_duplicate (function *fun, bitmap candidates)
+{
+  bool changed = false;
+
+  basic_block bb;
+  FOR_EACH_BB_FN (bb, fun)
+{
+  /* BB must not already be a copy.  We cannot access CANDIDATES with
+its index if it is.  */
+  if (get_bb_original (bb))
+   continue;
+
+  /* BB must have one outgoing edge.  That edge must not lead to
+the exit block or the next block.
+The destination must have more than one predecessor.  */
+  if (!single_succ_p (bb)
+ || single_succ (bb) == EXIT_BLOCK_PTR_FOR_FN (fun)
+ || single_succ (bb) == bb->next_bb
+ || single_pred_p (single_succ (bb)))
+   continue;
+
+  /* The successor block has to be a duplication candidate.  */
+  if (!bitmap_bit_p (candidates, single_succ (bb)->index))
+   continue;
+
+  /* Don't duplicate a partition crossing edge, which requires difficult
+ fixup.  */
+  if (JUMP_P (BB_END (bb)) && CROSSING_JUMP_P (BB_END (bb)))
+   continue;
+
+  basic_block new_bb = duplicate_block (single_succ (bb),
+   single_succ_edge (bb), bb);
+  new_bb->aux = bb->aux;
+  bb->aux = new_bb;
+  changed = true;
+}
+
+  /* Duplicating blocks above will 

Re: [PATCH] DWARF5 .debug_rnglists support

[Jakub Jelinek]

On Mon, Oct 31, 2016 at 05:03:12PM -0400, Jason Merrill wrote:
> > Ok.  Another option would be to call value_format in size_of_die
> > in this case and put the comment into value_format.
> 
> That works, too.

Done.
> 
> >> In general there's a lot of code duplication between the existing ranges
> >> support and the new rnglist support; even the new vector is a superset of
> >> the old one.  Why duplicate the code rather than modify it?
> >
> > The point was to conserve memory for the -gdwarf-{2,3,4} case.
> > The old table needs just 4 bytes per entry, the new one 16 bytes per entry.
> > The code duplication because of that is mainly in
> > add_high_low_attributes - 24 lines duplicated.
> 
> I was also thinking of the output_rnglists function.

I'm afraid there is nothing that can be shared between output_ranges and
output_rnglists, except for
  FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)
{
  int block_num = r->num;
and
  if (block_num > 0)
{
  char blabel[MAX_ARTIFICIAL_LABEL_BYTES];
  char elabel[MAX_ARTIFICIAL_LABEL_BYTES];

  ASM_GENERATE_INTERNAL_LABEL (blabel, BLOCK_BEGIN_LABEL, block_num);
  ASM_GENERATE_INTERNAL_LABEL (elabel, BLOCK_END_LABEL, block_num);
so I'd prefer to keep them separate instead of having one function with
various dwarf_version >= 5 checks (at least 4).

> 
> > At least while -gdwarf-4 is the default that looked to me like acceptable
> > cost, but if you disagree, I can surely try to just grow the original
> > table and use it for all versions.
> 
> Please.  I think if we're going in this direction we should just go
> ahead with it; if the memory consumption is going to be a problem it
> would be good to find that out so we can address it.

Here it is.  Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-11-01  Jakub Jelinek  

* tree.h (BLOCK_IN_COLD_SECTION_P): Define.
* final.c (final_scan_insn): Set BLOCK_IN_COLD_SECTION_P.
* dwarf2out.c (rnglist_idx): New variable.
(struct dw_ranges): Add label, idx and maybe_new_sec fields.
(DEBUG_RNGLISTS_SECTION): Define.
(ranges_base_label): New variable.
(size_of_die) : If using
DW_FORM_rnglistx, count size of uleb128 of range list index.
(value_format) : For
-gdwarf-5 -gsplit-dwarf return DW_FORM_rnglistx.
(output_range_list_offset): Handle -gdwarf-5 .debug_rnglists
offsets.  Multiply dwarf < 5 offsets by 2 * DWARF_ADDR_SIZE.
(add_ranges_num): Remove useless prototype.  Don't multiply
by 2 * DWARF2_ADDR_SIZE.  Add maybe_new_sec argument, adjust
for new fields added to dw_ranges struct.
(add_ranges): Add maybe_new_sec argument and pass it
through to add_ranges_num.
(note_rnglist_head): New function.
(add_ranges_by_labels): Pass true as maybe_new_sec to
add_ranges_num, call note_rnglist_head on the head of the list.
(output_ranges): Add function comment.  Switch to
.debug_ranges section here and emit .Ldebug_ranges0 label.
(index_rnglists, output_rnglists): New functions.
(gen_subprogram_die): Formatting fixes.
(add_high_low_attributes): Don't divide offsets
by 2 * DWARF2_ADDR_SIZE.  Call note_rnglist_head on the
first list element or when pointing into the middle of
a list.  Pass true as second argument to add_ranges on the
first block fragment after cold/hot section switch.
(init_sections_and_labels): For -gdwarf-5 use .debug_rnglists
section instead of .debug_ranges.  Initialize
ranges_base_label if -gdwarf-5 -gsplit-dwarf.
(dwarf2out_finish): For -gdwarf-5 -gsplit-dwarf call
index_rnglists and add DW_AT_rnglists_base attr.  Don't switch
to dwarf_ranges_section here or emit .Ldebug_ranges0 label.
Call output_rnglists for -gdwarf-5.
(dwarf2out_c_finalize): Clear rnglist_idx.

--- gcc/tree.h.jj   2016-10-31 13:28:06.378442462 +0100
+++ gcc/tree.h  2016-11-01 12:06:47.956228043 +0100
@@ -1757,6 +1757,10 @@ extern void protected_set_expr_location
 /* True if BLOCK has the same ranges as its BLOCK_SUPERCONTEXT.  */
 #define BLOCK_SAME_RANGE(NODE) (BLOCK_CHECK (NODE)->base.u.bits.nameless_flag)
 
+/* True if BLOCK appears in cold section.  */
+#define BLOCK_IN_COLD_SECTION_P(NODE) \
+  (BLOCK_CHECK (NODE)->base.u.bits.atomic_flag)
+
 /* An index number for this block.  These values are not guaranteed to
be unique across functions -- whether or not they are depends on
the debugging output format in use.  */
--- gcc/final.c.jj  2016-10-31 13:28:06.384442386 +0100
+++ gcc/final.c 2016-11-01 12:06:47.958228018 +0100
@@ -2323,6 +2323,7 @@ final_scan_insn (rtx_insn *insn, FILE *f
 
  /* Mark this block as output.  */
  TREE_ASM_WRITTEN (NOTE_BLOCK (insn)) = 1;
+ BLOCK_IN_COLD_SECTION_P (NOTE_BLOCK (insn)) = 

[PATCH] Emit DW_AT_inline for C++17 inline variables (take 2)

[Jakub Jelinek]

On Mon, Oct 31, 2016 at 10:38:40AM -0400, Jason Merrill wrote:
> > The current DWARF 5 wording is:
> > "If the variable entry represents the defining declaration for a C++ static 
> > data
> > member of a structure, class or union, the entry has a DW_AT_specification
> > attribute, whose value is a reference to the debugging information entry
> > representing the declaration of this data member. The referenced entry has
> > the tag DW_TAG_member and will be a child of some class, structure or
> > union type entry." on page 98 in DWARF5_Public_Review.pdf.
> 
> Yes, this changed in DWARF 3; DWARF 2 didn't specify the tag.  I think
> this was a mistake.
> 
> > Incidentally, I've filed today a DWARF issue that Appendix A doesn't list
> > for DW_TAG_member lots of attributes that are allowed for DW_TAG_variable
> > and are useful for static data members.
> 
> Using DW_TAG_variable would address that, too.

After some IRC discussions, following updated patch ensures that even for
inline static data members we emit DW_TAG_member in class with
DW_AT_declaration and DW_TAG_variable outside of the class with
DW_AT_specification pointing to the DW_TAG_member DIE.  DW_AT_location and
DW_AT_linkage_name appear on the DW_TAG_variable DIE,
DW_AT_const_value/DW_AT_const_expr/DW_AT_inline etc. on DW_TAG_member
(except for DW_AT_inline like for non-inline static data members).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-11-01  Jakub Jelinek  

* dwarf2out.c (add_name_and_src_coords_attributes): Add NO_LINKAGE_NAME
argument, don't call add_linkage_name if it is true.
(gen_variable_die): For C++ inline static data members, consider the
initial call when old_die is NULL to be declaration and call
add_name_and_src_coords_attributes in that case with true as
NO_LINKAGE_NAME.  Add DW_AT_inline attribute if needed.
(gen_member_die): For C++ inline static data members, emit a
definition DIE right away in DW_TAG_compile_unit context.
cp/
* cp-objcp-common.c (cp_decl_dwarf_attribute): Handle DW_AT_inline.
testsuite/
* g++.dg/debug/dwarf2/inline-var-1.C: New test.

--- gcc/dwarf2out.c.jj  2016-10-31 22:46:16.932801519 +0100
+++ gcc/dwarf2out.c 2016-11-01 11:51:57.839403234 +0100
@@ -3503,7 +3503,7 @@ static void add_prototyped_attribute (dw
 static dw_die_ref add_abstract_origin_attribute (dw_die_ref, tree);
 static void add_pure_or_virtual_attribute (dw_die_ref, tree);
 static void add_src_coords_attributes (dw_die_ref, tree);
-static void add_name_and_src_coords_attributes (dw_die_ref, tree);
+static void add_name_and_src_coords_attributes (dw_die_ref, tree, bool = 
false);
 static void add_discr_value (dw_die_ref, dw_discr_value *);
 static void add_discr_list (dw_die_ref, dw_discr_list_ref);
 static inline dw_discr_list_ref AT_discr_list (dw_attr_node *);
@@ -19820,7 +19820,8 @@ add_linkage_name (dw_die_ref die, tree d
given decl, but only if it actually has a name.  */
 
 static void
-add_name_and_src_coords_attributes (dw_die_ref die, tree decl)
+add_name_and_src_coords_attributes (dw_die_ref die, tree decl,
+   bool no_linkage_name)
 {
   tree decl_name;
 
@@ -19833,7 +19834,8 @@ add_name_and_src_coords_attributes (dw_d
   if (! DECL_ARTIFICIAL (decl))
add_src_coords_attributes (die, decl);
 
-  add_linkage_name (die, decl);
+  if (!no_linkage_name)
+   add_linkage_name (die, decl);
 }
 
 #ifdef VMS_DEBUGGING_INFO
@@ -22215,6 +22217,22 @@ gen_variable_die (tree decl, tree origin
   bool declaration = (DECL_EXTERNAL (decl_or_origin)
  || class_or_namespace_scope_p (context_die));
   bool specialization_p = false;
+  bool no_linkage_name = false;
+
+  /* While C++ inline static data members have definitions inside of the
+ class, force the first DIE to be a declaration, then let gen_member_die
+ reparent it to the class context and call gen_variable_die again
+ to create the outside of the class DIE for the definition.  */
+  if (!declaration
+  && old_die == NULL
+  && decl
+  && DECL_CONTEXT (decl)
+  && TYPE_P (DECL_CONTEXT (decl))
+  && lang_hooks.decls.decl_dwarf_attribute (decl, DW_AT_inline) != -1)
+{
+  declaration = true;
+  no_linkage_name = true;
+}
 
   ultimate_origin = decl_ultimate_origin (decl_or_origin);
   if (decl || ultimate_origin)
@@ -22402,7 +22420,7 @@ gen_variable_die (tree decl, tree origin
}
 }
   else
-add_name_and_src_coords_attributes (var_die, decl);
+add_name_and_src_coords_attributes (var_die, decl, no_linkage_name);
 
   if ((origin == NULL && !specialization_p)
   || (origin != NULL
@@ -22465,6 +22483,17 @@ gen_variable_die (tree decl, tree origin
   && (origin_die == NULL || get_AT (origin_die, DW_AT_const_expr) == NULL)
   && !specialization_p)
 add_AT_flag (var_die, DW_AT_const_expr, 1);
+
+  if 

Re: [PATCH, testsuite]: Cleanup lib/target-supports.exp, ...

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 10:05:22AM +0100, Uros Bizjak wrote:
> ... simplify some conditions and add i?86-*-* target where missing.
> 
> 2016-11-01  Uros Bizjak  
> 
> * lib/target-supports.exp: Normalize order of i?86 and x86_64 targets.
> Whitespace fixes.
...
> (check_effective_target_divmod): Add i?86-*-* target.

This part likely broke
+FAIL: gcc.dg/divmod-1.c scan-tree-dump-times widening_mul "DIVMOD" 7
+FAIL: gcc.dg/divmod-2.c scan-tree-dump-times widening_mul "DIVMOD" 7
+FAIL: gcc.dg/divmod-3.c scan-tree-dump-times widening_mul "DIVMOD" 7
+FAIL: gcc.dg/divmod-4.c scan-tree-dump-times widening_mul "DIVMOD" 7
+FAIL: gcc.dg/divmod-6.c scan-tree-dump-times widening_mul "DIVMOD" 7
on i686-linux (i.e. 32-bit).

Dunno what exactly the tests are meant to test, most likely they just
need extra guards or something.  Can be reproduced even on x86_64-linux
with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} dg.exp=divmod*'

> @@ -8110,7 +8090,7 @@
>  #TODO: Add checks for all targets that have either hardware divmod insn
>  # or define libfunc for divmod.
>  if { [istarget arm*-*-*]
> -  || [istarget x86_64-*-*] } {
> +  || [istarget i?86-*-*] || [istarget x86_64-*-*] } {
>   return 1
>  }
>  return 0


Jakub

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

[Jiong Wang]

On 01/11/16 15:24, Jason Merrill wrote:

On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang  wrote:

On 31/10/16 19:50, Jason Merrill wrote:

On 10/21/2016 04:30 AM, Jiong Wang wrote:

All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't have RTL mapping are wrapped by
UNSPEC.  The parsing algorithm is simply something like:

   foreach elem inside PARALLEL
 if (UNSPEC)
   {
 dw_op_code = INTVAL (XVECEXP (elem, 0, 0));
 oprnd1 = INTVAL (XVECEXP (elem, 0, 1));
 oprnd2 = INTVAL (XVECEXP (elem, 0, 2));
   }
 else
   call standard RTL parser.

Any comments on the approach?


If you're going to use UNSPEC, why not put the DWARF operator in the
second operand?

   Thanks for the review, but I still don't understand your meaning.

   Do you mean I should simply put the DWARF operator at XVECEXP (UNSPEC_RTX,
0, 2) instead of at XVECEXP (UNSPEC_RTX, 0, 0)

No, at XINT (UNSPEC_RTX, 1).  The documentation of UNSPEC says,

/* A machine-specific operation.
1st operand is a vector of operands being used by the operation so
that
  any needed reloads can be done.
2nd operand is a unique value saying which of a number of
machine-specific
  operations is to be performed.


Aha, understood now, thanks for the clarification.

You mean we simply reuse the UNSPEC number field, so the RTX will be

  (UNSPEC
 [((reg) (reg)]
   DW_OP_XXX)

Yeah, I do have tried to do that, but later give up, one reason I 
remember is suppose we
want to push two value on the stack, the second value is an address, 
which we want a

follow up DW_OP_deref to operate on that. then the value expression will be

   (set (reg A)
(parallel
  [(reg A)

(UNSPEC
  [DW_OP_deref, const0_rtx, const0_rtx]
UNSPEC_PRIVATE_DW);

   (UNSPEC
 [DW_OP_XXX (const0_rtx) (const0_rtx)]
UNSPEC_PRIVATE_DW))

And there might be some other expressions we need some complex RAW 
encoding, so it seems to
me if we want to offer user the most general way to do this, then it's 
better to encode the DWARF
operation inside UNSPEC as reuse the UNSPEC number then you need to make 
sure there is no

overlap with other backend UNSPEC enumeration number.

Does this explanation make sense to you?

Thanks.

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Bernd Edlinger]

On 11/01/16 16:20, Jason Merrill wrote:
> On 10/17/2016 03:18 PM, Bernd Edlinger wrote:
>> +@item -Wbuiltin-function-redefined @r{(C++ and Objective-C++ only)}
>> +@opindex Wbuiltin-function-redefined
>> +@opindex Wno-builtin-function-redefined
>> +Do warn if built-in functions are redefined.  This option is only
>> +supported for C++ and Objective-C++.  It is implied by @option{-Wall},
>> +which can be disabled with @option{-Wno-builtin-function-redefined}.
>
> There's no redefinition here (only a redeclaration), so perhaps
> -Wbuiltin-redeclaration-mismatch?
>

Works for me.  Thanks.

> I'm not even sure we need a new warning.  Can we combine this warning
> with the block that currently follows?
>

After 20 years of not having a warning on that,
an implicitly enabled warning would at least break lots of bogus
test cases.  Of course in C we have an implicitly enabled warning,
so I would like to at least enable the warning on -Wall, thus
-Wshadow is too weak IMO.

>>   else if ((DECL_EXTERN_C_P (newdecl)
>> && DECL_EXTERN_C_P (olddecl))
>>|| compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
>>  TYPE_ARG_TYPES (TREE_TYPE (olddecl
>> {
>>   /* A near match; override the builtin.  */
>>
>>   if (TREE_PUBLIC (newdecl))
>> warning_at (DECL_SOURCE_LOCATION (newdecl), 0,
>> "new declaration %q#D ambiguates built-in "
>> "declaration %q#D", newdecl, olddecl);
>>   else
>> warning (OPT_Wshadow,
>>  DECL_BUILT_IN (olddecl)
>>  ? G_("shadowing built-in function %q#D")
>>  : G_("shadowing library function %q#D"),
>> olddecl);
>> }
>
> It seems to me that if we have an extern "C" declaration that doesn't
> match the built-in, we should just warn.
>
> I looked at some of the testcases you mentioned in the bug report, and
> those declarations aren't extern "C", so we shouldn't be warning about
> them.  Does your current patch still warn about those?
>

No.  After looking at the false positives with the previous patch,
I changed my mind about that.

This started because I wanted to add builtin functions for some
special_function_p names.  And I wanted to warn the user if he uses a
name that is recognized by special_function_p, but the parameters
don't match.  Now I think we need to teach special_function_p to
distinguish "C" functions from "C++" functions, which it currently
cannot do, because that knowledge is only in the C++ FE.


Bernd.

[PATCH] AIX visibility

[David Edelsohn]

This patch enables visibility support for AIX.  AIX of course chose
different syntax, so the default machinery isn't usable.  AIX appends
the visibility to the .globl and .comm pseudo-ops.

Within the rs6000 port, this patch only affects AIX / XCOFF.

Also, because visibility support implicitly enables other features in
GCC, some of which conflict with AIX, I had to disable the additional
features.  Because AIX uses DWARF for EH but places the DWARF
information in the data section, the use of DWARF references and
force_constant_mem conflicts with the data section.  For this reason,
USE_LINKONCE_INDIRECT is disabled in dwarf2asm.c.

This patch also adjusts gcc/configure to set HAVE_GAS_HIDDEN. AIX ld
support for hidden is forced true because the assembler test will
catch if support is present.

A number of testsuite tweaks also are necessary to XFAIL some
visibility tests on AIX.

Bootstrapped on powerpc-ibm-aix7.2.0.0 and powerpc64le-ibm-linux-gnu.

Are the changes to configure and dwarf2asm.c okay?

* configure.ac (.hidden): Change to conftest_s string. Provide string
for AIX assembler.
(gcc_cv_ld_hidden): Yes for AIX.
* configure: Regenerate.

* dwarf2asm.c (USE_LINKONCE_INDIRECT): Don't set for AIX (XCOFF).

* config/rs6000/rs6000-protos.h
(rs6000_xcoff_asm_output_aligned_decl_common): Declare.
* config/rs6000/xcoff.h (TARGET_ASM_GLOBALIZE_DECL_NAME): Define.
(ASM_OUTPUT_ALIGNED_DECL_COMMON): Define.
(ASM_OUTPUT_ALIGNED_COMMON): Delete.
* config/rs6000/rs6000.c (rs6000_xcoff_visibility): New.
(rs6000_xcoff_declare_function_name): Add visibility support.
(rs6000_xcoff_asm_globalize_decl_name): New.
(rs6000_xcoff_asm_output_aligned_decl_common): New.
(rs6000_code_end): Disable HIDDEN_LINKONCE on XCOFF.

Thanks, David


ZZ
Description: Binary data

[PATCH][GCC/TESTSUITE] Make test for traditional-cpp depend on

[Tamar Christina]

Hi all,

A glibc update recently broke this test by adding a CPP
macro that uses the ## string function which traditional-cpp
does not support.
The change in glibc that made the test fail is from
6962682ffe5e5f0373047a0b894fee7a774be254.

This fixes (PR78136) by changing the test to use a local
include file instead of one from glibc.
The intention of the test is to test that traditional-cpp does
not expand values inside <> blocks of #includes.
As such the include has to be included via <> syntax. To do this
the .exp has been modified to add the test directory to the
Include search path.

Ran regression tests on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Tamar

gcc/testsuite/

2016-10-31  Tamar Christina  

PR testsuite/78136
* gcc.dg/cpp/trad/trad.exp
(dg-runtest): Added $srcdir/$subdir/ to Include dirs.
* gcc.dg/cpp/trad/include.c: Use local header file.

pr78136-fix-tradition-cpp
Description: pr78136-fix-tradition-cpp

Re: [PATCH VECT]Swap operands for cond_reduction when necessary

[Bin.Cheng]

On Fri, Oct 28, 2016 at 1:38 PM, Richard Biener
 wrote:
> On Wed, Oct 26, 2016 at 6:42 PM, Bin Cheng  wrote:
>> Hi,
>> For stmt defining reduction, GCC vectorizer assumes that the reduction 
>> variable is always the last (second) operand.  Another fact is that 
>> vectorizer doesn't swap operands for cond_reduction during analysis stage.  
>> The problem is GCC middle-end may canonicalize cond_expr into a form that 
>> reduction variable is not the last one.  At the moment, such case cannot be 
>> vectorized.
>> The patch fixes this issue by swapping operands in cond_reduction when it's 
>> necessary.  The patch also swaps it back if vectorization fails.  The patch 
>> resolves failures introduced by previous match.pd patches.  In addition, 
>> couple cases are XPASSed on AArch64 now, which means more loops are 
>> vectorized.  I will send following patch addressing those XPASS tests.
>> Bootstrap and test on x86_64 and AArch64 ongoing, is it OK?
>
> @@ -1225,6 +1225,20 @@ destroy_loop_vec_info (loop_vec_info
> loop_vinfo, bool clean_stmts)
> swap_ssa_operands (stmt,
>gimple_assign_rhs1_ptr (stmt),
>gimple_assign_rhs2_ptr (stmt));
> + else if (code == COND_EXPR
> +  && CONSTANT_CLASS_P (gimple_assign_rhs2 (stmt)))
> +   {
> + tree cond_expr = gimple_assign_rhs1 (stmt);
> + enum tree_code cond_code = TREE_CODE (cond_expr);
> +
> + gcc_assert (TREE_CODE_CLASS (cond_code) == tcc_comparison);
> + /* HONOR_NANS doesn't matter when inverting it back.  */
>
> I think this doesn't hold true for COND_EXPRs that were originally
> this way as canonicalization
> is also inhibited by this.  I suggest to simply not invert back when
> cond_code == ERROR_MARK
> as we can't possibly have swapped it to the current non-canonical way.
>
> Ok with that change.
Thanks for reviewing, attachment is the updated patch as suggested.
Will apply it if no further problems.

Thanks,
bin
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 9cca9b7..1cd9c72 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -1225,6 +1225,27 @@ destroy_loop_vec_info (loop_vec_info loop_vinfo, bool 
clean_stmts)
swap_ssa_operands (stmt,
   gimple_assign_rhs1_ptr (stmt),
   gimple_assign_rhs2_ptr (stmt));
+ else if (code == COND_EXPR
+  && CONSTANT_CLASS_P (gimple_assign_rhs2 (stmt)))
+   {
+ tree cond_expr = gimple_assign_rhs1 (stmt);
+ enum tree_code cond_code = TREE_CODE (cond_expr);
+
+ if (TREE_CODE_CLASS (cond_code) == tcc_comparison)
+   {
+ bool honor_nans = HONOR_NANS (TREE_OPERAND (cond_expr,
+ 0));
+ cond_code = invert_tree_comparison (cond_code,
+ honor_nans);
+ if (cond_code != ERROR_MARK)
+   {
+ TREE_SET_CODE (cond_expr, cond_code);
+ swap_ssa_operands (stmt,
+gimple_assign_rhs2_ptr (stmt),
+gimple_assign_rhs3_ptr (stmt));
+   }
+   }
+   }
}
 
  /* Free stmt_vec_info.  */
@@ -3006,38 +3027,56 @@ vect_is_simple_reduction (loop_vec_info loop_info, 
gimple *phi,
   && (code == COND_EXPR
  || !def2 || gimple_nop_p (def2)
  || !flow_bb_inside_loop_p (loop, gimple_bb (def2))
-  || (def2 && flow_bb_inside_loop_p (loop, gimple_bb (def2))
- && (is_gimple_assign (def2)
+ || (def2 && flow_bb_inside_loop_p (loop, gimple_bb (def2))
+ && (is_gimple_assign (def2)
  || is_gimple_call (def2)
- || STMT_VINFO_DEF_TYPE (vinfo_for_stmt (def2))
-  == vect_induction_def
- || (gimple_code (def2) == GIMPLE_PHI
+ || STMT_VINFO_DEF_TYPE (vinfo_for_stmt (def2))
+  == vect_induction_def
+ || (gimple_code (def2) == GIMPLE_PHI
  && STMT_VINFO_DEF_TYPE (vinfo_for_stmt (def2))
-  == vect_internal_def
+  == vect_internal_def
  && !is_loop_header_bb_p (gimple_bb (def2)))
 {
-  if (check_reduction
- && orig_code != MINUS_EXPR)
-{
+  if (check_reduction && orig_code != MINUS_EXPR)
+   {
+ /* Check if we can swap operands (just for simplicity - so that
+the rest of the code can assume that the reduction variable
+  

Re: [PR56974] output DWARF-5 markers for ref_qualifiers

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 11:34:47AM -0400, Jason Merrill wrote:
> On Wed, Oct 19, 2016 at 6:15 AM, Alexandre Oliva  wrote:
> > When a method or a method or function type has a ref-qualifier, output
> > DW_AT_reference or DW_AT_rvalue_reference in the subprogram or
> > subroutine_type tag, as specified in DWARF version 5 drafts, see
> > .
> 
> I believe one of Jakub's recent patches has addressed this.  Can you
> verify that with your testcases?

For methods and functions yes, in r241492.

> > Output pointer to member function types as DW_TAG_ptr_to_member_type,
> > as required by DWARF since version 2.
> 
> This should use the existing get_debug_type langhook.

For pointer to member, I've posted an unsuccessful attempt at that today,
http://gcc.gnu.org/ml/gcc-patches/2016-11/msg00022.html
But that wasn't trying to emit DW_TAG_ptr_to_member_type, just
the DW_AT_{,rvalue_}reference on DW_TAG_subroutine_type.

Jakub

Re: [PR56974] output DWARF-5 markers for ref_qualifiers

[Jason Merrill]

On Wed, Oct 19, 2016 at 6:15 AM, Alexandre Oliva  wrote:
> When a method or a method or function type has a ref-qualifier, output
> DW_AT_reference or DW_AT_rvalue_reference in the subprogram or
> subroutine_type tag, as specified in DWARF version 5 drafts, see
> .

I believe one of Jakub's recent patches has addressed this.  Can you
verify that with your testcases?

> Output pointer to member function types as DW_TAG_ptr_to_member_type,
> as required by DWARF since version 2.

This should use the existing get_debug_type langhook.

Jason

[PATCH] [ARC] Various small miscellaneous fixes.

[Claudiu Zissulescu]

This is an updated version of the patch that can be applied as is.

Ok to apply?
Claudiu

gcc/
2016-05-09  Claudiu Zissulescu  

* config/arc/arc.c (arc_process_double_reg_moves): Change.
* config/arc/arc.md (movsi_insn): Disable unsupported move
instructions for ARCv2 cores.
(movdi): Use prepare_move_operands.
(movsf, movdf): Use move_dest_operand predicate.
(arc_process_double_reg_moves): Change.
* config/arc/constraints.md (Chs): Enable when barrel shifter is
present.
* config/arc/fpu.md (divsf3): Change to divsf3_fpu.
* config/arc/fpx.md (dexcl_3op_peep2_insn): Dx data register is
also a destination.
(dexcl_3op_peep2_insn_nores): Likewise.
* config/arc/arc.h (SHIFT_COUNT_TRUNCATED): Define to one.
(LINK_COMMAND_SPEC): Remove.
---
 gcc/config/arc/arc.c  |  5 +
 gcc/config/arc/arc.h  | 27 +++
 gcc/config/arc/arc.md | 35 +++
 gcc/config/arc/constraints.md |  3 ++-
 gcc/config/arc/fpu.md |  6 --
 gcc/config/arc/fpx.md | 26 --
 6 files changed, 41 insertions(+), 61 deletions(-)

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 0e7b63d..c927d5b 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -9021,10 +9021,7 @@ arc_process_double_reg_moves (rtx *operands)
   rtx srcLow  = simplify_gen_subreg (SImode, src, DFmode,
TARGET_BIG_ENDIAN ? 4 : 0);
 
-  emit_insn (gen_rtx_UNSPEC_VOLATILE (Pmode,
- gen_rtvec (3, dest, srcHigh, srcLow),
- VUNSPEC_ARC_DEXCL_NORES));
-
+  emit_insn (gen_dexcl_2op (dest, srcHigh, srcLow));
 }
   else
 gcc_unreachable ();
diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index b146f3a..17285a7 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -128,24 +128,6 @@ along with GCC; see the file COPYING3.  If not see
   %{!marclinux*: %{pg|p|profile:-marclinux_prof;: -marclinux}} 
\
   %{!z:-z max-page-size=0x2000 -z common-page-size=0x2000} \
   %{shared:-shared}"
-/* Like the standard LINK_COMMAND_SPEC, but add %G when building
-   a shared library with -nostdlib, so that the hidden functions of libgcc
-   will be incorporated.
-   N.B., we don't want a plain -lgcc, as this would lead to re-exporting
-   non-hidden functions, so we have to consider libgcc_s.so.* first, which in
-   turn should be wrapped with --as-needed.  */
-#define LINK_COMMAND_SPEC "\
-%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
-%(linker) %l " LINK_PIE_SPEC "%X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}\
-%{s} %{t} %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
-%{static:} %{L*} %(mfwrap) %(link_libgcc) %o\
-%{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1):\
-   %:include(libgomp.spec)%(link_gomp)}\
-%(mflib)\
-%{fprofile-arcs|fprofile-generate|coverage:-lgcov}\
-%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
-%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}"
-
 #else
 #define LINK_SPEC "%{mbig-endian:-EB} %{EB} %{EL}\
   %{pg|p:-marcelf_prof;mA7|mARC700|mcpu=arc700|mcpu=ARC700: -marcelf}"
@@ -1570,13 +1552,10 @@ extern int arc_return_address_regs[4];
 /* Undo the effects of the movmem pattern presence on STORE_BY_PIECES_P .  */
 #define MOVE_RATIO(SPEED) ((SPEED) ? 15 : 3)
 
-/* Define this to be nonzero if shift instructions ignore all but the low-order
-   few bits. Changed from 1 to 0 for rotate pattern testcases
-   (e.g. 20020226-1.c). This change truncates the upper 27 bits of a word
-   while rotating a word. Came to notice through a combine phase
-   optimization viz. a << (32-b) is equivalent to a << (-b).
+/* Define this to be nonzero if shift instructions ignore all but the
+   low-order few bits.
 */
-#define SHIFT_COUNT_TRUNCATED 0
+#define SHIFT_COUNT_TRUNCATED 1
 
 /* Value is 1 if truncating an integer of INPREC bits to OUTPREC bits
is done just by pretending it is already truncated.  */
diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index e127d5b..7147fbd 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -704,9 +704,9 @@
 ; the iscompact attribute allows the epilogue expander to know for which
 ; insns it should lengthen the return insn.
 ; N.B. operand 1 of alternative 7 expands into pcl,symbol@gotpc .
-(define_insn "*movsi_insn"  ;   0 1 23  4 5   
6   7   8   9   10  11  1213   14  15  16 17 18 19   202122 
23 2425 26  27   28   29
-  [(set (match_operand:SI 0 "move_dest_operand" "=Rcq,Rcq#q,w,   h, w,w,  
w,  w,  w,  w,???w, ?w,  w,Rcq#q,   w,Rcq,  S,   Us<,RcqRck,!*x,  
r,!*Rsd,!*Rcd,r,Ucm,  Usd,m,???m,VUsc,VUsc")
-   

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

[Jason Merrill]

On Tue, Nov 1, 2016 at 11:12 AM, Jiong Wang  wrote:
> On 31/10/16 19:50, Jason Merrill wrote:
>>
>> On 10/21/2016 04:30 AM, Jiong Wang wrote:
>>>
>>> All DW_OP_* of the expression are grouped together inside the PARALLEL,
>>> and those operations which don't have RTL mapping are wrapped by
>>> UNSPEC.  The parsing algorithm is simply something like:
>>>
>>>   foreach elem inside PARALLEL
>>> if (UNSPEC)
>>>   {
>>> dw_op_code = INTVAL (XVECEXP (elem, 0, 0));
>>> oprnd1 = INTVAL (XVECEXP (elem, 0, 1));
>>> oprnd2 = INTVAL (XVECEXP (elem, 0, 2));
>>>   }
>>> else
>>>   call standard RTL parser.
>>>
>>> Any comments on the approach?
>>
>>
>> If you're going to use UNSPEC, why not put the DWARF operator in the
>> second operand?
>
>   Thanks for the review, but I still don't understand your meaning.
>
>   Do you mean I should simply put the DWARF operator at XVECEXP (UNSPEC_RTX,
> 0, 2) instead of at XVECEXP (UNSPEC_RTX, 0, 0)

No, at XINT (UNSPEC_RTX, 1).  The documentation of UNSPEC says,

/* A machine-specific operation.
   1st operand is a vector of operands being used by the operation so
that
 any needed reloads can be done.
   2nd operand is a unique value saying which of a number of
machine-specific
 operations is to be performed.

Jason

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Bernd Edlinger]

On 11/01/16 16:02, Jason Merrill wrote:
> On 10/17/2016 03:18 PM, Bernd Edlinger wrote:
>> Regarding this hunk:
>>
>> /* Whether or not the builtin can throw exceptions has no
>>   bearing on this declarator.  */
>> -  TREE_NOTHROW (olddecl) = 0;
>> +  TREE_NOTHROW (olddecl) = TREE_NOTHROW (newdecl);
>>
>> You may ask, why the old code was working most of the time.
>> I think, usually, when types_match == true, there happens another
>> assignment to TREE_NOTHROW, later in that function around line 2183:
>>
>>/* Merge the type qualifiers.  */
>>if (TREE_READONLY (newdecl))
>>  TREE_READONLY (olddecl) = 1;
>>if (TREE_THIS_VOLATILE (newdecl))
>>  TREE_THIS_VOLATILE (olddecl) = 1;
>>if (TREE_NOTHROW (newdecl))
>>  TREE_NOTHROW (olddecl) = 1;
>>
>> This is in a big "if (types_match)", so I think that explains,
>> why the old code did work normally, and why it fails if the
>> parameter don't match, but I still have no idea what to say
>> in the comment, except that the code should exactly do what
>> the comment above says.
>
> I think a better fix would be to add a copy of TREE_NOTHROW to the else
> block of the if (types_match), to go with the existing copies of
> TREE_READONLY and TREE_THIS_VOLATILE.  But yes, duplicate_decls is a mess.
>

Possibly, but I am only aware of problems with redeclarations
of builtins functions, TREE_CODE (olddecl) == FUNCTION_DECL
&& DECL_ARTIFICIAL (olddecl), but the "if (types_match)" can
be called for many other types of decls.

So super scary code here

[PATCH, Fortran] New warning flag -Wargument-mismatch to control argument mismatch warnings

[Fritz Reese]

All,

Here I propose a new warning flag -Wargument-mismatch to control
warnings emitted when the type, rank, or some other property of actual
arguments does not match that of a function's formal parameters
according to its declaration or interface specification. The warnings
are of course enabled by default, as they should be. Note also with
-Wno-argument-mismatch, only _warnings_ are suppressed. In such cases
where an argument mismatch is an error, the error is still properly
emitted.

This simple patch depends on the recently-submitted patch [1] "Allow
warnings given through gfc_error to associate with warning flags".
Since the argument mismatch warnings are sometimes errors, they are
currently emitted through gfc_error with `warnings_not_errors` set.
Without the solution in [1], awkward code changes may be required to
work around this fact.

The new flag is supplied for the benefit of those users which believe
that suppression of any given warning generated by a compiler should
be possible. Such users may be frustrated with the current GNU Fortran
front-end, in which there is no way to suppress this class of
warnings, even if the user "knows what he is doing" and refuses to
change his/her code.

[1] https://gcc.gnu.org/ml/fortran/2016-11/msg3.html

Bootstraps and regtests on x86_64-redhat-linux.

if (gfc_accepted ([1]))
  {
gfc_ask_ok_for_trunk ($0);
  }

---
Fritz Reese

Re: [PATCH testsuite]Require vect_cond_mixed for test case gcc.dg/vect/pr56541.c

[Bin.Cheng]

On Thu, Aug 11, 2016 at 11:38 AM, Richard Biener
 wrote:
> On Thu, Aug 11, 2016 at 11:56 AM, Bin.Cheng  wrote:
>> On Thu, Aug 11, 2016 at 10:50 AM, Richard Biener
>>  wrote:
>>> On Wed, Aug 10, 2016 at 5:58 PM, Bin Cheng  wrote:
 Hi,
 Due to some reasons, tree-if-conv.c now factors floating point comparison 
 out of cond_expr,
 resulting in mixed types in it.  This does help CSE on common comparison 
 operations.
 Only problem is that test gcc.dg/vect/pr56541.c now requires 
 vect_cond_mixed to be
 vectorized.  This patch changes the test in that way.
 Test result checked.  Is it OK?
>>>
>>> Hmm, I think the fix is to fix if-conversion not doing that.  Can you
>>> track down why this happens?
>> Hmm, but there are several common floating comparison operations in
>> the case, by doing this, we could do CSE on GIMPLE, otherwise we
>> depends on RTL optimizers.
>
> I see.
>
>> I thought we prefer GIMPLE level
>> transforms?
>
> Yes, but the vectorizer is happier with the conditions present in the 
> COND_EXPR
> and thus we concluded we always want to have them there.  forwprop will
> also aggressively put them back.  Note that we cannot put back
> tree_could_throw_p
> conditions (FP compares with signalling nans for example) to properly model EH
> (though for VEC_COND_EXPRs we don't really care here).
>
> Note that nothing between if-conversion and vectorization will perform
> the desired
> CSE anyway.
Hi Richard,
I looked into this one and found it was not if-conv factors cond_expr
out.  For test case:

  for (i=0; i!=1024; ++i)
{
  float rR = a*z[i];
  float rL = b*z[i];
  float rMin = (rR0) ? rMin : rBig;
  rMin = (rMin>0) ? rMin : rMax;
  ok[i] = rMin-c
  if (iftmp.3_12 > 0.0)
goto ;
  else
goto ;

  :

  :
  # iftmp.4_13 = PHI 
  if (iftmp.4_13 > 0.0)
goto ;
  else
goto ;

  :

  :
  # iftmp.5_14 = PHI 

Jump thread in dom pass threads edges (bb7 -> bb8 -> ... bb11) to (bb6
-> bb12 -> bb9) as below:

  :
  # iftmp.3_12 = PHI 
  # iftmp.2_23 = PHI 
  if (iftmp.3_12 > 0.0)
goto ;
  else
goto ;

  :
  # iftmp.4_13 = PHI 
  if (iftmp.4_13 > 0.0)
goto ;
  else
goto ;

  :

  :
  # iftmp.5_14 = PHI 

  //...
  :
  # iftmp.4_22 = PHI <1.5e+2(6)>
  goto ;

This transform saves one comparison on the path, but creates multi-arg
phi, resulting in cond_expr being factored out.

Looks like threading corrupts vectorization opportunity for target
doesn't support vect_cond_mixed, but I guess it's hard to tell in
threading itself.  Any ideas?

Thanks,
bin

Re: [PATCH][AArch64] Expand DImode constant stores to two SImode stores when profitable

[Kyrill Tkachov]

And here is the patch itself.


On 01/11/16 15:21, Kyrill Tkachov wrote:


On 31/10/16 11:54, Kyrill Tkachov wrote:


On 24/10/16 17:15, Andrew Pinski wrote:

On Mon, Oct 24, 2016 at 7:27 AM, Kyrill Tkachov
 wrote:

Hi all,

When storing a 64-bit immediate that has equal bottom and top halves we
currently
synthesize the repeating 32-bit pattern twice and perform a single X-store.
With this patch we synthesize the 32-bit pattern once into a W register and
store
that twice using an STP. This reduces codesize bloat from synthesising the
same
constant multiple times at the expense of converting a store to a
store-pair.
It will only trigger if we can save two or more instructions, so it will
only transform:
 mov x1, 49370
 movkx1, 0xc0da, lsl 32
 str x1, [x0]

into:

 mov w1, 49370
 stp w1, w1, [x0]

when optimising for -Os, whereas it will always transform a 4-insn synthesis
sequence into a two-insn sequence + STP (see comments in the patch).

This patch triggers already but will trigger more with the store merging
pass
that I'm working on since that will generate more of these repeating 64-bit
constants.
This helps improve codegen on 456.hmmer where store merging can sometimes
create very
complex repeating constants and target-specific expand needs to break them
down.


Doing STP might be worse on ThunderX 1 than the mov/movk.  Or this
might cause an ICE with -mcpu=thunderx; I can't remember if the check
for slow unaligned store pair word is with the pattern or not.


I can't get it to ICE with -mcpu=thunderx.
The restriction is just on the STP forming code in the sched-fusion hooks AFAIK.


Basically the rule is
1) if 4 byte aligned, then it is better to do two str.
2) If 8 byte aligned, then doing stp is good
3) Otherwise it is better to do two str.


Ok, then I'll make the function just emit two stores and depend on the 
sched-fusion
machinery to fuse them into an STP when appropriate since that has the logic 
that
takes thunderx into account.



Here it is.
I've confirmed that it emits to STRs for 4 byte aligned stores when 
-mtune=thunderx
and still generates STP for the other tunings, though now sched-fusion is 
responsible for
merging them, which is ok by me.

Bootstrapped and tested on aarch64.
Ok for trunk?

Thanks,
Kyril


2016-11-01  Kyrylo Tkachov  

* config/aarch64/aarch64.md (mov): Call
aarch64_split_dimode_const_store on DImode constant stores.
* config/aarch64/aarch64-protos.h (aarch64_split_dimode_const_store):
New prototype.
* config/aarch64/aarch64.c (aarch64_split_dimode_const_store): New
function.

2016-11-01  Kyrylo Tkachov  

* gcc.target/aarch64/store_repeating_constant_1.c: New test.
* gcc.target/aarch64/store_repeating_constant_2.c: Likewise.






Thanks,
Andrew



Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

2016-10-24  Kyrylo Tkachov  

 * config/aarch64/aarch64.md (mov): Call
 aarch64_split_dimode_const_store on DImode constant stores.
 * config/aarch64/aarch64-protos.h (aarch64_split_dimode_const_store):
 New prototype.
 * config/aarch64/aarch64.c (aarch64_split_dimode_const_store): New
 function.

2016-10-24  Kyrylo Tkachov  

 * gcc.target/aarch64/store_repeating_constant_1.c: New test.
 * gcc.target/aarch64/store_repeating_constant_2.c: Likewise.






diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 4f4989d8b0da91096000d0b51736eaa5b0aa9474..b6ca3dfacb0dc88e5d688905d9d013263d4e8d7f 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -337,6 +337,7 @@ bool aarch64_simd_scalar_immediate_valid_for_move (rtx, machine_mode);
 bool aarch64_simd_shift_imm_p (rtx, machine_mode, bool);
 bool aarch64_simd_valid_immediate (rtx, machine_mode, bool,
    struct simd_immediate_info *);
+bool aarch64_split_dimode_const_store (rtx, rtx);
 bool aarch64_symbolic_address_p (rtx);
 bool aarch64_uimm12_shift (HOST_WIDE_INT);
 bool aarch64_use_return_insn_p (void);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index a5c72a65451db639a5a623d15ecc61ceb60d1707..ec77d1cb2a6c63ac1703efc75fc67946e7d24c8e 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -13178,6 +13178,63 @@ aarch64_expand_movmem (rtx *operands)
   return true;
 }
 
+/* Split a DImode store of a CONST_INT SRC to MEM DST as two
+   SImode stores.  Handle the case when the constant has identical
+   bottom and top halves.  This is beneficial when the two stores can be
+   merged into an STP and we avoid synthesising potentially expensive
+   immediates twice.  Return true if such a split is possible.  */
+
+bool
+aarch64_split_dimode_const_store (rtx dst, rtx src)
+{
+  rtx lo = gen_lowpart (SImode, src);
+  rtx 

Re: [PATCH][AArch64] Expand DImode constant stores to two SImode stores when profitable

[Kyrill Tkachov]

On 31/10/16 11:54, Kyrill Tkachov wrote:


On 24/10/16 17:15, Andrew Pinski wrote:

On Mon, Oct 24, 2016 at 7:27 AM, Kyrill Tkachov
 wrote:

Hi all,

When storing a 64-bit immediate that has equal bottom and top halves we
currently
synthesize the repeating 32-bit pattern twice and perform a single X-store.
With this patch we synthesize the 32-bit pattern once into a W register and
store
that twice using an STP. This reduces codesize bloat from synthesising the
same
constant multiple times at the expense of converting a store to a
store-pair.
It will only trigger if we can save two or more instructions, so it will
only transform:
 mov x1, 49370
 movkx1, 0xc0da, lsl 32
 str x1, [x0]

into:

 mov w1, 49370
 stp w1, w1, [x0]

when optimising for -Os, whereas it will always transform a 4-insn synthesis
sequence into a two-insn sequence + STP (see comments in the patch).

This patch triggers already but will trigger more with the store merging
pass
that I'm working on since that will generate more of these repeating 64-bit
constants.
This helps improve codegen on 456.hmmer where store merging can sometimes
create very
complex repeating constants and target-specific expand needs to break them
down.


Doing STP might be worse on ThunderX 1 than the mov/movk.  Or this
might cause an ICE with -mcpu=thunderx; I can't remember if the check
for slow unaligned store pair word is with the pattern or not.


I can't get it to ICE with -mcpu=thunderx.
The restriction is just on the STP forming code in the sched-fusion hooks AFAIK.


Basically the rule is
1) if 4 byte aligned, then it is better to do two str.
2) If 8 byte aligned, then doing stp is good
3) Otherwise it is better to do two str.


Ok, then I'll make the function just emit two stores and depend on the 
sched-fusion
machinery to fuse them into an STP when appropriate since that has the logic 
that
takes thunderx into account.



Here it is.
I've confirmed that it emits to STRs for 4 byte aligned stores when 
-mtune=thunderx
and still generates STP for the other tunings, though now sched-fusion is 
responsible for
merging them, which is ok by me.

Bootstrapped and tested on aarch64.
Ok for trunk?

Thanks,
Kyril


2016-11-01  Kyrylo Tkachov  

* config/aarch64/aarch64.md (mov): Call
aarch64_split_dimode_const_store on DImode constant stores.
* config/aarch64/aarch64-protos.h (aarch64_split_dimode_const_store):
New prototype.
* config/aarch64/aarch64.c (aarch64_split_dimode_const_store): New
function.

2016-11-01  Kyrylo Tkachov  

* gcc.target/aarch64/store_repeating_constant_1.c: New test.
* gcc.target/aarch64/store_repeating_constant_2.c: Likewise.






Thanks,
Andrew



Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

2016-10-24  Kyrylo Tkachov  

 * config/aarch64/aarch64.md (mov): Call
 aarch64_split_dimode_const_store on DImode constant stores.
 * config/aarch64/aarch64-protos.h (aarch64_split_dimode_const_store):
 New prototype.
 * config/aarch64/aarch64.c (aarch64_split_dimode_const_store): New
 function.

2016-10-24  Kyrylo Tkachov  

 * gcc.target/aarch64/store_repeating_constant_1.c: New test.
 * gcc.target/aarch64/store_repeating_constant_2.c: Likewise.

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Jason Merrill]

On 10/17/2016 03:18 PM, Bernd Edlinger wrote:

+@item -Wbuiltin-function-redefined @r{(C++ and Objective-C++ only)}
+@opindex Wbuiltin-function-redefined
+@opindex Wno-builtin-function-redefined
+Do warn if built-in functions are redefined.  This option is only
+supported for C++ and Objective-C++.  It is implied by @option{-Wall},
+which can be disabled with @option{-Wno-builtin-function-redefined}.


There's no redefinition here (only a redeclaration), so perhaps 
-Wbuiltin-redeclaration-mismatch?


I'm not even sure we need a new warning.  Can we combine this warning 
with the block that currently follows?



  else if ((DECL_EXTERN_C_P (newdecl)
&& DECL_EXTERN_C_P (olddecl))
   || compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)),
 TYPE_ARG_TYPES (TREE_TYPE (olddecl
{
  /* A near match; override the builtin.  */

  if (TREE_PUBLIC (newdecl))
warning_at (DECL_SOURCE_LOCATION (newdecl), 0,
"new declaration %q#D ambiguates built-in "
"declaration %q#D", newdecl, olddecl);
  else
warning (OPT_Wshadow,
 DECL_BUILT_IN (olddecl)
 ? G_("shadowing built-in function %q#D")
 : G_("shadowing library function %q#D"), olddecl);
}


It seems to me that if we have an extern "C" declaration that doesn't 
match the built-in, we should just warn.


I looked at some of the testcases you mentioned in the bug report, and 
those declarations aren't extern "C", so we shouldn't be warning about 
them.  Does your current patch still warn about those?


Jason

Re: [gcc] Enable DW_OP_VAL_EXPRESSION support in dwarf module

[Jiong Wang]

On 31/10/16 19:50, Jason Merrill wrote:

On 10/21/2016 04:30 AM, Jiong Wang wrote:

All DW_OP_* of the expression are grouped together inside the PARALLEL,
and those operations which don't have RTL mapping are wrapped by
UNSPEC.  The parsing algorithm is simply something like:

  foreach elem inside PARALLEL
if (UNSPEC)
  {
dw_op_code = INTVAL (XVECEXP (elem, 0, 0));
oprnd1 = INTVAL (XVECEXP (elem, 0, 1));
oprnd2 = INTVAL (XVECEXP (elem, 0, 2));
  }
else
  call standard RTL parser.

Any comments on the approach?


If you're going to use UNSPEC, why not put the DWARF operator in the 
second operand?


Hi Jason,

  Thanks for the review, but I still don't understand your meaning.

  Do you mean I should simply put the DWARF operator at XVECEXP 
(UNSPEC_RTX, 0, 2)
  instead of at XVECEXP (UNSPEC_RTX, 0, 0), and the new parsing 
algorithm will be

  the following ?

  foreach elem inside PARALLEL
if (UNSPEC)
  {
oprnd1 = INTVAL (XVECEXP (elem, 0, 0));
oprnd2 = INTVAL (XVECEXP (elem, 0, 1));
dw_op_code = INTVAL (XVECEXP (elem, 0, 2));
  }
else
  call standard RTL parser.

  I actually don't see the benefit of this change, could you please 
give more

  comments on this?

  For this patch, suppose the unwinding rule for register A is poping two
  values from dwarf evalutaion stack, do some complex processing based on
  the two values, then push back the result on to stack.

  We can generate the dwarf value expression description like:

   (set (reg A)
(parallel
  [(reg A) (reg B)
   (UNSPEC
 [(const_int DW_OP_XXX) (const0_rtx) (const0_rtx)]
UNSPEC_NUM)

   then readelf dump will be something like
   ===
   DW_CFA_val_expression: A (DW_OP_bregB: 0; DW_OP_bregC: 0; DW_OP_XXX)

We can't do such description based on current GCC dwarf code, right?

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>  
>  static void
>  maybe_optimize_var (tree var, bitmap addresses_taken, bitmap not_reg_needs,
> - bitmap suitable_for_renaming)
> + bitmap suitable_for_renaming, bitmap marked_nonaddressable)
>  {
>/* Global Variables, result decls cannot be changed.  */
>if (is_global_var (var)
> @@ -1522,6 +1523,7 @@ maybe_optimize_var (tree var, bitmap addresses_taken, 
> bitmap not_reg_needs,
> || !bitmap_bit_p (not_reg_needs, DECL_UID (var
>  {
>TREE_ADDRESSABLE (var) = 0;
> +  bitmap_set_bit (marked_nonaddressable, DECL_UID (var));

Why do you need the marked_nonaddressable bitmap?

>if (is_gimple_reg (var))
>   bitmap_set_bit (suitable_for_renaming, DECL_UID (var));
>if (dump_file)
> @@ -1550,20 +1552,43 @@ maybe_optimize_var (tree var, bitmap addresses_taken, 
> bitmap not_reg_needs,
>  }
>  }
>  
> -/* Compute TREE_ADDRESSABLE and DECL_GIMPLE_REG_P for local variables.  */
> +/* Return true when STMT is ASAN mark where second argument is an address
> +   of a local variable.  */
>  
> -void
> -execute_update_addresses_taken (void)
> +static bool
> +is_asan_mark_p (gimple *stmt)
> +{
> +  if (!gimple_call_internal_p (stmt, IFN_ASAN_MARK))
> +return false;
> +
> +  tree addr = get_base_address (gimple_call_arg (stmt, 1));
> +  if (TREE_CODE (addr) == ADDR_EXPR
> +  && TREE_CODE (TREE_OPERAND (addr, 0)) == VAR_DECL)

Just check here if dropping TREE_ADDRESSABLE from the VAR (use VAR_P btw)
would turn it into is_gimple_reg), and don't return true if not.

> +return true;
> +
> +  return false;
> +}
> +
> +/* Compute TREE_ADDRESSABLE and DECL_GIMPLE_REG_P for local variables.
> +   If SANITIZE_ASAN_MARK is set to true, sanitize also ASAN_MARK built-ins.  
> */
> +
> +
> +static void
> +execute_update_addresses_taken (bool sanitize_asan_mark = false)

I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property
set during the asan pass and kept on until end of compilation of that
function.  That means even if a var only addressable because of ASAN_MARK is
discovered after this pass we'd still be able to rewrite it into SSA.

Jakub

[PATCH, Fortran] Allow warnings given through gfc_error to associate with warning flags

[Fritz Reese]

All,

Currently warnings given by the GNU Fortran front-end typically
indicate which flag controls the warning, if any, as given by the
first argument to gfc_warning. However, there is no support for
controlling warnings which are emitted by gfc_error when
warnings_not_errors is set. Herein I propose a patch such that when a
call to gfc_error may cause a warning, suppression of the warning can
be controlled with a -W* warning flag, as with other warnings.

The simple patch extends the gfc_error interface to also accept an
additional 'opt' arg, which is passed as the same first argument to
gfc_warning if warnings_not_errors causes a warning instead of an
error. The old interface remains, so that a default 'opt' of 0 is
passed when gfc_error is called with no 'opt' argument. This minimizes
the impact of the interface change on existing code. Note also that if
the call to gfc_error would actually cause an error, the warning flag
will not suppress the error.

See the patch for details. Bootstraps and regtests on x86_64-redhat-linux.

Another patch proposal will follow which utilizes this functionality
to introduce a new warning -W[no-]argument-mismatch, assuming this one
is OK.

---
Fritz Reese

From: Fritz Reese 
Date: Thu, 27 Oct 2016 13:33:57 -0400
Subject: [PATCH] Allow warning flags to associate through gfc_error.

gcc/fortran/
* gfortran.h (gfc_error): New declaration for gfc_error with 'opt'.
* error.c (gfc_error): Add optional 'opt' argument.
* error.c (gfc_notify_std): Call fully-qualified gfc_error.
diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
index fe91419..0fd8a4e 100644
--- a/gcc/fortran/error.c
+++ b/gcc/fortran/error.c
@@ -67,7 +67,7 @@ gfc_push_suppress_errors (void)
 }
 
 static void
-gfc_error (const char *gmsgid, va_list ap)  ATTRIBUTE_GCC_GFC(1,0);
+gfc_error (int opt, const char *gmsgid, va_list ap)  ATTRIBUTE_GCC_GFC(2,0);
 
 static bool
 gfc_warning (int opt, const char *gmsgid, va_list ap) ATTRIBUTE_GCC_GFC(2,0);
@@ -902,7 +902,7 @@ gfc_notify_std (int std, const char *gmsgid, ...)
   if (warning)
 gfc_warning (0, buffer, argp);
   else
-gfc_error (buffer, argp);
+gfc_error (0, buffer, argp);
   va_end (argp);
 
   return (warning && !warnings_are_errors) ? true : false;
@@ -1233,7 +1233,7 @@ gfc_warning_check (void)
 /* Issue an error.  */
 
 static void
-gfc_error (const char *gmsgid, va_list ap)
+gfc_error (int opt, const char *gmsgid, va_list ap)
 {
   va_list argp;
   va_copy (argp, ap);
@@ -1241,7 +1241,7 @@ gfc_error (const char *gmsgid, va_list ap)
 
   if (warnings_not_errors)
 {
-  gfc_warning (/*opt=*/0, gmsgid, argp);
+  gfc_warning (opt, gmsgid, argp);
   va_end (argp);
   return;
 }
@@ -1289,11 +1289,21 @@ gfc_error (const char *gmsgid, va_list ap)
 
 
 void
+gfc_error (int opt, const char *gmsgid, ...)
+{
+  va_list argp;
+  va_start (argp, gmsgid);
+  gfc_error (opt, gmsgid, argp);
+  va_end (argp);
+}
+
+
+void
 gfc_error (const char *gmsgid, ...)
 {
   va_list argp;
   va_start (argp, gmsgid);
-  gfc_error (gmsgid, argp);
+  gfc_error (0, gmsgid, argp);
   va_end (argp);
 }
 
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index a0dcf6d..3fb6f41 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2731,6 +2731,7 @@ bool gfc_warning_now_at (location_t loc, int opt, const 
char *gmsgid, ...)
 void gfc_clear_warning (void);
 void gfc_warning_check (void);
 
+void gfc_error (int opt, const char *, ...) ATTRIBUTE_GCC_GFC(2,3);
 void gfc_error (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
 void gfc_error_now (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
 void gfc_fatal_error (const char *, ...) ATTRIBUTE_NORETURN 
ATTRIBUTE_GCC_GFC(1,2);

Re: [PATCH] Fix PR77407

[Marc Glisse]

On Mon, 31 Oct 2016, Richard Biener wrote:


On Fri, 28 Oct 2016, Marc Glisse wrote:


On Wed, 28 Sep 2016, Richard Biener wrote:


The following patch implements patterns to catch x / abs (x)
and x / -x, taking advantage of undefinedness at x == 0 as
opposed to the PR having testcases with explicit != 0 checks.

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

Richard.

2016-09-28  Richard Biener  

PR middle-end/77407
* match.pd: Add X / abs (X) -> X < 0 ? -1 : 1 and
X / -X -> -1 simplifications.


I notice that we still have the following comment a few lines above:

/* Make sure to preserve divisions by zero.  This is the reason why
   we don't simplify x / x to 1 or 0 / x to 0.  */

Did we give up on preserving divisions by 0? Can we now do the 2
simplifications listed by the comment?


At some point there was at least diagnostics fallout when doing them.
There may be also undefined sanitizer fallout depending on when we
instrument for that.

But in general yes, we do want to do the two simplifications.  Maybe
we can compromise (in case of early fallout) to do them on GIMPLE
only.

We could at least add them with a proper nonzero_p predicate.


 (for div (trunc_div ceil_div floor_div round_div exact_div)
+ (simplify (div @0 @0) { build_one_cst (type); })
+ (simplify (div integer_zerop@0 @1) @0)

causes no regression on powerpc64le-unknown-linux-gnu with 
--enable-languages=all,obj-c++,go.


--
Marc Glisse

Re: [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Jason Merrill]

On 10/17/2016 03:18 PM, Bernd Edlinger wrote:

Regarding this hunk:

/* Whether or not the builtin can throw exceptions has no
  bearing on this declarator.  */
-  TREE_NOTHROW (olddecl) = 0;
+  TREE_NOTHROW (olddecl) = TREE_NOTHROW (newdecl);

You may ask, why the old code was working most of the time.
I think, usually, when types_match == true, there happens another
assignment to TREE_NOTHROW, later in that function around line 2183:

   /* Merge the type qualifiers.  */
   if (TREE_READONLY (newdecl))
 TREE_READONLY (olddecl) = 1;
   if (TREE_THIS_VOLATILE (newdecl))
 TREE_THIS_VOLATILE (olddecl) = 1;
   if (TREE_NOTHROW (newdecl))
 TREE_NOTHROW (olddecl) = 1;

This is in a big "if (types_match)", so I think that explains,
why the old code did work normally, and why it fails if the
parameter don't match, but I still have no idea what to say
in the comment, except that the code should exactly do what
the comment above says.


I think a better fix would be to add a copy of TREE_NOTHROW to the else 
block of the if (types_match), to go with the existing copies of 
TREE_READONLY and TREE_THIS_VOLATILE.  But yes, duplicate_decls is a mess.


Jason

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Martin Liška]

On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
> On Tue, Nov 01, 2016 at 03:47:54PM +0100, Martin Liška wrote:
>> On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
>>> Ok for trunk with that change.
>>>
>>> Jakub
>>
>> Hello.
>>
>> I'll commit the patch as soon as following patch would be accepted. The patch
>> fixes false positives when running asan-bootstrap.
> 
> What kind of false positives it is for each case?  Is it with normal
> asan-bootstrap (without your -fsanitize-use-after-scope changes), or
> only with those changes, or only with those changes and
> -fsanitize-use-after-scope used during bootstrap?

It's only with those changes as -fsanitize-address-use-after-scope is enabled by
default with -fsanitize=address. Current bootstrap-asan works fine. I'll 
re-trigger
the bootstrap again, but IIRC the main culprit was ASAN_MARK poisoning done at 
switch labels
(which should be partially fixed with a newer version of the patch).

Martin

> 
>> >From b62e4d7ffe659ec338ef83e84ccb572a07264283 Mon Sep 17 00:00:00 2001
>> From: marxin 
>> Date: Tue, 20 Sep 2016 10:31:25 +0200
>> Subject: [PATCH 1/4] Fix ASAN bootstrap uninitialized warning.
>>
>> gcc/ChangeLog:
>>
>> 2016-09-26  Martin Liska  
>>
>>  * ipa-devirt.c (record_targets_from_bases): Initialize a
>>  variable.
>>  * omp-low.c (lower_omp_target): Remove a variable from
>>  scope defined by a switch statement.
>>  * tree-dump.c (dequeue_and_dump): Likewise.
>>
>> gcc/java/ChangeLog:
>>
>> 2016-09-26  Martin Liska  
>>
>>  * mangle.c (mangle_type): Remove a variable from
>>  scope defined by a switch statement.
>> ---
>>  gcc/ipa-devirt.c |  2 +-
>>  gcc/omp-low.c| 11 ---
>>  gcc/tree-dump.c  |  8 +++-
>>  3 files changed, 8 insertions(+), 13 deletions(-)
>>
>> diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
>> index 49e2195..5c0ae72 100644
>> --- a/gcc/ipa-devirt.c
>> +++ b/gcc/ipa-devirt.c
>> @@ -2862,7 +2862,7 @@ record_targets_from_bases (tree otr_type,
>>  {
>>while (true)
>>  {
>> -  HOST_WIDE_INT pos, size;
>> +  HOST_WIDE_INT pos = 0, size;
>>tree base_binfo;
>>tree fld;
>>  
>> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
>> index e5b9e4c..62c9e5c 100644
>> --- a/gcc/omp-low.c
>> +++ b/gcc/omp-low.c
>> @@ -15803,11 +15803,10 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
>> omp_context *ctx)
>>push_gimplify_context ();
>>fplist = NULL;
>>  
>> +  tree var, x;
>>for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
>>  switch (OMP_CLAUSE_CODE (c))
>>{
>> -tree var, x;
>> -
>>default:
>>  break;
>>case OMP_CLAUSE_MAP:
>> @@ -16066,12 +16065,11 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
>> omp_context *ctx)
>>vec_alloc (vkind, map_cnt);
>>unsigned int map_idx = 0;
>>  
>> +  tree ovar, nc, s, purpose, var, x, type;
>> +  unsigned int talign;
>>for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
>>  switch (OMP_CLAUSE_CODE (c))
>>{
>> -tree ovar, nc, s, purpose, var, x, type;
>> -unsigned int talign;
>> -
>>default:
>>  break;
>>  
>> @@ -16442,10 +16440,10 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
>> omp_context *ctx)
>>if (offloaded || data_region)
>>  {
>>tree prev = NULL_TREE;
>> +  tree var, x;
>>for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
>>  switch (OMP_CLAUSE_CODE (c))
>>{
>> -tree var, x;
>>default:
>>  break;
>>case OMP_CLAUSE_FIRSTPRIVATE:
>> @@ -16594,7 +16592,6 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
>> omp_context *ctx)
>>for (c = clauses; c; c = OMP_CLAUSE_CHAIN (c))
>>  switch (OMP_CLAUSE_CODE (c))
>>{
>> -tree var;
>>default:
>>  break;
>>case OMP_CLAUSE_MAP:
>> diff --git a/gcc/tree-dump.c b/gcc/tree-dump.c
>> index df47181..89f72a0 100644
>> --- a/gcc/tree-dump.c
>> +++ b/gcc/tree-dump.c
>> @@ -420,8 +420,6 @@ dequeue_and_dump (dump_info_p di)
>>/* Now handle the various kinds of nodes.  */
>>switch (code)
>>  {
>> -  int i;
>> -
>>  case IDENTIFIER_NODE:
>>dump_string_field (di, "strg", IDENTIFIER_POINTER (t));
>>dump_int (di, "lngt", IDENTIFIER_LENGTH (t));
>> @@ -435,6 +433,7 @@ dequeue_and_dump (dump_info_p di)
>>  
>>  case STATEMENT_LIST:
>>{
>> +int i;
>>  tree_stmt_iterator it;
>>  for (i = 0, it = tsi_start (t); !tsi_end_p (it); tsi_next (), i++)
>>{
>> @@ -447,7 +446,7 @@ dequeue_and_dump (dump_info_p di)
>>  
>>  case TREE_VEC:
>>dump_int (di, "lngt", TREE_VEC_LENGTH (t));
>> -  for (i = 0; i < TREE_VEC_LENGTH (t); ++i)
>> +  for (int i = 0; i < TREE_VEC_LENGTH (t); ++i)
>>  {
>>char buffer[32];
>>sprintf (buffer, "%u", i);
>> @@ -707,9 +706,8 @@ dequeue_and_dump (dump_info_p di)
>>break;
>>  case OMP_CLAUSE:

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Martin Liška]

On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
> On Thu, Oct 27, 2016 at 04:40:30PM +0200, Martin Liška wrote:
>> On 10/21/2016 04:26 PM, Jakub Jelinek wrote:
>>> On Wed, Oct 12, 2016 at 04:07:53PM +0200, Martin Liška wrote:
> Ok, first let me list some needed follow-ups that don't need to be handled
> right away:
> - r237814-like changes for ASAN_MARK
>>
>> I've spent quite some on that and that's what I begin 
>> (use-after-scope-addressable.patch).
>> Problem is that as I ignore all ASAN_MARK internal fns, the code does not 
>> detect having address
>> taken in:
>>
>> _2 = MEM[(char *)_char + 8B];
>>
>>   char *ptr;
>>   {
>> char my_char[9];
>> ptr = _char[0];
>>   }
>>
>>   return *(ptr+8);
>>
>> and thus the code in tree-ssa.c (maybe_optimize_var) sets TREE_ADDRESSABLE 
>> (var) = 0.
> 
> Perhaps we should do that only if the var's type is_gimple_reg_type,
> then we'd rewrite that into SSA at that time, right?  So, in theory if we
> turned the ASAN_MARK poisoning call into another internal function
> (var_5 = ASAN_POISON ()) and then after converting it into SSA looked at
> all the uses of such an lhs and perhaps at sanopt part or when marked all
> the use places with a library call that would complain at runtime?
> Or turn those back at sanopt time into addressable memory loads which would
> be poisoned or similar?  Or alternatively, immediately before turning
> variables addressable just because of ASAN_MARK into non-addressable use
> the same framework into-ssa uses to find out if there are any poisoned
> accesses, and just not optimize it in that case.
> Anyway, this can be done incrementally.

I've done a patch candidate (not tested yet) which is capable of ASAN_MARK 
removal
for local variables that can be rewritten into SSA. This is done by running 
execute_update_addresses_taken
after we create ASAN_CHECK internal fns and skipping all ASAN_MARK for having 
address taken considerations.
This removes significant number of ASAN_MARK fns in tramp3d (due to C++ 
temporaries).

> 
>> Second question I have is whether we want to handle just TREE_ADDRESSABLE 
>> stuff during gimplification?
>> Basically in a way that the current patch is doing?
> 
> How could variables that aren't TREE_ADDRESSABLE during gimplification be
> accessed out of scope?

Yep, TREE_ADDRESSABLE guard does what it should do.

I'm going to test the patch which can be installed incrementally.

Martin

> 
>> +/* Return true if DECL should be guarded on the stack.  */
>> +
>> +static inline bool
>> +asan_protect_stack_decl (tree decl)
>> +{
>> +  return DECL_P (decl)
>> +&& (!DECL_ARTIFICIAL (decl)
>> +|| (asan_sanitize_use_after_scope () && TREE_ADDRESSABLE (decl)));
> 
> Bad formatting.  Should be:
> 
>   return (DECL_P (decl)
> && (!DECL_ARTIFICIAL (decl)
> || (asan_sanitize_use_after_scope ()
> && TREE_ADDRESSABLE (decl;
> 
> Ok for trunk with that change.
> 
>   Jakub
> 

>From cf860324da41244745f04a16b184fabe343ac5d9 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 1 Nov 2016 11:21:20 +0100
Subject: [PATCH 4/4] Use-after-scope: do not mark variables that are no longer
 addressable

gcc/ChangeLog:

2016-11-01  Martin Liska  

	* asan.c (asan_instrument): Call
	execute_update_addresses_taken_asan_sanitize right after
	sanitization.
	* tree-ssa.c (maybe_optimize_var): Mark all variables set to
	non-addressable.
	(is_asan_mark_p): New function.
	(execute_update_addresses_taken): Likewise.
	(execute_update_addresses_taken_asan_sanitize): Likewise.
	* tree-ssa.h (execute_update_addresses_taken_asan_sanitize):
	Declare new function.
---
 gcc/asan.c |  4 +++
 gcc/tree-ssa.c | 96 +++---
 gcc/tree-ssa.h |  1 +
 3 files changed, 84 insertions(+), 17 deletions(-)

diff --git a/gcc/asan.c b/gcc/asan.c
index 95495d2..5cb37c8 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -59,6 +59,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "params.h"
 #include "builtins.h"
 #include "fnmatch.h"
+#include "tree-ssa.h"
 
 /* AddressSanitizer finds out-of-bounds and use-after-free bugs
with <2x slowdown on average.
@@ -2973,6 +2974,9 @@ asan_instrument (void)
   if (shadow_ptr_types[0] == NULL_TREE)
 asan_init_shadow_ptr_types ();
   transform_statements ();
+
+  if (optimize)
+execute_update_addresses_taken_asan_sanitize ();
   return 0;
 }
 
diff --git a/gcc/tree-ssa.c b/gcc/tree-ssa.c
index 135952b..0633b21 100644
--- a/gcc/tree-ssa.c
+++ b/gcc/tree-ssa.c
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfgexpand.h"
 #include "tree-cfg.h"
 #include "tree-dfa.h"
+#include "asan.h"
 
 /* Pointer map of variable mappings, keyed by edge.  */
 static hash_map *edge_var_maps;
@@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
 
 static void
 maybe_optimize_var (tree var, bitmap addresses_taken, bitmap not_reg_needs,
-		 

[PING**2] [PATCH, C++] Warn on redefinition of builtin functions (PR c++/71973)

[Bernd Edlinger]

Ping...

On 10/24/16 15:36, Bernd Edlinger wrote:
> Hi!
>
> I'd like to ping for my patch here:
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01348.html
>
>
> Thanks
> Bernd.
>
> On 10/17/16 21:18, Bernd Edlinger wrote:
>> On 10/17/16 20:05, Joseph Myers wrote:
>>> On Sun, 16 Oct 2016, Bernd Edlinger wrote:
>>>
 Second, the declaration in the glibc header files simply look wrong,
 because the type of argv, and envp is "char *const *" while the
 builtin function wants "const char**", thus only the array of char*
 itself is const, not the actual char stings they point to.
>>>
>>> char *const * is the POSIX type.  (It can't be const char ** or const
>>> char
>>> *const * because you can't convert char ** implicitly to those types in
>>> ISO C.)  You'd need to check the list archives for rationale for the
>>> built-in functions doing something different.
>>>
>>
>> Yes, that was discussed here:
>> https://gcc.gnu.org/ml/gcc-patches/2004-03/msg01148.html
>>
>> No mention why the BT_PTR_CONST_TYPE does not match the posix type.
>> But the right types were used on __gcov_execv/e/p stubs, so the author
>> did know the right types at least.
>>
>> So I think that was broken from the beginning, but that was hidden by
>> the loose checking in the C FE and not warning in the C++ FE when
>> prototypes don't match.
>>
 Third, in C the  builtins are not diagnosed, because C does only look
 at the mode of the parameters see match_builtin_function_types in
 c/c-decl.c, which may itself be wrong, because that makes an ABI
 decision dependent on the mode of the parameter.
>>>
>>> The matching needs to be loose because of functions using types such as
>>> FILE * where the compiler doesn't know the exact contents of the type
>>> when
>>> processing built-in function definitions.  (Historically there were also
>>> issues with pre-ISO headers, but that may be less relevant now.)
>>>
>>
>> The C++ FE has exactly the same problem with FILE* and struct tm*
>> but it solves it differently and "learns" the type but only for FILE*
>> and with this patch also for const struct tm*.  It is a lot more
>> restrictive than C, but that is because of the ++ ;)
>>
>> Well in that case the posix functions have to use the prototypes
>> from POSIX.1.2008 although their rationale is a bit silly...
>>
>> This updated patch fixes the prototype of execv/p/e,
>> and adds a new test case that checks that no type conflict
>> exists in the execve built-in any more.
>>
>> Now we have no -Wsystem-headers warnings with glibc-headers any more.
>> And the gcov builtin also is working with C++.
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 03:47:54PM +0100, Martin Liška wrote:
> On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
> > Ok for trunk with that change.
> > 
> > Jakub
> 
> Hello.
> 
> I'll commit the patch as soon as following patch would be accepted. The patch
> fixes false positives when running asan-bootstrap.

What kind of false positives it is for each case?  Is it with normal
asan-bootstrap (without your -fsanitize-use-after-scope changes), or
only with those changes, or only with those changes and
-fsanitize-use-after-scope used during bootstrap?

> >From b62e4d7ffe659ec338ef83e84ccb572a07264283 Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Tue, 20 Sep 2016 10:31:25 +0200
> Subject: [PATCH 1/4] Fix ASAN bootstrap uninitialized warning.
> 
> gcc/ChangeLog:
> 
> 2016-09-26  Martin Liska  
> 
>   * ipa-devirt.c (record_targets_from_bases): Initialize a
>   variable.
>   * omp-low.c (lower_omp_target): Remove a variable from
>   scope defined by a switch statement.
>   * tree-dump.c (dequeue_and_dump): Likewise.
> 
> gcc/java/ChangeLog:
> 
> 2016-09-26  Martin Liska  
> 
>   * mangle.c (mangle_type): Remove a variable from
>   scope defined by a switch statement.
> ---
>  gcc/ipa-devirt.c |  2 +-
>  gcc/omp-low.c| 11 ---
>  gcc/tree-dump.c  |  8 +++-
>  3 files changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
> index 49e2195..5c0ae72 100644
> --- a/gcc/ipa-devirt.c
> +++ b/gcc/ipa-devirt.c
> @@ -2862,7 +2862,7 @@ record_targets_from_bases (tree otr_type,
>  {
>while (true)
>  {
> -  HOST_WIDE_INT pos, size;
> +  HOST_WIDE_INT pos = 0, size;
>tree base_binfo;
>tree fld;
>  
> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index e5b9e4c..62c9e5c 100644
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -15803,11 +15803,10 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
>push_gimplify_context ();
>fplist = NULL;
>  
> +  tree var, x;
>for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
>  switch (OMP_CLAUSE_CODE (c))
>{
> - tree var, x;
> -
>default:
>   break;
>case OMP_CLAUSE_MAP:
> @@ -16066,12 +16065,11 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
>vec_alloc (vkind, map_cnt);
>unsigned int map_idx = 0;
>  
> +  tree ovar, nc, s, purpose, var, x, type;
> +  unsigned int talign;
>for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
>   switch (OMP_CLAUSE_CODE (c))
> {
> - tree ovar, nc, s, purpose, var, x, type;
> - unsigned int talign;
> -
> default:
>   break;
>  
> @@ -16442,10 +16440,10 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
>if (offloaded || data_region)
>  {
>tree prev = NULL_TREE;
> +  tree var, x;
>for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
>   switch (OMP_CLAUSE_CODE (c))
> {
> - tree var, x;
> default:
>   break;
> case OMP_CLAUSE_FIRSTPRIVATE:
> @@ -16594,7 +16592,6 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, 
> omp_context *ctx)
>for (c = clauses; c; c = OMP_CLAUSE_CHAIN (c))
>   switch (OMP_CLAUSE_CODE (c))
> {
> - tree var;
> default:
>   break;
> case OMP_CLAUSE_MAP:
> diff --git a/gcc/tree-dump.c b/gcc/tree-dump.c
> index df47181..89f72a0 100644
> --- a/gcc/tree-dump.c
> +++ b/gcc/tree-dump.c
> @@ -420,8 +420,6 @@ dequeue_and_dump (dump_info_p di)
>/* Now handle the various kinds of nodes.  */
>switch (code)
>  {
> -  int i;
> -
>  case IDENTIFIER_NODE:
>dump_string_field (di, "strg", IDENTIFIER_POINTER (t));
>dump_int (di, "lngt", IDENTIFIER_LENGTH (t));
> @@ -435,6 +433,7 @@ dequeue_and_dump (dump_info_p di)
>  
>  case STATEMENT_LIST:
>{
> + int i;
>   tree_stmt_iterator it;
>   for (i = 0, it = tsi_start (t); !tsi_end_p (it); tsi_next (), i++)
> {
> @@ -447,7 +446,7 @@ dequeue_and_dump (dump_info_p di)
>  
>  case TREE_VEC:
>dump_int (di, "lngt", TREE_VEC_LENGTH (t));
> -  for (i = 0; i < TREE_VEC_LENGTH (t); ++i)
> +  for (int i = 0; i < TREE_VEC_LENGTH (t); ++i)
>   {
> char buffer[32];
> sprintf (buffer, "%u", i);
> @@ -707,9 +706,8 @@ dequeue_and_dump (dump_info_p di)
>break;
>  case OMP_CLAUSE:
>{
> - int i;
>   fprintf (di->stream, "%s\n", omp_clause_code_name[OMP_CLAUSE_CODE (t)]);
> - for (i = 0; i < omp_clause_num_ops[OMP_CLAUSE_CODE (t)]; i++)
> + for (int i = 0; i < omp_clause_num_ops[OMP_CLAUSE_CODE (t)]; i++)
> dump_child ("op: ", OMP_CLAUSE_OPERAND (t, i));
>}
>break;
> -- 
> 2.10.1
> 


Jakub

Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2)

[Martin Liška]

On 10/27/2016 07:23 PM, Jakub Jelinek wrote:
> Ok for trunk with that change.
> 
>   Jakub

Hello.

I'll commit the patch as soon as following patch would be accepted. The patch
fixes false positives when running asan-bootstrap.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From b62e4d7ffe659ec338ef83e84ccb572a07264283 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 20 Sep 2016 10:31:25 +0200
Subject: [PATCH 1/4] Fix ASAN bootstrap uninitialized warning.

gcc/ChangeLog:

2016-09-26  Martin Liska  

	* ipa-devirt.c (record_targets_from_bases): Initialize a
	variable.
	* omp-low.c (lower_omp_target): Remove a variable from
	scope defined by a switch statement.
	* tree-dump.c (dequeue_and_dump): Likewise.

gcc/java/ChangeLog:

2016-09-26  Martin Liska  

	* mangle.c (mangle_type): Remove a variable from
	scope defined by a switch statement.
---
 gcc/ipa-devirt.c |  2 +-
 gcc/omp-low.c| 11 ---
 gcc/tree-dump.c  |  8 +++-
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 49e2195..5c0ae72 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -2862,7 +2862,7 @@ record_targets_from_bases (tree otr_type,
 {
   while (true)
 {
-  HOST_WIDE_INT pos, size;
+  HOST_WIDE_INT pos = 0, size;
   tree base_binfo;
   tree fld;
 
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index e5b9e4c..62c9e5c 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -15803,11 +15803,10 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, omp_context *ctx)
   push_gimplify_context ();
   fplist = NULL;
 
+  tree var, x;
   for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
 switch (OMP_CLAUSE_CODE (c))
   {
-	tree var, x;
-
   default:
 	break;
   case OMP_CLAUSE_MAP:
@@ -16066,12 +16065,11 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, omp_context *ctx)
   vec_alloc (vkind, map_cnt);
   unsigned int map_idx = 0;
 
+  tree ovar, nc, s, purpose, var, x, type;
+  unsigned int talign;
   for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
 	switch (OMP_CLAUSE_CODE (c))
 	  {
-	tree ovar, nc, s, purpose, var, x, type;
-	unsigned int talign;
-
 	  default:
 	break;
 
@@ -16442,10 +16440,10 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, omp_context *ctx)
   if (offloaded || data_region)
 {
   tree prev = NULL_TREE;
+  tree var, x;
   for (c = clauses; c ; c = OMP_CLAUSE_CHAIN (c))
 	switch (OMP_CLAUSE_CODE (c))
 	  {
-	tree var, x;
 	  default:
 	break;
 	  case OMP_CLAUSE_FIRSTPRIVATE:
@@ -16594,7 +16592,6 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, omp_context *ctx)
   for (c = clauses; c; c = OMP_CLAUSE_CHAIN (c))
 	switch (OMP_CLAUSE_CODE (c))
 	  {
-	tree var;
 	  default:
 	break;
 	  case OMP_CLAUSE_MAP:
diff --git a/gcc/tree-dump.c b/gcc/tree-dump.c
index df47181..89f72a0 100644
--- a/gcc/tree-dump.c
+++ b/gcc/tree-dump.c
@@ -420,8 +420,6 @@ dequeue_and_dump (dump_info_p di)
   /* Now handle the various kinds of nodes.  */
   switch (code)
 {
-  int i;
-
 case IDENTIFIER_NODE:
   dump_string_field (di, "strg", IDENTIFIER_POINTER (t));
   dump_int (di, "lngt", IDENTIFIER_LENGTH (t));
@@ -435,6 +433,7 @@ dequeue_and_dump (dump_info_p di)
 
 case STATEMENT_LIST:
   {
+	int i;
 	tree_stmt_iterator it;
 	for (i = 0, it = tsi_start (t); !tsi_end_p (it); tsi_next (), i++)
 	  {
@@ -447,7 +446,7 @@ dequeue_and_dump (dump_info_p di)
 
 case TREE_VEC:
   dump_int (di, "lngt", TREE_VEC_LENGTH (t));
-  for (i = 0; i < TREE_VEC_LENGTH (t); ++i)
+  for (int i = 0; i < TREE_VEC_LENGTH (t); ++i)
 	{
 	  char buffer[32];
 	  sprintf (buffer, "%u", i);
@@ -707,9 +706,8 @@ dequeue_and_dump (dump_info_p di)
   break;
 case OMP_CLAUSE:
   {
-	int i;
 	fprintf (di->stream, "%s\n", omp_clause_code_name[OMP_CLAUSE_CODE (t)]);
-	for (i = 0; i < omp_clause_num_ops[OMP_CLAUSE_CODE (t)]; i++)
+	for (int i = 0; i < omp_clause_num_ops[OMP_CLAUSE_CODE (t)]; i++)
 	  dump_child ("op: ", OMP_CLAUSE_OPERAND (t, i));
   }
   break;
-- 
2.10.1

Re: [patch, fortran] Fix PR 69544

[Dominique d'Humières]

Hi Thomas,

> the attached, rather simple, patch, fixes a regression where
> the locus was not set, leading to an ICE on a warning.
Looking for the occurrences of gfc_clear_new_st in fortran/match.c, I have 
found it in the following procs:

gfc_match_if
match_simple_forall
gfc_match_forall
match_simple_where
gfc_match_where

In the first three, gfc_current_locus is provided, but not in the last two. The 
patch fixes the ICE due to the missing gfc_current_locus in the last one, but 
the same should be applied to match_simple_where, otherwise one gets an ICE for 
statements such as

if (n==10) where (txt(1:3) /= ''   )  y(1:3,i,j) = txt(1:3)

Note that there is no comment explaining the need of gfc_current_locus where it 
is presently implemented. Is the new comment really needed?

IMO a similar audit should be performed for fortran/parse.c (11 occurrences of 
gfc_clear_new_st).

Thanks for taking care of this issue,

Dominique

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

[Jakub Jelinek]

On Mon, Oct 31, 2016 at 08:39:15PM -0600, Martin Sebor wrote:
> Attached is an updated patch that works around the problem with
> the definition of the NOTE_DATA macro discussed below.  I've
> raised bug 78174 for it and temporarily worked around it in
> the patch.  I'll see if I can come up with a patch to fix the
> macro the "right way" but would prefer to do that separately.
> The NOTE_DATA macro is implemented in terms of the RTL_CHECK1
> macro that will need to change and that macro is used in many
> others, so I would rather not mess around with those as part
> of this patch.

No, you just shouldn't use __bos (*, 1) in the warning code
for mem* like builtins.

Jakub

libgo patch committed: Add functions used by cgo

[Ian Lance Taylor]

When using the cgo tool with the -gccgo option, calls to C.GoString,
C.GoStringN, and C.GoBytes will be translated into calls to
__go_byte_array_to_string and __go_string_to_byte_array.  Those
functions were removed when the string code was copied from Go 1.7,
but we still need them for cgo.  While cgo should be updated, old
versions will exist for some time.  So this patch adds the functions
to libgo so that they are available for use by cgo.  Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241742)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-90f12ac1fa72a95e73cb88b6114fa3131c4ca8ee
+069ed35ecbefd2f138ea3132a557ad23a6936a45
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/string.go
===
--- libgo/go/runtime/string.go  (revision 241341)
+++ libgo/go/runtime/string.go  (working copy)
@@ -444,3 +444,20 @@ func gostringw(strw *uint16) string {
b[n2] = 0 // for luck
return s[:n2]
 }
+
+// These two functions are called by code generated by cgo -gccgo.
+
+//go:linkname __go_byte_array_to_string __go_byte_array_to_string
+func __go_byte_array_to_string(p unsafe.Pointer, l int) string {
+   if l == 0 {
+   return ""
+   }
+   s, c := rawstringtmp(nil, l)
+   memmove(unsafe.Pointer([0]), p, uintptr(l))
+   return s
+}
+
+//go:linkname __go_string_to_byte_array __go_string_to_byte_array
+func __go_string_to_byte_array(s string) []byte {
+   return stringtoslicebyte(nil, s)
+}

Re: [patch, fortran] Fix PR 69544

[Steve Kargl]

On Tue, Nov 01, 2016 at 11:58:10AM +0100, Thomas Koenig wrote:
> 
> the attached, rather simple, patch, fixes a regression where
> the locus was not set, leading to an ICE on a warning.
> 
> Regression-tested on trunk. OK on all affected and open branches
> (7/6/5)?
> 

Yes.

-- 
Steve

[Patch AArch64] aarch64-c.o should depend on TARGET_H

[James Greenhalgh]

Hi,

I've noticed that aarch64-c.o doesn't get rebuilt after a change to
the target hooks. That leaves it out of sync with the rest of the compiler
in incremental builds, which in turn causes this code to write to the wrong
memory location:

  void
  aarch64_register_pragmas (void)
  {
/* Update pragma hook to allow parsing #pragma GCC target.  */
targetm.target_option.pragma_parse = aarch64_pragma_target_parse;
  }

Leaving pragma_parse pointing at the default implementation, and mangling
poor innocent targetm.target_option.print (which generally we don't use
after the rebuild - else we likely would see it here too).

This change adds a dependency on target.h to aarch64-c.o in t-aarch64,
which looks correct.

Thanks,
James

---
2016-11-01  James Greenhalgh  

* config/aarch64/t-aarch64 (aarch64-c.o): Depend on TARGET_H.

diff --git a/gcc/config/aarch64/t-aarch64 b/gcc/config/aarch64/t-aarch64
index 04eb636..b461eb5 100644
--- a/gcc/config/aarch64/t-aarch64
+++ b/gcc/config/aarch64/t-aarch64
@@ -52,7 +52,7 @@ aarch-common.o: $(srcdir)/config/arm/aarch-common.c $(CONFIG_H) $(SYSTEM_H) \
 		$(srcdir)/config/arm/aarch-common.c
 
 aarch64-c.o: $(srcdir)/config/aarch64/aarch64-c.c $(CONFIG_H) $(SYSTEM_H) \
-coretypes.h $(TM_H) $(TREE_H) output.h $(C_COMMON_H)
+coretypes.h $(TM_H) $(TREE_H) output.h $(C_COMMON_H) $(TARGET_H)
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 		$(srcdir)/config/aarch64/aarch64-c.c
 

Re: [PATCH] Emit DWARF5 DW_AT_reference and DW_AT_rvalue_reference

[Jakub Jelinek]

On Mon, Oct 31, 2016 at 09:56:28AM -0400, Jason Merrill wrote:
> >Or by changing get_qualified_die (in particular check_base_type) to use a
> >langhook, we could at least for DW_AT_{reference,rvalue_reference} just use
> >equate_type_number_to_die/lookup_type_die reliably (DW_AT_endianity issue
> >remains).
> 
> Yeah, I think that adding a langhook is the right way to go.  The generic
> code clobbering C++ qualifiers is a frequent headache.

I've tried to implement that, but am getting some TYPE_CANONICAL differences
because of that, and am really lost what the problem is and how to fix it.
Furthermore, I bet the exception specification also should be considered in
that langhook.

The testcase I've been trying is:

struct S
{
  void foo1 ();
  void bar1 () &;
  void baz1 () &&;
  void foo2 () const;
  void bar2 () const &;
  void baz2 () const &&;
  void foo3 () const;
  void bar3 () const &;
  void baz3 () const &&;
};

void
test ()
{
  S s;
  auto o1 = ::foo1;
  auto r1 = ::bar1;
  auto z1 = ::baz1;
  auto o2 = ::foo2;
  auto r2 = ::bar2;
  auto z2 = ::baz2;
  auto o3 = ::foo3;
  auto r3 = ::bar3;
  auto z3 = ::baz3;
  void (S::*o4) () const;
  o4 = ::foo3;
  void (S::*r4) () const &;
  r4 = ::bar3;
  void (S::*z4) () const &&;
  z4 = ::baz3;
  (s.*o1) ();
  (s.*r1) ();
  (S ().*z1) ();
  (s.*o2) ();
  (s.*r2) ();
  (S ().*z2) ();
  (s.*o3) ();
  (s.*r3) ();
  (S ().*z3) ();
  (s.*o4) ();
  (s.*r4) ();
  (S ().*z4) ();
}

--- gcc/hooks.h.jj  2016-10-31 13:28:06.0 +0100
+++ gcc/hooks.h 2016-11-01 12:55:33.662494341 +0100
@@ -59,6 +59,7 @@ extern bool hook_bool_rtx_mode_int_int_i
int, int, int *, bool);
 extern bool hook_bool_tree_tree_false (tree, tree);
 extern bool hook_bool_tree_tree_true (tree, tree);
+extern bool hook_bool_const_tree_const_tree_true (const_tree, const_tree);
 extern bool hook_bool_tree_bool_false (tree, bool);
 extern bool hook_bool_wint_wint_uint_bool_true (const widest_int &,
const widest_int &,
--- gcc/cp/cp-objcp-common.h.jj 2016-10-31 13:28:11.0 +0100
+++ gcc/cp/cp-objcp-common.h2016-11-01 12:56:44.446605921 +0100
@@ -27,6 +27,8 @@ extern tree objcp_tsubst_copy_and_build
 tree, bool);
 
 extern int cp_decl_dwarf_attribute (const_tree, int);
+extern int cp_type_dwarf_attribute (const_tree, int);
+extern bool cp_check_base_type (const_tree, const_tree);
 extern void cp_common_init_ts (void);
 
 /* Lang hooks that are shared between C++ and ObjC++ are defined here.  Hooks
@@ -131,6 +133,10 @@ extern void cp_common_init_ts (void);
 #define LANG_HOOKS_GIMPLIFY_EXPR cp_gimplify_expr
 #undef LANG_HOOKS_DECL_DWARF_ATTRIBUTE
 #define LANG_HOOKS_DECL_DWARF_ATTRIBUTE cp_decl_dwarf_attribute
+#undef LANG_HOOKS_TYPE_DWARF_ATTRIBUTE
+#define LANG_HOOKS_TYPE_DWARF_ATTRIBUTE cp_type_dwarf_attribute
+#undef LANG_HOOKS_CHECK_BASE_TYPE
+#define LANG_HOOKS_CHECK_BASE_TYPE cp_check_base_type
 #undef LANG_HOOKS_OMP_PREDETERMINED_SHARING
 #define LANG_HOOKS_OMP_PREDETERMINED_SHARING cxx_omp_predetermined_sharing
 #undef LANG_HOOKS_OMP_CLAUSE_DEFAULT_CTOR
--- gcc/cp/cp-objcp-common.c.jj 2016-11-01 14:39:29.308309164 +0100
+++ gcc/cp/cp-objcp-common.c2016-11-01 14:22:40.135992547 +0100
@@ -179,11 +179,6 @@ cp_decl_dwarf_attribute (const_tree decl
  && FUNCTION_REF_QUALIFIED (TREE_TYPE (decl))
  && !FUNCTION_RVALUE_QUALIFIED (TREE_TYPE (decl)))
return 1;
-  if ((TREE_CODE (decl) == FUNCTION_TYPE
-  || TREE_CODE (decl) == METHOD_TYPE)
- && FUNCTION_REF_QUALIFIED (decl)
- && !FUNCTION_RVALUE_QUALIFIED (decl))
-   return 1;
   break;
 
 case DW_AT_rvalue_reference:
@@ -192,11 +187,6 @@ cp_decl_dwarf_attribute (const_tree decl
  && FUNCTION_REF_QUALIFIED (TREE_TYPE (decl))
  && FUNCTION_RVALUE_QUALIFIED (TREE_TYPE (decl)))
return 1;
-  if ((TREE_CODE (decl) == FUNCTION_TYPE
-  || TREE_CODE (decl) == METHOD_TYPE)
- && FUNCTION_REF_QUALIFIED (decl)
- && FUNCTION_RVALUE_QUALIFIED (decl))
-   return 1;
   break;
 
 case DW_AT_inline:
@@ -216,6 +206,57 @@ cp_decl_dwarf_attribute (const_tree decl
   return -1;
 }
 
+/* Return -1 if dwarf ATTR shouldn't be added for TYPE, or the attribute
+   value otherwise.  */
+int
+cp_type_dwarf_attribute (const_tree type, int attr)
+{
+  if (type == NULL_TREE)
+return -1;
+
+  switch (attr)
+{
+case DW_AT_reference:
+  if ((TREE_CODE (type) == FUNCTION_TYPE
+  || TREE_CODE (type) == METHOD_TYPE)
+ && FUNCTION_REF_QUALIFIED (type)
+ && !FUNCTION_RVALUE_QUALIFIED (type))
+   return 1;
+  break;
+
+case DW_AT_rvalue_reference:
+  if ((TREE_CODE (type) == FUNCTION_TYPE
+  || TREE_CODE (type) == METHOD_TYPE)
+ && FUNCTION_REF_QUALIFIED (type)
+ && FUNCTION_RVALUE_QUALIFIED (type))
+   return 1;
+  

libgo patch committed: Only rebuild package if dependent .gox changed

[Ian Lance Taylor]

This patch to libgo tweaks the libgo Makefile so that we only rebuild
a package if the .gox file of some imported package changes.  We now
use mvifdiff and stamp files to track whether a .gox file has changed.
When package A depends on package B, and we rebuild package B, we only
rebuild package A if package B's .gox file changes.  This is safe
because when package A imports package B it only reads package B's
.gox file.  This means that changes that do not affect export
information will not cause dependent packages to be recompiled.  This
doesn't matter in a clean build, but it speeds up an incremental build
when the export information does not change.  Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241741)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-9ee8ad540d6f2f77af1821bfd977dc1820e1be8f
+90f12ac1fa72a95e73cb88b6114fa3131c4ca8ee
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 241741)
+++ libgo/Makefile.am   (working copy)
@@ -924,7 +924,8 @@ BUILDPACKAGE = \
 # How to build a .gox file from a .lo file.
 BUILDGOX = \
f=`echo $< | sed -e 's/.lo$$/.o/'`; \
-   $(OBJCOPY) -j .go_export $$f $@.tmp && mv -f $@.tmp $@
+   $(OBJCOPY) -j .go_export $$f $@.tmp; \
+   $(SHELL) $(srcdir)/mvifdiff.sh $@.tmp `echo $@ | sed -e 's/s-gox/gox/'`
 
 GOTESTFLAGS =
 GOBENCH = 
@@ -1022,8 +1023,10 @@ $(1).lo:
 $(1)/check: $$(CHECK_DEPS)
@$$(CHECK)
 .PHONY: $(1)/check
-$(1).gox: $(1).lo
+$(1).gox: $(1).s-gox; @true
+$(1).s-gox: $(1).lo
$$(BUILDGOX)
+   $$(STAMP) $$@
 endef
 
 # This line expands PACKAGE_template once for each package name listed

Re: Implement -Wduplicated-branches (PR c/64279) (v3)

[Jakub Jelinek]

On Tue, Nov 01, 2016 at 09:41:20AM -0400, Jason Merrill wrote:
> On Tue, Oct 25, 2016 at 9:59 AM, Marek Polacek  wrote:
> > On Mon, Oct 24, 2016 at 04:10:21PM +0200, Marek Polacek wrote:
> >> On Thu, Oct 20, 2016 at 12:28:36PM +0200, Marek Polacek wrote:
> >> > I found a problem with this patch--we can't call 
> >> > do_warn_duplicated_branches in
> >> > build_conditional_expr, because that way the C++-specific codes might 
> >> > leak into
> >> > the hasher.  Instead, I should use operand_equal_p, I think.  Let me 
> >> > rework
> >> > that part of the patch.
> 
> Hmm, is there a reason not to use operand_equal_p for
> do_warn_duplicated_branches as well?  I'm concerned about hash
> collisions leading to false positives.

If the hashing function is iterative_hash_expr / inchash::add_expr, then
that is supposed to pair together with operand_equal_p, we even have
checking verification of that.

Jakub

Go patch committed: Don't put print/println constants into temporaries

[Ian Lance Taylor]

This patch to the Go frontend stops putting constants passed to the
predeclared print/println functions in temporaries.  This was an
accidental recent change when the printlock function was introduced.
The print/println functions are unusual in that integer constants are
treated as int64 or uint64 when necessary.  Putting them in
temporaries breaks that, forcing the constants to int, which means
that the wrong thing happens on 32-bit systems.  This fixes GCC PR
78145.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241688)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-c353ffbe18d1538cac7f2a3fcefb846dbf1a6591
+919ef699fe56a9b40c2bd0df07ac1378ce4a7fab
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 241688)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -7193,7 +7193,7 @@ Builtin_call_expression::do_lower(Gogo*,
   pa != this->args()->end();
   ++pa)
{
- if (!(*pa)->is_variable())
+ if (!(*pa)->is_variable() && !(*pa)->is_constant())
{
  Temporary_statement* temp =
Statement::make_temporary(NULL, *pa, loc);

libgo patch committed: Minor Makefile improvements

[Ian Lance Taylor]

This patch to libgo implements some minor Makefile improvements
suggested by Ralph Corderoy.  These reduce the number of processes
used to generate some files.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241740)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-919ef699fe56a9b40c2bd0df07ac1378ce4a7fab
+9ee8ad540d6f2f77af1821bfd977dc1820e1be8f
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 241687)
+++ libgo/Makefile.am   (working copy)
@@ -575,8 +575,8 @@ s-runtime_sysinfo: $(srcdir)/mkrsysinfo.
 runtime.inc: s-runtime-inc; @true
 s-runtime-inc: runtime.lo Makefile
rm -f runtime.inc.tmp2
-   grep -v "#define _" runtime.inc.tmp | grep -v "#define c0 " | grep -v 
"#define c1 " > runtime.inc.tmp2
-   for pattern in '_G[a-z]' '_P[a-z]' _Max _Lock _Sig _Trace _MHeap _Num; 
do \
+   grep -v "#define _" runtime.inc.tmp | grep -v "#define c[01] " > 
runtime.inc.tmp2
+   for pattern in '_[GP][a-z]' _Max _Lock _Sig _Trace _MHeap _Num; do \
  grep "#define $$pattern" runtime.inc.tmp >> runtime.inc.tmp2; \
done
$(SHELL) $(srcdir)/mvifdiff.sh runtime.inc.tmp2 runtime.inc
@@ -591,7 +591,7 @@ s-zstdpkglist: Makefile
echo 'package main' > zstdpkglist.go.tmp
echo "" >> zstdpkglist.go.tmp
echo 'var stdpkg = map[string]bool{' >> zstdpkglist.go.tmp
-   echo $(libgo_go_objs) 'unsafe.lo' 'runtime/cgo.lo' | sed 's/\.lo /\": 
true,\n/g' | sed 's/\.lo/\": true,/' | grep -v _c | sed 's/^/\t\"/' | sort | 
uniq >> zstdpkglist.go.tmp
+   echo $(libgo_go_objs) 'unsafe.lo' 'runtime/cgo.lo' | sed 's/\.lo /\": 
true,\n/g' | grep -v _c | sed 's/\.lo/\": true,/' | sed 's/^/\t\"/' | sort -u 
>> zstdpkglist.go.tmp
echo '}' >> zstdpkglist.go.tmp
$(SHELL) $(srcdir)/mvifdiff.sh zstdpkglist.go.tmp zstdpkglist.go
$(STAMP) $@

Re: Implement -Wduplicated-branches (PR c/64279) (v3)

[Jason Merrill]

On Tue, Oct 25, 2016 at 9:59 AM, Marek Polacek  wrote:
> On Mon, Oct 24, 2016 at 04:10:21PM +0200, Marek Polacek wrote:
>> On Thu, Oct 20, 2016 at 12:28:36PM +0200, Marek Polacek wrote:
>> > I found a problem with this patch--we can't call 
>> > do_warn_duplicated_branches in
>> > build_conditional_expr, because that way the C++-specific codes might leak 
>> > into
>> > the hasher.  Instead, I should use operand_equal_p, I think.  Let me rework
>> > that part of the patch.

Hmm, is there a reason not to use operand_equal_p for
do_warn_duplicated_branches as well?  I'm concerned about hash
collisions leading to false positives.

Jason

[PATCH, vec-tails] Support loop epilogue vectorization

[Yuri Rumyantsev]

Hi All,

I re-send all patches sent by Ilya earlier for review which support
vectorization of loop epilogues and loops with low trip count. We
assume that the only patch - vec-tails-07-combine-tail.patch - was not
approved by Jeff.

I did re-base of all patches and performed bootstrapping and
regression testing that did not show any new failures. Also all
changes related to new vect_do_peeling algorithm have been changed
accordingly.

Is it OK for trunk?

ChangeLog files and patches are attached.


vec-tails-changelogs.tgz
Description: GNU Zip compressed data


vec-tails-patches.tgz
Description: GNU Zip compressed data

Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsincs.

[Kyrill Tkachov]

Hi Tamar,

On 26/10/16 16:01, Tamar Christina wrote:

Hi Christophe,

Here's the updated patch.

Cheers,
Tamar

From: Christophe Lyon 
Sent: Wednesday, October 19, 2016 11:23:56 AM
To: Tamar Christina
Cc: GCC Patches; Kyrylo Tkachov; nd
Subject: Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST 
intrinsincs.

On 19 October 2016 at 11:36, Tamar Christina  wrote:

Hi All,

This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsics. The
current builtin registration code is deficient since it can't access
standard pattern names, to which vmaxnmQ_ST and vminnmQ_ST map
directly. Thus, to enable the vectoriser to have access to these
intrinsics, we implement them using builtin functions, which we
expand to the proper standard pattern using a define_expand.

This patch also implements the __ARM_FEATURE_NUMERIC_MAXMIN macro,
which is defined when __ARM_ARCH >= 8, and which enables the
intrinsics.

Regression tested on arm-none-eabi and no regressions.

This patch is a rework of a previous patch:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01971.html

OK for trunk?


Ok.
Thanks,
Kyrill


Thanks,
Tamar

---

gcc/

2016-10-19  Bilyan Borisov  
 Tamar Christina 

 * config/arm/arm-c.c (arm_cpu_builtins): New macro definition.
 * config/arm/arm_neon.h (vmaxnm_f32): New intrinsinc.
 (vmaxnmq_f32): Likewise.
 (vminnm_f32): Likewise.
 (vminnmq_f32): Likewise.
 * config/arm/arm_neon_builtins.def (vmaxnm): New builtin.
 (vminnm): Likewise.
 * config/arm/neon.md (neon_, VCVTF): New
 expander.

gcc/testsuite/

2016-10-19  Bilyan Borisov  

 * gcc.target/arm/simd/vmaxnm_f32_1.c: New.
 * gcc.target/arm/simd/vmaxnmq_f32_1.c: Likewise.
 * gcc.target/arm/simd/vminnm_f32_1.c: Likewise.
 * gcc.target/arm/simd/vminnmq_f32_1.c: Likewise.


I think you forgot to attach the new tests.

Christophe

[PATCH] PR tree-optimization/78162: Reject negative offsets in store merging early

[Kyrill Tkachov]

Hi all,

Store merging ICEs on this invalid testcase because it trips up on the negative 
bitposition to store to.
It doesn't really expect to handle negative offsets and I believe they won't 
occur very often in valid code anyway.
Filling out structs/bitfields/class members involves positive offsets.
I can look into removing all the assumptions about positive offsets if folks 
want me to (should involve removing
some 'unsigned' modifiers from HOST_WIDE_INTs and double-checking some range 
checks), but for now
this patch just fixes the ICE by rejecting negative offsets early on.

Bootstrapped and tested on aarch64-none-linux-gnu and x86_64.

Ok for trunk?
Thanks,
Kyrill

2016-11-01  Kyrylo Tkachov  

PR tree-optimization/78162
* gimple-ssa-store-merging.c (execute): Mark stores with bitpos < 0
as invalid.

2016-11-01  Kyrylo Tkachov  

PR tree-optimization/78162
* gcc.c-torture/compile/pr78162.c: New test.
diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index f82cad35afbc10eea76957d38100acdce137d271..4dbf03f61ab5ed4e33481d53cc3c2dee1a457f8f 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -1371,7 +1371,7 @@ pass_store_merging::execute (function *fun)
    , , );
 	  /* As a future enhancement we could handle stores with the same
 		 base and offset.  */
-	  bool invalid = offset || reversep
+	  bool invalid = offset || reversep || bitpos < 0
 			 || ((bitsize > MAX_BITSIZE_MODE_ANY_INT)
   && (TREE_CODE (rhs) != INTEGER_CST))
 			 || !rhs_valid_for_store_merging_p (rhs)
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr78162.c b/gcc/testsuite/gcc.c-torture/compile/pr78162.c
new file mode 100644
index ..743d4e678b5b8c9a7ee6fb45254f86212523d59c
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr78162.c
@@ -0,0 +1,10 @@
+/* PR tree-optimization/78162.
+   Handle negative offsets in store merging gracefully.  */
+
+int a, b[1][2];
+
+void fn1()
+{
+  for (a = 0; a < 2; a++)
+b[-1][a] = 0;
+}

[PATCH] PR tree-optimization/78170: Truncate sign-extended padding when encoding bitfields

[Kyrill Tkachov]

Hi all,

In this PR the code writes a -1 to a bitfield of size 17 bits and ends up 
overwriting another bitfields.
The problem is that the intermediate buffer in encode_tree_to_bitpos holding 
the value to merge holds
a 24-bit temporary with -1 written to it i.e. sign-extended to all ones. That 
is how native_encode_expr works.This gets then written to
the final buffer (well, a shifted version of it).

We should instead be truncating the intermediate value to contain zeros in all 
the bits that we don't want.
This is already performed for big-endian, this patch just wires it up for 
little-endian.

Bootstrapped and tested on x86_64.
Ok for trunk?

Thanks,
Kyrill

2016-11-01  Kyrylo Tkachov  

PR tree-optimization/78170
* gimple-ssa-store-merging.c (encode_tree_to_bitpos): Truncate padding
introduced by native_encode_expr on little-endian as well.

2016-11-01  Kyrylo Tkachov  

PR tree-optimization/78170
* gcc.c-torture/execute/pr78170.c: New test.
diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index 5a293d7f30735499aafebeb935b073946eab5691..f82cad35afbc10eea76957d38100acdce137d271 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -432,13 +432,23 @@ encode_tree_to_bitpos (tree expr, unsigned char *ptr, int bitlen, int bitpos,
  contain a sign bit due to sign-extension).  */
   unsigned int padding
 = byte_size - ROUND_UP (bitlen, BITS_PER_UNIT) / BITS_PER_UNIT - 1;
-  if (BYTES_BIG_ENDIAN)
+  if (padding != 0)
 {
-  tmpbuf += padding;
+  /* On big-endian the padding is at the 'front' so just skip the initial
+	 bytes.  */
+  if (BYTES_BIG_ENDIAN)
+	tmpbuf += padding;
+
   byte_size -= padding;
   if (bitlen % BITS_PER_UNIT != 0)
-	clear_bit_region_be (tmpbuf, BITS_PER_UNIT - 1,
-			 BITS_PER_UNIT - (bitlen % BITS_PER_UNIT));
+	{
+	  if (BYTES_BIG_ENDIAN)
+	clear_bit_region_be (tmpbuf, BITS_PER_UNIT - 1,
+ BITS_PER_UNIT - (bitlen % BITS_PER_UNIT));
+	  else
+	clear_bit_region (tmpbuf, bitlen,
+			  byte_size * BITS_PER_UNIT - bitlen);
+	}
 }
 
   /* Clear the bit region in PTR where the bits from TMPBUF will be
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr78170.c b/gcc/testsuite/gcc.c-torture/execute/pr78170.c
new file mode 100644
index ..8ef812ee6accb62db8dd6889d74032a88b784d2c
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr78170.c
@@ -0,0 +1,37 @@
+/* PR tree-optimization/78170.
+   Check that sign-extended store to a bitfield
+   doesn't overwrite other fields.  */
+
+int a, b, d;
+
+struct S0
+{
+  int f0;
+  int f1;
+  int f2;
+  int f3;
+  int f4;
+  int f5:15;
+  int f6:17;
+  int f7:2;
+  int f8:30;
+} c;
+
+void fn1 ()
+{
+  d = b = 1;
+  for (; b; b = a)
+{
+  struct S0 e = { 0, 0, 0, 0, 0, 0, 1, 0, 1 };
+  c = e;
+  c.f6 = -1;
+}
+}
+
+int main ()
+{
+  fn1 ();
+  if (c.f7 != 0)
+__builtin_abort ();
+  return 0;
+}

[patch, fortran] Fix PR 69544

[Thomas Koenig]

Hello world,

the attached, rather simple, patch, fixes a regression where
the locus was not set, leading to an ICE on a warning.

Regression-tested on trunk. OK on all affected and open branches
(7/6/5)?

Regards

Thomas

2016-11-01  Thomas Koenig  

PR fortran/69544
* match.c (gfc_match_where):  Fill in locus for assigment
in simple WHERE statement.

2016-11-01  Thomas Koenig  

PR fortran/69544
* gfortran.dg/where_5.f90:  New test.
Index: match.c
===
--- match.c	(Revision 241590)
+++ match.c	(Arbeitskopie)
@@ -6265,8 +6265,12 @@ gfc_match_where (gfc_statement *st)
   c = gfc_get_code (EXEC_WHERE);
   c->expr1 = expr;
 
+  /* Put in the assignment.  It will not be processed by add_statement, so we
+ need to copy the location here. */
+
   c->next = XCNEW (gfc_code);
   *c->next = new_st;
+  c->next->loc = gfc_current_locus;
   gfc_clear_new_st ();
 
   new_st.op = EXEC_WHERE;
! { dg-do compile }
! { dg-options "-Wcharacter-truncation" }
subroutine where_ice (i,j)
 
  implicit none

  character(8)  :: y(10,10,2)

  integer   :: i
  integer   :: j

  character(12) :: txt(5)
  where (txt(1:3) /= ''   )  y(1:3,i,j) = txt(1:3) ! { dg-warning "CHARACTER expression will be truncated" }

end subroutine where_ice

Re: [PATCH][AArch64] Add function comments to some prologue/epilogue helpers

[Jiong Wang]

On 31/10/16 12:10, Kyrill Tkachov wrote:

Ping.

Thanks,
Kyrill

On 24/10/16 12:30, Kyrill Tkachov wrote:

Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00839.html

Thanks,
Kyrill

On 12/10/16 11:23, Kyrill Tkachov wrote:

Hi all,

I'm looking at the aarch64 prologue and epilogue generation code and 
I noticed many of the helper
functions don't have function comments so it makes it harder than it 
has to to understand what's going on.
This patch adds function comments to some of them. I hope I 
understood the functions correctly.


Is this ok for trunk?

Thanks,
Kyrill

2016-10-12  Kyrylo Tkachov  

* config/aarch64/aarch64.c (aarch64_register_saved_on_entry): Add
function comment.
(aarch64_next_callee_save): Likewise.
(aarch64_pushwb_single_reg): Likewise.
(aarch64_gen_storewb_pair): Likewise.
(aarch64_push_regs): Likewise.
(aarch64_gen_loadwb_pair): Likewise.
(aarch64_pop_regs): Likewise.
(aarch64_gen_store_pair): Likewise.
(aarch64_gen_load_pair): Likewise.
(aarch64_save_callee_saves): Likewise.
(aarch64_restore_callee_saves): Likewise.


I "contributed" some of these functions without comments...
The new added comments looks good to me though I can't approve.

Thanks for fixing these.

Regards,
Jiong

Re: [PATCH][ree] PR rtl-optimization/78038: Handle global register dataflow definitions in ree

[Kyrill Tkachov]

On 20/10/16 19:52, Jeff Law wrote:

On 10/20/2016 08:57 AM, Kyrill Tkachov wrote:

Hi all,

In this PR we've got code like this:
register struct test2_s *g __asm__("x28");

void
do_something ()
{
  test_fptr ();
  struct test2_s *p1 = 0;
  *p1 = *g;
}

And we get an ICE in gcc/ree.c:655 in get_sub_rtx.
The problem is when we try to process the defining insn of register x28
from the insn:
(set (reg/f:DI 1 x1 [orig:74 g.1_2 ] [74])
(zero_extend:DI (reg/v:SI 28 x28 [ g ])))

The dataflow reports the insn setting x28 to be:
(call_insn 8 7 10 2 (parallel [
(call (mem:DI (reg/f:DI 0 x0 [orig:77 test_fptr ] [77]) [0
*test_fptr.0_1 S8 A8])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:DI 30 x30))
]) "ree.c":14 41 {*call_reg}
 (expr_list:REG_CALL_DECL (nil)
(nil))
(expr_list (clobber (reg:DI 17 x17))
(expr_list (clobber (reg:DI 16 x16))
(nil

which, as you can see, doesn't actually set x28.
AFAICS the reason dataflow reports call_insn 8 as defining x28 is
because x28 is a global register variable
and that means that every function call is considered to define it.
But the ree pass can't really use any of that. It only wants some SET
RTL patterns to play with.
One solution is to bail out at the ICE location, in get_sub_rtx, when no
SETs are found inside the parallel.
But I think we shouldn't be getting this far along anyway.
So this patch prevents the call_insn from being recognised as a defining
insn for x28 for the purposes of ree.
It makes sure that if the register we're extending is a global register
that all the insns in the def chain
actually set it directly as determined by set_of from rtlanal.c.
This should hopefully still allow ree to optimise extensions of global
registers as long as they are combined
with legitimate defining insns.

Bootstrapped and tested on aarch64, arm, x86_64.

Ok for trunk?

Thanks,
Kyrill

2016-10-20  Kyrylo Tkachov  

PR rtl-optimization/78038
* ree.c (get_defs): Return NULL if a defining insn for REG cannot
be deduced to set REG through the RTL structure.
(make_defs_and_copies_lists): Return false on a failing get_defs call.

2016-10-20  Kyrylo Tkachov  

PR rtl-optimization/78038
* gcc.target/aarch64/pr78038.c: New test.

OK.


Thanks.
As this patch has been in trunk for more than a week with no issues I'd like to 
apply it to the release branches.
I've so far bootstrapped and tested it on the GCC 6 branch on 
aarch64-none-linux-gnu and I'll be applying it there.

Kyrill



Jeff

Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST intrinsincs.

[Tamar Christina]

Ping.


From: gcc-patches-ow...@gcc.gnu.org  on behalf 
of Tamar Christina 
Sent: Wednesday, October 26, 2016 4:01:42 PM
To: Christophe Lyon
Cc: GCC Patches; Kyrylo Tkachov; nd
Subject: Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST 
intrinsincs.

Hi Christophe,

Here's the updated patch.

Cheers,
Tamar

From: Christophe Lyon 
Sent: Wednesday, October 19, 2016 11:23:56 AM
To: Tamar Christina
Cc: GCC Patches; Kyrylo Tkachov; nd
Subject: Re: [PATCH v2][AArch32][NEON] Implementing vmaxnmQ_ST and vminnmQ_ST 
intrinsincs.

On 19 October 2016 at 11:36, Tamar Christina  wrote:
> Hi All,
>
> This patch implements the vmaxnmQ_ST and vminnmQ_ST intrinsics. The
> current builtin registration code is deficient since it can't access
> standard pattern names, to which vmaxnmQ_ST and vminnmQ_ST map
> directly. Thus, to enable the vectoriser to have access to these
> intrinsics, we implement them using builtin functions, which we
> expand to the proper standard pattern using a define_expand.
>
> This patch also implements the __ARM_FEATURE_NUMERIC_MAXMIN macro,
> which is defined when __ARM_ARCH >= 8, and which enables the
> intrinsics.
>
> Regression tested on arm-none-eabi and no regressions.
>
> This patch is a rework of a previous patch:
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01971.html
>
> OK for trunk?
>
> Thanks,
> Tamar
>
> ---
>
> gcc/
>
> 2016-10-19  Bilyan Borisov  
> Tamar Christina 
>
> * config/arm/arm-c.c (arm_cpu_builtins): New macro definition.
> * config/arm/arm_neon.h (vmaxnm_f32): New intrinsinc.
> (vmaxnmq_f32): Likewise.
> (vminnm_f32): Likewise.
> (vminnmq_f32): Likewise.
> * config/arm/arm_neon_builtins.def (vmaxnm): New builtin.
> (vminnm): Likewise.
> * config/arm/neon.md (neon_, VCVTF): New
> expander.
>
> gcc/testsuite/
>
> 2016-10-19  Bilyan Borisov  
>
> * gcc.target/arm/simd/vmaxnm_f32_1.c: New.
> * gcc.target/arm/simd/vmaxnmq_f32_1.c: Likewise.
> * gcc.target/arm/simd/vminnm_f32_1.c: Likewise.
> * gcc.target/arm/simd/vminnmq_f32_1.c: Likewise.
>

I think you forgot to attach the new tests.

Christophe