[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 8 Dec 2016, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
> 
> --- Comment #4 from Jeffrey A. Law  ---
> So my patches for 33562 will detect the partial dead store in "foo", but I
> never wrote the bits to narrow partial dead stores.
> 
> The difficulty in optimizing this particular case will be rewriting the
> CONSTRUCTOR node.  Though it may be as simple as walking down the CONSTRUCTOR
> and splicing out components which correspond to dead assignments -- I'll have
> to familiarize myself with the guts of how to walk CONSTRUCTOR nodes. 
> Hopefully they're at least in-order and extracting byte offsets is easy :-)

Should be.

But I still think any "real" DSE work should be done by unifying what
SRA, update-address-taken, store-merging and current DSE do (eventually 
even the bswap pass).  Those are all related and they share basic analysis
(and dataflow) parts and would benefit from each other transform "tricks".

And all of them would benefit from being flow-sensitive in a way to
consider parts of the CFG where for example addresses do not escape
and doing some (eventually expensive) stuff at such (cold?) region 
boundaries.

[Bug rtl-optimization/78671] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213 with -Og -march=skylake-avx512

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Assuming fixed.

Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

[Mikael Morin]

Hello,

Le 08/12/2016 à 23:49, Mikael Morin a écrit :

Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 2e6ef2a..8173ba9 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1019,7 +1019,7 @@ gfc_build_qualified_array (tree decl, gfc_symbol
* sym)
   layout_type (type);
 }

-  if (TYPE_NAME (type) != NULL_TREE
+  if (TYPE_NAME (type) != NULL_TREE && as->rank > 0

I suppose one should replace as->rank with as->rank + as->corank instead
of this.


I remember now that rank can be negative, so your change is fine.


   && GFC_TYPE_ARRAY_UBOUND (type, as->rank - 1) != NULL_TREE
   && VAR_P (GFC_TYPE_ARRAY_UBOUND (type, as->rank - 1)))
 {



Mikael

Re: [PATCH] [AArch64] PR target/71663 Improve Vector Initializtion

[Hurugalawadi, Naveen]

Hi,

Sorry. Missed out the testcase in patch submission.
Added the missing testcase along with the ChangeLog.
Please review the same and let us know if thats okay?

2016-12-09  Andrew PInski  

gcc
    * config/aarch64/aarch64.c (aarch64_expand_vector_init):
    Improve vector initialization code gen.
gcc/testsuite
* gcc.target/aarch64/pr71663.c: New Testcase.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e87831f..da5b6fa 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11609,11 +11609,54 @@ aarch64_expand_vector_init (rtx target, rtx vals)
   aarch64_expand_vector_init (target, copy);
 }
 
-  /* Insert the variable lanes directly.  */
-
   enum insn_code icode = optab_handler (vec_set_optab, mode);
   gcc_assert (icode != CODE_FOR_nothing);
 
+  /* If there is only varables, try to optimize
+ the inseration using dup for the most common element
+ followed by insertations. */
+  if (n_var == n_elts && n_elts <= 16)
+{
+  int matches[16][2];
+  int nummatches = 0;
+  memset (matches, 0, sizeof(matches));
+  for(int i = 0; i < n_elts; i++)
+	{
+	  for (int j = 0; j <= i; j++)
+	{
+	  if (rtx_equal_p (XVECEXP (vals, 0, i), XVECEXP (vals, 0, j)))
+		{
+		  matches[i][0] = j;
+		  matches[j][1]++;
+		  if (i != j)
+		nummatches++;
+		  break;
+		}
+	}
+	}
+  int maxelement = 0;
+  int maxv = 0;
+  for (int i = 0; i < n_elts; i++)
+	if (matches[i][1] > maxv)
+	  maxelement = i, maxv = matches[i][1];
+
+  /* Create a duplicate of the most common element. */
+  rtx x = copy_to_mode_reg (inner_mode, XVECEXP (vals, 0, maxelement));
+  aarch64_emit_move (target, gen_rtx_VEC_DUPLICATE (mode, x));
+  /* Insert the rest. */
+  for (int i = 0; i < n_elts; i++)
+	{
+	  rtx x = XVECEXP (vals, 0, i);
+	  if (matches[i][0] == maxelement)
+	continue;
+	  x = copy_to_mode_reg (inner_mode, x);
+	  emit_insn (GEN_FCN (icode) (target, x, GEN_INT (i)));
+	}
+  return;
+}
+
+  /* Insert the variable lanes directly.  */
+
   for (int i = 0; i < n_elts; i++)
 {
   rtx x = XVECEXP (vals, 0, i);
diff --git a/gcc/testsuite/gcc.target/aarch64/pr71663.c b/gcc/testsuite/gcc.target/aarch64/pr71663.c
new file mode 100644
index 000..c8df847
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr71663.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+#define vector __attribute__((vector_size(16)))
+
+vector float combine (float a, float b, float c, float d)
+{
+  return (vector float) { a, b, c, d };
+}
+
+/* { dg-final { scan-assembler-not "movi\t" } } */
+/* { dg-final { scan-assembler-not "orr\t" } } */
+/* { dg-final { scan-assembler-times "ins\t" 3 } } */
+/* { dg-final { scan-assembler-times "dup\t" 1 } } */

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[kugan]

Hi Martin,

On 07/12/16 21:08, Martin Jambor wrote:

Hello Kugan,

sorry, I have lost track of this patch and re-discovered it only now.

On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:

Hi,

On 24/11/16 19:48, Richard Biener wrote:

On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor  wrote:

Hi,

On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote:

Hi,

I was relying on ipa_get_callee_param_type to get type of parameter and then
convert arguments to this type while computing jump functions. However, in
cases like shown in PR78365, ipa_get_callee_param_type, instead of giving
up, would return the wrong type.


At what stage does this happen?  During analysis
(ipa_compute_jump_functions_for_edge) or at WPA
(propagate_constants_accross_call)?  Both?


Hmm, where does jump function compute require the callee type?
In my view the jump function should record

 (expected-incoming-type) arg [OP X]

for each call argument in its body.  Thus required conversions are
done at WPA propagation time.


I think the current uses of
ipa_get_callee_param_type are fine with this.

Attached patch now uses callee's DECL_ARGUMENTS to get the type. If it
cannot be found, then I would give up and set the jump function to varying.


But DECL_ARGUMENTS is not available at WPA stage with LTO so your
patch would make our IPA layer to optimize less with LTO.  This was
the reason to go through the hoops of TYPE_ARG_TYPES in the first
place.

If TYPE_ARG_TYPES cannot be trusted, then I'm afraid we are back to
square one and indeed need to put the correct type in jump functions.


If DECL_ARGUMENTS is not available at WPA stage then I see no other
way than to put the types on the jump functions.


Here is a patch that does this. To fox PR78365, in
ipa_get_callee_param_type, I am now checking DECL_ARGUMENTS first. I lto
bootstrapped and regression tested on x86_64-linux-gnu and ppc64le-linux
with no new regressions. I will build Firefox and measure the memory usage
as Honza suggested based on the feedback.



So, do you have any numbers?
I will do it. How do you measure the gcc's memory usage while building 
Firefox. I saw Honza's LTO blog talks about using vmstat result. Any 
tips please?






diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2ec671f..3d50041 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1846,11 +1846,11 @@ propagate_bits_accross_jump_function (cgraph_edge *cs, 
int idx, ipa_jump_func *j
 static bool
 propagate_vr_accross_jump_function (cgraph_edge *cs,
ipa_jump_func *jfunc,
-   struct ipcp_param_lattices *dest_plats,
-   tree param_type)
+   struct ipcp_param_lattices *dest_plats)
 {
   struct ipcp_param_lattices *src_lats;
   ipcp_vr_lattice *dest_lat = _plats->m_value_range;
+  tree param_type = jfunc->param_type;

   if (dest_lat->bottom_p ())
 return false;
@@ -1895,9 +1895,9 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
   tree val = ipa_get_jf_constant (jfunc);
   if (TREE_CODE (val) == INTEGER_CST)
{
+ val = fold_convert (param_type, val);
  if (TREE_OVERFLOW_P (val))
val = drop_tree_overflow (val);
- val = fold_convert (param_type, val);
  jfunc->vr_known = true;
  jfunc->m_vr.type = VR_RANGE;
  jfunc->m_vr.min = val;
@@ -2247,7 +2247,6 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
 {
   struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
   struct ipcp_param_lattices *dest_plats;
-  tree param_type = ipa_get_callee_param_type (cs, i);

   dest_plats = ipa_get_parm_lattices (callee_info, i);
   if (availability == AVAIL_INTERPOSABLE)
@@ -2264,8 +2263,7 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
   dest_plats);
  if (opt_for_fn (callee->decl, flag_ipa_vrp))
ret |= propagate_vr_accross_jump_function (cs,
-  jump_func, dest_plats,
-  param_type);
+  jump_func, dest_plats);
  else
ret |= dest_plats->m_value_range.set_to_bottom ();
}
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 90c19fc..235531b 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1651,14 +1651,24 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
 /* Return the Ith param type of callee associated with call graph
edge E.  */

-tree
+static tree
 ipa_get_callee_param_type (struct cgraph_edge *e, int i)
 {
   int n;
+  tree t = e->callee ? DECL_ARGUMENTS (e->callee->decl) : NULL_TREE;
+  if (t)
+for (n = 0; n < i; n++)
+  {
+   if (!t)
+ return NULL;
+   t = TREE_CHAIN (t);
+  }
+  if (t)
+return TREE_TYPE (t);
   tree type = 

[Bug tree-optimization/78731] Possible bug with switch when optimization is turned on.

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson  ---
The compiler is failing in jump threading as called by dom2.  Jeff's 2015-09-30
patch is triggering in dom1, and changing the CFG just enough to prevent the
jump threading bug from triggering.  So it isn't a proper fix.

Disabling it, and bisecting again, I found bug 67892, another patch from Jeff,
which looks like a proper fix.  However, there is a problem.  The bug was
reported against gcc 5, fixed in gcc 6, and then closed, but is still broken in
gcc 5.  I think it is in the wrong state.  Presumably, it should still be open,
and then fixed in gcc 5 if reasonably safe, or documented as a known bug that
we won't fix in gcc 5.

[PATCH] Fix PR78721

[kugan]

Hi,

in propagate_vr_accross_jump_function, drop_tree_overflow should be 
after fold_convert. Attached patch changes this.


Bootstrapped and regression tested on x86_64-linux-gnu with no new 
regressions. Is this OK for trunk?


Thanks,
Kugan

gcc/testsuite/ChangeLog:

2016-12-09  Kugan Vivekanandarajah  

PR ipa/78721
* gcc.dg/pr78721.c: New test.


gcc/ChangeLog:

2016-12-09  Kugan Vivekanandarajah  

PR ipa/78721
* ipa-cp.c (propagate_vr_accross_jump_function): drop_tree_overflow
after fold_convert.










diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2ec671f..4ec7cc5 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1895,9 +1895,9 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
   tree val = ipa_get_jf_constant (jfunc);
   if (TREE_CODE (val) == INTEGER_CST)
{
+ val = fold_convert (param_type, val);
  if (TREE_OVERFLOW_P (val))
val = drop_tree_overflow (val);
- val = fold_convert (param_type, val);
  jfunc->vr_known = true;
  jfunc->m_vr.type = VR_RANGE;
  jfunc->m_vr.min = val;
diff --git a/gcc/testsuite/gcc.dg/pr78721.c b/gcc/testsuite/gcc.dg/pr78721.c
index e69de29..fb2ffc3 100644
--- a/gcc/testsuite/gcc.dg/pr78721.c
+++ b/gcc/testsuite/gcc.dg/pr78721.c
@@ -0,0 +1,23 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+int a, b, c;
+
+int fn1 (char e, char f)
+{
+  return !f || (e && f == 1);
+}
+
+void fn2 (char e)
+{
+  while (b)
+e = 0;
+  a = 128;
+  c = fn1 (e, a == e);
+}
+
+int main ()
+{
+  fn2 (0);
+  return 0;
+}

[PATCH] [AArch64] PR target/71663 Improve Vector Initializtion

[Hurugalawadi, Naveen]

Hi,

The AArch64 vector initialization sequence can be optimized to generate
better code. The attached patch handles for the case where the vector
contains only variables. It checks for the common elements in the vector
and inserts the values in optimized way.

Bootstrapped and Regression tested on aarch64-thunder-linux.
Please review the patch and let us know if its okay?

2016-12-09  Andrew PInski  

gcc
* config/aarch64/aarch64.c (aarch64_expand_vector_init):
Improve vector initialization code gen.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e87831f..da5b6fa 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11609,11 +11609,54 @@ aarch64_expand_vector_init (rtx target, rtx vals)
   aarch64_expand_vector_init (target, copy);
 }
 
-  /* Insert the variable lanes directly.  */
-
   enum insn_code icode = optab_handler (vec_set_optab, mode);
   gcc_assert (icode != CODE_FOR_nothing);
 
+  /* If there is only varables, try to optimize
+ the inseration using dup for the most common element
+ followed by insertations. */
+  if (n_var == n_elts && n_elts <= 16)
+{
+  int matches[16][2];
+  int nummatches = 0;
+  memset (matches, 0, sizeof(matches));
+  for(int i = 0; i < n_elts; i++)
+	{
+	  for (int j = 0; j <= i; j++)
+	{
+	  if (rtx_equal_p (XVECEXP (vals, 0, i), XVECEXP (vals, 0, j)))
+		{
+		  matches[i][0] = j;
+		  matches[j][1]++;
+		  if (i != j)
+		nummatches++;
+		  break;
+		}
+	}
+	}
+  int maxelement = 0;
+  int maxv = 0;
+  for (int i = 0; i < n_elts; i++)
+	if (matches[i][1] > maxv)
+	  maxelement = i, maxv = matches[i][1];
+
+  /* Create a duplicate of the most common element. */
+  rtx x = copy_to_mode_reg (inner_mode, XVECEXP (vals, 0, maxelement));
+  aarch64_emit_move (target, gen_rtx_VEC_DUPLICATE (mode, x));
+  /* Insert the rest. */
+  for (int i = 0; i < n_elts; i++)
+	{
+	  rtx x = XVECEXP (vals, 0, i);
+	  if (matches[i][0] == maxelement)
+	continue;
+	  x = copy_to_mode_reg (inner_mode, x);
+	  emit_insn (GEN_FCN (icode) (target, x, GEN_INT (i)));
+	}
+  return;
+}
+
+  /* Insert the variable lanes directly.  */
+
   for (int i = 0; i < n_elts; i++)
 {
   rtx x = XVECEXP (vals, 0, i);

Re: [PATCH, rs6000] Use new pass registration framework for analyze_swaps

[Segher Boessenkool]

On Thu, Dec 08, 2016 at 04:53:55PM -0600, Bill Schmidt wrote:
> Back in October
> (https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00256.html), Jakub
> updated the target pass registration framework so that target passes act
> more like regular passes:  their dumps are numbered in proper order, and
> use of dump options like -details now works.  I've finally gotten around
> to updating the rs6000 back end to take advantage of this.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  I've verified that the "swaps" dump now appears with
> proper numbering:
> 
> -rw-rw-r--  1 wschmidt wschmidt 3815 Dec  8 16:40 
> swaps-p8-17.c.232r.dfinit
> -rw-rw-r--  1 wschmidt wschmidt 5092 Dec  8 16:40 swaps-p8-17.c.233r.swaps
> -rw-rw-r--  1 wschmidt wschmidt 9751 Dec  8 16:40 swaps-p8-17.c.234r.cse1
> 
> Is this ok for trunk?

Yes please.  Thanks,


Segher


> 2016-12-08  Bill Schmidt  
> 
>   * config/rs6000/rs6000-passes.def: New file.
>   * config/rs6000/rs6000-protos.h: Declare make_pass_analyze_swaps.
>   * config/rs6000/rs6000.c (rs6000_option_override): Remove
>   registration of machine-specific passes.
>   (pass_analyze_swaps::clone): New function.
>   * config/rs6000/t-rs6000: Define PASSES_EXTRA.

Re: [PATCH, rs6000] Add support for vec_pack and vec_sld built-ins

[Segher Boessenkool]

On Thu, Dec 08, 2016 at 08:28:22AM -0800, Carl E. Love wrote:
> The following patch adds two more built-ins that are missing.
> Specifically:
> 
> vector floatvec_packvector doublevector double
> vector double   vec_sld vector doublevector double
> 
> The patch has been boot strapped and tested on
> powerpc64le-unknown-linux-gnu (Power 8) and on 
> powerpc64-unknown-linux-gnu (Power 7) with no regressions.

> 2016-12-08  Carl Love  
> 
>* config/rs6000/rs6000-c.c: Add built-in support for
>vector float  vec_pack  vector double  vector double
>vector double  vec_sld  vector double  vector double

Add some parens and commas here?

>* config/rs6000/rs6000.c: Add icode check for vsldoi_v2df to allow
>4-bit unsigned literal.
>* config/rs6000/rs6000-builtin.def: Add definition for VSLDOI_2DF
>* doc/extend.texi: Update the built-in documentation file for the
>new powerpc vec_pack and vec_sld built-ins.

Okay for trunk with that.  Thanks,


Segher

Re: [PATCH, rs6000] whitespace fix for p9-dimode tests

[Segher Boessenkool]

Hello,

On Thu, Dec 08, 2016 at 10:18:42AM -0600, Will Schmidt wrote:
> I am seeing some failures in the p9-dimode tests. This appears to
> be due to the scan-assembler strings matching comment portions of the
> generated assembly, versus the actual generated assembly. In
> particular, the dg-final directive  { scan-assembler-not "ld"}
> is matching the "ld" as seen in the string
>   # 19 "/home/willschm/gcc/gcc-mainline-vec_fold/..."
> 
> This is resolved by adding a leading whitespace regex string "\[ \t\]"
> as seen in other tests.

That works; a more future-proof way is writing it as

/* { dg-final { scan-assembler-not {\mld\M}   } } */

which will also not match a future "ldlol" instruction (\m \M are like
\< \> in some other regular expression dialects; see
https://www.tcl.tk/man/tcl8.4/TclCmd/re_syntax.htm ).

Okay either way.  Thanks,


Segher

Re: [PATCH, rs6000] Fix 32-bit BE failure for gcc.target/powerpc/fold-vec-add-7.c

[Segher Boessenkool]

On Wed, Dec 07, 2016 at 09:05:13PM -0600, Bill Schmidt wrote:
> Andreas Schwab observed that the subject test case fails on 32-bit big-endian
> because the test is not restricted to targets that support __int128.  This
> patch rectifies that.
> 
> Tested on powerpc64-unknown-linux-gnu and verified that the test is flagged
> as unsupported for BE, but runs correctly on LE.  Tested on powerpc64le-
> unknown-linux-gnu and verified that the test runs correctly there.  Is this
> ok for trunk?

Yes, thanks!


Segher


> 2016-12-07  Bill Schmidt  
> 
>   * gcc.target/powerpc/fold-vec-add-7.c: Require effective target to
>   support __int128.

Re: [PATCH 5/9] Introduce selftest::locate_file (v4)

[Bernd Schmidt]

On 12/08/2016 10:47 PM, David Malcolm wrote:


Is (A) OK, or would you prefer (B)?   (I prefer (A) fwiw)


Oh well, just keep it as it is.


Bernd

Re: [PATCH] Prevent use of MEM_* attr accessor macros as lvalues

[Bernd Schmidt]

On 12/09/2016 03:02 AM, David Malcolm wrote:

The following patch leads to errors like this for that kind
of mistake:

error: assignment of member 'mem_attrs::offset' in read-only object
MEM_OFFSET (x) = atoi (name.string);
  ^

Successfully bootstrapped on x86_64-pc-linux-gnu.


That easy? Nice. A quick grep through the ports shows nothing of 
concern, so OK.



Bernd

[PATCH] Prevent use of MEM_* attr accessor macros as lvalues

[David Malcolm]

On Thu, 2016-12-08 at 21:08 +0100, Bernd Schmidt wrote:
> On 12/08/2016 09:39 PM, David Malcolm wrote:
> > 
> > OK as adjustments to patches 8a and 8b?
> 
> Ok. Is it possible to adjust these macros to return something like a
> const reference to ensure people can't make this kind of error?
> 
> 
> Bernd

The following patch leads to errors like this for that kind
of mistake:

error: assignment of member 'mem_attrs::offset' in read-only object
MEM_OFFSET (x) = atoi (name.string);
  ^

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk?

gcc/ChangeLog:
* rtl.h (get_mem_attrs): Add "const" qualifier to returned
pointer.
---
 gcc/rtl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/rtl.h b/gcc/rtl.h
index a5efa28..4f0efa6 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -3355,7 +3355,7 @@ extern struct target_rtl *this_target_rtl;
 
 #ifndef GENERATOR_FILE
 /* Return the attributes of a MEM rtx.  */
-static inline struct mem_attrs *
+static inline const struct mem_attrs *
 get_mem_attrs (const_rtx x)
 {
   struct mem_attrs *attrs;
-- 
1.8.5.3

[Bug middle-end/50481] builtin to reverse the bit order

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin  changed:

   What|Removed |Added

 CC||matthijsvanduin at gmail dot 
com

--- Comment #3 from Matthijs van Duin  ---
Bump!  Proper intrinsics for bitreverse would be much appreciated!  A plain C
implementation is ugly and results in equally awful code output, while using
inline asm breaks portability and can't be constant-folded or used in
constexpr.

What makes the continued lack of a __builtin_arm_rbit() in gcc a bit bizarre is
that the (identically named) Neon versions of this instruction on AArch64
actually *did* receive proper intrinsics! [1]

It's worth mentioning that clang does support __builtin_arm_rbit(), and they've
actually generalized this to a full set of target-independent bitreverse
builtins [2].

[1] https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01913.html
[2] http://clang.llvm.org/docs/LanguageExtensions.html#builtin-bitreverse

Re: [PATCH] Fix PR78027

[Jeff Law]

On 12/08/2016 04:05 PM, Cesar Philippidis wrote:

PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with omp decl attributes as candidates for aliasing.
Usually that works for OpenACC, because offloaded functions generated by
OpenACC PARALLEL or KERNELS regions usually have an 'omp target
entrypoint' attribute. However that is not the case in two situations:

1. ACC ROUTINES do not have an 'omp target entrypoint' attribute.

2. Nested offloaded regions inside 'omp declare target' functions do not
have 'omp target entrypoint' attributes either.

The solution I chose for this problem is to teach the IPA-ICF pass to
ignore function with 'oacc *' decl attributes. Arguably 2) should be a
parser error when an OpenACC offloaded region is embedded within an
OpenMP offloaded function. The LTO linker does report an error for nvptx
targets, but not the host. With that in mind, this patch is still
necessary for case 1.

Is this OK for trunk?

Cesar


trunk-pr78027.diff


2016-12-08  Cesar Philippidis  

PR fortran/78027

gcc/
* ipa-icf.c (sem_function::parse): Don't process functions with
oacc decl attributes, as they may be OpenACC routines.

gcc/testsuite/
* c-c++-common/goacc/acc-icf.c: New test.
* gfortran.dg/goacc/pr78027.f90: New test.
This follows the same approach as we do for openmp.  This is fine for 
the trunk.


Jeff

Re: strange test failures

[Jeff Law]

On 12/08/2016 04:47 PM, Martin Sebor wrote:

I'm seeing failures in a few C tests that I'm not sure what to make
out of.  The tests fail due to undefined symbols while linking even
though they're not meant to link.  Among these are a number (but not
all) of the gcc.dg/divmod-[1-6]{-simode}.c tests.

  FAIL: gcc.dg/divmod-1.c (test for excess errors)

The log shows that they are being built without the -S option:

spawn -ignore SIGHUP /opt/notnfs/msebor/build/gcc-78622/gcc/xgcc
-B/opt/notnfs/msebor/build/gcc-78622/gcc/
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.dg/divmod-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-fdump-tree-widening_mul-details -lm -o ./divmod-1.exe
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
...

When I run make check-c I get these same failures in different tests.

In successful builds the logs show that the tests are only assembled
(i.e., compiled with -S), never linked.

I can reproduce this on two different x86_64 machines but so far
only with my patches to GCC (the middle end but none of these tests
or the GCC .exp files).  Is it possible that somehow my changes cause
this?  (The removal of the -S option.)  Am I missing something about
how GCC tests are run?
IIRC the default for a dg test is to compile, but not assemble or run. 
The log shows that it's trying to go through the link step.






Thanks
Martin

PS I also see other strange errors like

RROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/execute.exp.

ERROR: unmatched open brace in list

ERROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp.

ERROR: torture-init: torture_without_loops is not empty as expected
This all sounds like you've got a mucked up testsuite/lib directory or 
something like that.  I'd start by verifying the contents of your 
testsuite/lib directory.


I did a testrun on Dec 7 on the trunk and didn't see any of these problems.

jeff

Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)

[Martin Sebor]

+enabled with @option{-Wextra}.

So I think we should in the immediate term not enable this in Wextra.
However, I think for gcc-8 we should revisit after fixing GCC to be
cleaner WRT alloc-zero.

So disable alloc-zero by default, comment typo and potentially adding
the GTY marker to alloc_object_size_limit and this is OK.


Thanks.  Committed in r243470 with the changes above.

Martin

[Bug c/77531] __attribute__((alloc_size(1,2))) could also warn on multiplication overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #6 from Martin Sebor  ---
Implemented in r243470.

[Bug c/77531] __attribute__((alloc_size(1,2))) could also warn on multiplication overflow

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  8 23:50:40 2016
New Revision: 243470

URL: https://gcc.gnu.org/viewcvs?rev=243470=gcc=rev
Log:
PR c/77531 - __attribute__((alloc_size(1,2))) could also warn on multiplication
overflow
PR c/78284 - warn on malloc with very large arguments

gcc/c-family/ChangeLog:

PR c/78284
* c.opt (-Walloc-zero, -Walloc-size-larger-than): New options.

gcc/ChangeLog:

PR c/78284
* builtin-attrs.def (ATTR_ALLOC_SIZE, ATTR_RETURNS_NONNULL): New
identifier tree nodes.
(ATTR_ALLOCA_SIZE_1_NOTHROW_LEAF_LIST): New attribute list.
(ATTR_MALLOC_SIZE_1_NOTHROW_LIST): Same.
(ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST): Same.
(ATTR_MALLOC_SIZE_1_2_NOTHROW_LEAF_LIST): Same.
(ATTR_ALLOC_SIZE_2_NOTHROW_LEAF_LIST): Same.
* builtins.c (expand_builtin_alloca): Call
maybe_warn_alloc_args_overflow.
* builtins.def (aligned_alloc, calloc, malloc, realloc):
Add attribute alloc_size.
(alloca): Add attribute alloc_size and returns_nonnull.
* calls.h (maybe_warn_alloc_args_overflow): Declare.
* calls.c (alloc_max_size, operand_signed_p): New functions.
(maybe_warn_alloc_args_overflow): Define.
(initialize_argument_information): Diagnose overflow in functions
declared with attaribute alloc_size.
* doc/invoke.texi (Warning Options): Document -Walloc-zero and
-Walloc-size-larger-than.

gcc/testsuite/ChangeLog:

PR c/78284
* gcc.dg/attr-alloc_size-3.c: New test.
* gcc.dg/attr-alloc_size-4.c: New test.
* gcc.dg/attr-alloc_size-5.c: New test.
* gcc.dg/attr-alloc_size-6.c: New test.
* gcc.dg/attr-alloc_size-7.c: New test.
* gcc.dg/attr-alloc_size-8.c: New test.
* gcc.dg/attr-alloc_size-9.c: New test.
* gcc/testsuite/gcc.dg/errno-1.c: Adjust.


Added:
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-3.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-5.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-8.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/calls.c
trunk/gcc/calls.h
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/errno-1.c

[Bug c/78284] warn on malloc with very large arguments

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  8 23:50:40 2016
New Revision: 243470

URL: https://gcc.gnu.org/viewcvs?rev=243470=gcc=rev
Log:
PR c/77531 - __attribute__((alloc_size(1,2))) could also warn on multiplication
overflow
PR c/78284 - warn on malloc with very large arguments

gcc/c-family/ChangeLog:

PR c/78284
* c.opt (-Walloc-zero, -Walloc-size-larger-than): New options.

gcc/ChangeLog:

PR c/78284
* builtin-attrs.def (ATTR_ALLOC_SIZE, ATTR_RETURNS_NONNULL): New
identifier tree nodes.
(ATTR_ALLOCA_SIZE_1_NOTHROW_LEAF_LIST): New attribute list.
(ATTR_MALLOC_SIZE_1_NOTHROW_LIST): Same.
(ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST): Same.
(ATTR_MALLOC_SIZE_1_2_NOTHROW_LEAF_LIST): Same.
(ATTR_ALLOC_SIZE_2_NOTHROW_LEAF_LIST): Same.
* builtins.c (expand_builtin_alloca): Call
maybe_warn_alloc_args_overflow.
* builtins.def (aligned_alloc, calloc, malloc, realloc):
Add attribute alloc_size.
(alloca): Add attribute alloc_size and returns_nonnull.
* calls.h (maybe_warn_alloc_args_overflow): Declare.
* calls.c (alloc_max_size, operand_signed_p): New functions.
(maybe_warn_alloc_args_overflow): Define.
(initialize_argument_information): Diagnose overflow in functions
declared with attaribute alloc_size.
* doc/invoke.texi (Warning Options): Document -Walloc-zero and
-Walloc-size-larger-than.

gcc/testsuite/ChangeLog:

PR c/78284
* gcc.dg/attr-alloc_size-3.c: New test.
* gcc.dg/attr-alloc_size-4.c: New test.
* gcc.dg/attr-alloc_size-5.c: New test.
* gcc.dg/attr-alloc_size-6.c: New test.
* gcc.dg/attr-alloc_size-7.c: New test.
* gcc.dg/attr-alloc_size-8.c: New test.
* gcc.dg/attr-alloc_size-9.c: New test.
* gcc/testsuite/gcc.dg/errno-1.c: Adjust.


Added:
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-3.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-5.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-8.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/calls.c
trunk/gcc/calls.h
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/errno-1.c

[Bug c/78284] warn on malloc with very large arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Implemented in r243470.

[Bug fortran/78737] linking error with deferred, undefined user-defined derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
I am not sure what you are expecting. The module has an empty main program and
nothing allocated to link to.. Since the interface is abstract it creates
nothing until it is used I think.

$ gfc pr78737.f03 
/tmp/ccBH9og7.o: In function `__object_interface_MOD_assert':
pr78737.f03:(.text+0x59): undefined reference to `write_formatted_interface_'
collect2: error: ld returned 1 exit status

$ gfc -c pr78737.f03 
$

strange test failures

[Martin Sebor]

I'm seeing failures in a few C tests that I'm not sure what to make
out of.  The tests fail due to undefined symbols while linking even
though they're not meant to link.  Among these are a number (but not
all) of the gcc.dg/divmod-[1-6]{-simode}.c tests.

  FAIL: gcc.dg/divmod-1.c (test for excess errors)

The log shows that they are being built without the -S option:

spawn -ignore SIGHUP /opt/notnfs/msebor/build/gcc-78622/gcc/xgcc 
-B/opt/notnfs/msebor/build/gcc-78622/gcc/ 
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.dg/divmod-1.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 
-fdump-tree-widening_mul-details -lm -o ./divmod-1.exe

/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
...

When I run make check-c I get these same failures in different tests.

In successful builds the logs show that the tests are only assembled
(i.e., compiled with -S), never linked.

I can reproduce this on two different x86_64 machines but so far
only with my patches to GCC (the middle end but none of these tests
or the GCC .exp files).  Is it possible that somehow my changes cause
this?  (The removal of the -S option.)  Am I missing something about
how GCC tests are run?

Thanks
Martin

PS I also see other strange errors like

RROR: tcl error sourcing 
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/execute.exp.

ERROR: unmatched open brace in list

ERROR: tcl error sourcing 
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp.

ERROR: torture-init: torture_without_loops is not empty as expected

[Bug tree-optimization/78742] New: internal compiler error: in int_cst_value, at tree.c:10782

[dabler at gmail dot com]

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

Bug ID: 78742
   Summary: internal compiler error: in int_cst_value, at
tree.c:10782
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dabler at gmail dot com
  Target Milestone: ---

Created attachment 40283
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40283=edit
testcase

On x86_64 Linux:

$ gcc -v -save-temps -O3 -o libmp-test.o libmp.c -c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux
Configured with: ../configure --build=x86_64-linux --with-arch=core2
--with-tune=westmere --with-thread=posix --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --with-system-zlib --program-suffix=-5.4
Thread model: posix
gcc version 5.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'libmp-test.o' '-c'
'-mtune=westmere' '-march=core2'
 /usr/local/libexec/gcc/x86_64-linux/5.4.0/cc1 -E -quiet -v libmp.c
-mtune=westmere -march=core2 -O3 -fpch-preprocess -o libmp.i
ignoring duplicate directory
"/usr/local/lib/gcc/x86_64-linux/5.4.0/../../../../x86_64-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-linux/5.4.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-linux/5.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'libmp-test.o' '-c'
'-mtune=westmere' '-march=core2'
 /usr/local/libexec/gcc/x86_64-linux/5.4.0/cc1 -fpreprocessed libmp.i -quiet
-dumpbase libmp.c -mtune=westmere -march=core2 -auxbase-strip libmp-test.o -O3
-version -o libmp.s
GNU C11 (GCC) version 5.4.0 (x86_64-linux)
compiled by GNU C version 5.4.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.4.0 (x86_64-linux)
compiled by GNU C version 5.4.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6af85bd5d50765bfdcb33ae94df5c82d
libmp.c: In function ‘func’:
libmp.c:3:6: internal compiler error: in int_cst_value, at tree.c:10782
 void func()
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ cat libmp.c
void foo();

void func()
{
int m;

int tab[m];

__int128 j;
for(; j; j++)
{
tab[j] = 0;
tab[j+1] = 0;
}

foo();
}

Affected gcc versions I have found: 5.x.x, 6.x.x

Re: [PATCH] Fix PR78027

[Steve Kargl]

On Thu, Dec 08, 2016 at 03:05:10PM -0800, Cesar Philippidis wrote:

> 2016-12-08  Cesar Philippidis  
> 
>   PR fortran/78027
> 
>   gcc/
>   * ipa-icf.c (sem_function::parse): Don't process functions with
>   oacc decl attributes, as they may be OpenACC routines.
> 
>   gcc/testsuite/
>   * c-c++-common/goacc/acc-icf.c: New test.
>   * gfortran.dg/goacc/pr78027.f90: New test.
> 

The Fortran testcase is OK.  I probably don't have the
necessary background to review the ipa-icf.c code changes.

-- 
Steve

[PATCH] Fix PR78027

[Cesar Philippidis]

PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with omp decl attributes as candidates for aliasing.
Usually that works for OpenACC, because offloaded functions generated by
OpenACC PARALLEL or KERNELS regions usually have an 'omp target
entrypoint' attribute. However that is not the case in two situations:

1. ACC ROUTINES do not have an 'omp target entrypoint' attribute.

2. Nested offloaded regions inside 'omp declare target' functions do not
have 'omp target entrypoint' attributes either.

The solution I chose for this problem is to teach the IPA-ICF pass to
ignore function with 'oacc *' decl attributes. Arguably 2) should be a
parser error when an OpenACC offloaded region is embedded within an
OpenMP offloaded function. The LTO linker does report an error for nvptx
targets, but not the host. With that in mind, this patch is still
necessary for case 1.

Is this OK for trunk?

Cesar
2016-12-08  Cesar Philippidis  

	PR fortran/78027

	gcc/
	* ipa-icf.c (sem_function::parse): Don't process functions with
	oacc decl attributes, as they may be OpenACC routines.

	gcc/testsuite/
	* c-c++-common/goacc/acc-icf.c: New test.
	* gfortran.dg/goacc/pr78027.f90: New test.


diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 553b81e..31061e9 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -1689,6 +1689,10 @@ sem_function::parse (cgraph_node *node, bitmap_obstack *stack)
   if (lookup_attribute_by_prefix ("omp ", DECL_ATTRIBUTES (node->decl)) != NULL)
 return NULL;
 
+  if (lookup_attribute_by_prefix ("oacc ",
+  DECL_ATTRIBUTES (node->decl)) != NULL)
+return NULL;
+
   /* PR ipa/70306.  */
   if (DECL_STATIC_CONSTRUCTOR (node->decl)
   || DECL_STATIC_DESTRUCTOR (node->decl))
diff --git a/gcc/testsuite/c-c++-common/goacc/acc-icf.c b/gcc/testsuite/c-c++-common/goacc/acc-icf.c
new file mode 100644
index 000..ecfe3f2
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/acc-icf.c
@@ -0,0 +1,49 @@
+/* Ensure that IPA-ICF is disabled on OpenACC routines.  */
+
+/* { dg-additional-options "-fopenacc -O2 -fdump-ipa-icf" }  */
+
+#pragma acc routine gang
+int
+routine1 (int n)
+{
+  int i;
+
+  #pragma acc loop
+  for (i = 0; i < n; i++)
+;
+
+  return n + 1;
+}
+
+#pragma acc routine gang
+int
+routine2 (int n)
+{
+  int i;
+
+  #pragma acc loop
+  for (i = 0; i < n; i++)
+;
+
+  return n + 1;
+}
+
+int
+main ()
+{
+  int i;
+
+  #pragma acc parallel loop
+  for (i = 0; i < 8; i++)
+;
+
+  #pragma acc parallel loop
+  for (i = 0; i < 8; i++)
+;
+
+  return 0;
+}
+
+/* { dg-final { scan-ipa-dump-times "Not parsed function:" 4 "icf" } }  */
+/* { dg-final { scan-ipa-dump "Parsed function:main" "icf" } }  */
+
diff --git a/gcc/testsuite/gfortran.dg/goacc/pr78027.f90 b/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
new file mode 100644
index 000..db65063
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
@@ -0,0 +1,20 @@
+! { dg-additional-options "-fopenmp -O2 -fdump-ipa-icf" }
+
+real function f()
+   !$omp declare target(f)
+   f = 1.
+   !$acc parallel
+   !$acc loop
+   do i = 1, 8
+   end do
+   !$acc end parallel
+   !$acc parallel
+   !$acc loop
+   do i = 1, 8
+   end do
+   !$acc end parallel
+ end
+ 
+! { dg-final { scan-ipa-dump "Not parsed function:f_._omp_fn.1" "icf" } }
+! { dg-final { scan-ipa-dump "Not parsed function:f_._omp_fn.0" "icf" } }
+! { dg-final { scan-ipa-dump "Not parsed function:f_" "icf" } }

[PATCH] Add support for Fuchsia (OS)

[Josh Conner]

This patch adds support to gcc for the Fuchsia OS 
(https://fuchsia.googlesource.com/).


OK for mainline?

Thanks -

Josh


2016-12-08  Joshua Conner  


* config/arm/fuchsia-elf.h: New file.

* config/fuchsia.h: New file.

* config.gcc (*-*-fuchsia*): Set native_system_header_dir.

(aarch64*-*-fuchsia*, arm*-*-fuchsia*, x86_64-*-fuchsia*): Add to 
targets.


* config.host: (aarch64*-*-fuchsia*, arm*-*-fuchsia*): Add to hosts.


Index: gcc/config/arm/fuchsia-elf.h
===
--- gcc/config/arm/fuchsia-elf.h(revision 0)
+++ gcc/config/arm/fuchsia-elf.h(working copy)
@@ -0,0 +1,31 @@
+/* Configuration file for ARM Fuchsia ELF targets.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+   Contributed by Google.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+/* Use the BPABI builtins and the generic OS builtins.  */
+#undef  TARGET_SUB_OS_CPP_BUILTINS
+#define TARGET_SUB_OS_CPP_BUILTINS()   \
+  TARGET_BPABI_CPP_BUILTINS()
+
+/* Use the AAPCS ABI by default.  */
+#undef ARM_DEFAULT_ABI
+#define ARM_DEFAULT_ABI ARM_ABI_AAPCS
+
+#define ARM_TARGET2_DWARF_FORMAT (DW_EH_PE_pcrel | DW_EH_PE_indirect)
+
Index: gcc/config/fuchsia.h
===
--- gcc/config/fuchsia.h(revision 0)
+++ gcc/config/fuchsia.h(working copy)
@@ -0,0 +1,64 @@
+/* Base configuration file for all Fuchsia targets.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* Common Fuchsia configuration.  */
+
+#undef  STARTFILE_SPEC
+#define STARTFILE_SPEC "%{!shared: crt1%O%s} crtbegin%O%s"
+
+#undef  ENDFILE_SPEC
+#define ENDFILE_SPEC "crtend%O%s"
+
+/* Build with PIC by default.  */
+#undef  CC1_SPEC
+#define CC1_SPEC "%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC"
+
+#undef  LIB_SPEC
+#define LIB_SPEC "-lmxio -lmagenta -lc -llaunchpad" \
+"%{!static: -lgcc_s}"
+
+#undef  LINK_SPEC
+#define LINK_SPEC "-z max-page-size=4096" \
+ " -z combreloc" \
+ " -z relro" \
+ " -z now" \
+ " -z text" \
+ "%{!hash-style: --hash-style=gnu}" \
+ "%{!no-eh-frame-hdr: --eh-frame-hdr}" \
+ "%{!no-build-id: --build-id}" \
+ "%{shared: -shared}" \
+ "%{!shared:%{!static:%{!dynamic-linker: 
-dynamic-linker=ld.so.1}}}"
+
+/* We are using MUSL as our libc.  */
+#undef  OPTION_MUSL
+#define OPTION_MUSL 1
+
+#ifndef TARGET_SUB_OS_CPP_BUILTINS
+#define TARGET_SUB_OS_CPP_BUILTINS()
+#endif
+
+#undef  TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+  builtin_define ("__fuchsia__");  \
+  TARGET_SUB_OS_CPP_BUILTINS();\
+}  \
+  while (false)
+
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 243452)
+++ gcc/config.gcc  (working copy)
@@ -706,6 +706,9 @@
   esac
   use_gcc_stdint=wrap
   ;;
+*-*-fuchsia*)
+  native_system_header_dir=/include
+  ;;
 *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* | 
*-*-kopensolaris*-gnu)
   extra_options="$extra_options gnu-user.opt"
   gas=yes
@@ -908,7 +911,7 @@
 esac
 
 case ${target} in
-aarch64*-*-elf | aarch64*-*-rtems*)
+aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-elf-raw.h"

[PATCH, rs6000] Use new pass registration framework for analyze_swaps

[Bill Schmidt]

Hi,

Back in October
(https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00256.html), Jakub
updated the target pass registration framework so that target passes act
more like regular passes:  their dumps are numbered in proper order, and
use of dump options like -details now works.  I've finally gotten around
to updating the rs6000 back end to take advantage of this.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  I've verified that the "swaps" dump now appears with
proper numbering:

-rw-rw-r--  1 wschmidt wschmidt 3815 Dec  8 16:40 swaps-p8-17.c.232r.dfinit
-rw-rw-r--  1 wschmidt wschmidt 5092 Dec  8 16:40 swaps-p8-17.c.233r.swaps
-rw-rw-r--  1 wschmidt wschmidt 9751 Dec  8 16:40 swaps-p8-17.c.234r.cse1

Is this ok for trunk?

Thanks,
Bill


2016-12-08  Bill Schmidt  

* config/rs6000/rs6000-passes.def: New file.
* config/rs6000/rs6000-protos.h: Declare make_pass_analyze_swaps.
* config/rs6000/rs6000.c (rs6000_option_override): Remove
registration of machine-specific passes.
(pass_analyze_swaps::clone): New function.
* config/rs6000/t-rs6000: Define PASSES_EXTRA.


Index: gcc/config/rs6000/rs6000-passes.def
===
--- gcc/config/rs6000/rs6000-passes.def (revision 0)
+++ gcc/config/rs6000/rs6000-passes.def (working copy)
@@ -0,0 +1,27 @@
+/* Description of target passes for rs6000
+   Copyright (C) 2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/*
+   Macros that can be used in this file:
+   INSERT_PASS_AFTER (PASS, INSTANCE, TGT_PASS)
+   INSERT_PASS_BEFORE (PASS, INSTANCE, TGT_PASS)
+   REPLACE_PASS (PASS, INSTANCE, TGT_PASS)
+ */
+
+  INSERT_PASS_BEFORE (pass_cse, 1, pass_analyze_swaps);
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 243441)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -258,4 +258,11 @@ extern unsigned char rs6000_class_max_nregs[][LIM_
 extern unsigned char rs6000_hard_regno_nregs[][FIRST_PSEUDO_REGISTER];
 
 extern bool rs6000_linux_float_exceptions_rounding_supported_p (void);
+
+/* Pass management.  */
+namespace gcc { class context; }
+class rtl_opt_pass;
+
+extern rtl_opt_pass *make_pass_analyze_swaps (gcc::context *);
+
 #endif  /* rs6000-protos.h */
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 243441)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5203,15 +5203,6 @@ static void
 rs6000_option_override (void)
 {
   (void) rs6000_option_override_internal (true);
-
-  /* Register machine-specific passes.  This needs to be done at start-up.
- It's convenient to do it here (like i386 does).  */
-  opt_pass *pass_analyze_swaps = make_pass_analyze_swaps (g);
-
-  struct register_pass_info analyze_swaps_info
-= { pass_analyze_swaps, "cse1", 1, PASS_POS_INSERT_BEFORE };
-
-  register_pass (_swaps_info);
 }
 
 
@@ -41865,6 +41856,11 @@ class pass_analyze_swaps : public rtl_opt_pass
   return rs6000_analyze_swaps (fun);
 }
 
+  opt_pass *clone ()
+{
+  return new pass_analyze_swaps (m_ctxt);
+}
+
 }; // class pass_analyze_swaps
 
 rtl_opt_pass *
Index: gcc/config/rs6000/t-rs6000
===
--- gcc/config/rs6000/t-rs6000  (revision 243441)
+++ gcc/config/rs6000/t-rs6000  (working copy)
@@ -20,6 +20,7 @@
 
 TM_H += $(srcdir)/config/rs6000/rs6000-builtin.def
 TM_H += $(srcdir)/config/rs6000/rs6000-cpus.def
+PASSES_EXTRA += $(srcdir)/config/rs6000/rs6000-passes.def
 
 rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c
$(COMPILE) $<

Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

[Mikael Morin]

Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :

Hi all, hi Dominique,

this is the "compile time part 1" (ctp1) patch to fix the issues reported in
gfortran by a sanitized compiler when compiling the testsuite. The patch
addresses all issues besides leaks (ASAN_OPTIONS="detect_leaks=false". Most of
the issues were about assuming certain kinds of data without explicitly
checking, e.g., taking a component-ref for an array-ref and similar.

So this patch only addresses the -fsanitize=address,undefined reports (without
leaks) for running the compiler. I liked to keep this patch small to get it
reviewed quickly.

I see some other areas of work:

compile time part 2: address the leaks
testsuite run time: address the runtime issues (might have to be split in
others and leaks, too)

So far, is this patch bootstrapping and regtesting fine on x86_64-linux/f23. Ok
for trunk?

Regards,
Andre

PS: @Dominique: I will not commit before you are better and had the time to
test this.


diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 139ce88..4f835b3 100644
--- a/gcc/fortran/data.c
+++ b/gcc/fortran/data.c
@@ -186,7 +186,7 @@ create_character_initializer (gfc_expr *init, gfc_typespec 
*ts,
   for (i = 0; i < len; i++)
dest[start+i] = rvalue->representation.string[i];
 }
-  else
+  else if (rvalue->value.character.string)

This one looks fishy.
Either rvalue is a character constant and its string should be set, or 
it’s not a character constant and the value.character.string should not 
be accessed at all.




 memcpy ([start], rvalue->value.character.string,
len * sizeof (gfc_char_t));

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 8afba84..4e4d17c 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2803,6 +2803,7 @@ compare_actual_formal (gfc_actual_arglist **ap, 
gfc_formal_arglist *formal,
   int i, n, na;
   unsigned long actual_size, formal_size;
   bool full_array = false;
+  gfc_ref *actual_arr_ref;

   actual = *ap;

@@ -2942,37 +2943,38 @@ compare_actual_formal (gfc_actual_arglist **ap, 
gfc_formal_arglist *formal,
 and assumed-shape dummies, the string length needs to match
 exactly.  */
   if (a->expr->ts.type == BT_CHARACTER
-  && a->expr->ts.u.cl && a->expr->ts.u.cl->length
-  && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT
-  && f->sym->ts.u.cl && f->sym->ts.u.cl && f->sym->ts.u.cl->length
-  && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT
-  && (f->sym->attr.pointer || f->sym->attr.allocatable
-  || (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE))
-  && (mpz_cmp (a->expr->ts.u.cl->length->value.integer,
-   f->sym->ts.u.cl->length->value.integer) != 0))
-{
-  if (where && (f->sym->attr.pointer || f->sym->attr.allocatable))
-gfc_warning (OPT_Wargument_mismatch,
- "Character length mismatch (%ld/%ld) between actual "
- "argument and pointer or allocatable dummy argument "
- "%qs at %L",
- mpz_get_si (a->expr->ts.u.cl->length->value.integer),
- mpz_get_si (f->sym->ts.u.cl->length->value.integer),
- f->sym->name, >expr->where);
-  else if (where)
-gfc_warning (OPT_Wargument_mismatch,
- "Character length mismatch (%ld/%ld) between actual "
- "argument and assumed-shape dummy argument %qs "
- "at %L",
- mpz_get_si (a->expr->ts.u.cl->length->value.integer),
- mpz_get_si (f->sym->ts.u.cl->length->value.integer),
- f->sym->name, >expr->where);
-  return 0;
-}
+ && a->expr->ts.u.cl && a->expr->ts.u.cl->length
+ && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT
+ && f->sym->ts.type == BT_CHARACTER && f->sym->ts.u.cl
+ && f->sym->ts.u.cl->length
+ && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT
+ && (f->sym->attr.pointer || f->sym->attr.allocatable
+ || (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE))
+ && (mpz_cmp (a->expr->ts.u.cl->length->value.integer,
+  f->sym->ts.u.cl->length->value.integer) != 0))
+   {
+ if (where && (f->sym->attr.pointer || f->sym->attr.allocatable))
+   gfc_warning (OPT_Wargument_mismatch,
+"Character length mismatch (%ld/%ld) between actual "
+"argument and pointer or allocatable dummy argument "
+"%qs at %L",
+mpz_get_si (a->expr->ts.u.cl->length->value.integer),
+mpz_get_si (f->sym->ts.u.cl->length->value.integer),
+f->sym->name, >expr->where);
+ else 

[Bug fortran/78737] linking error with deferred, undefined user-defined derived-type I/O

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Upon further investigation, the workaround mentioned in the final line of the
original report appears not to work.  The only workaround I have come up with
is to make the "object" type non-abstract, which then necessitates making the
write_formatted binding non-deferred, which then necessitates replacing the
abstract interface with an actual implementation. It's pretty major surgery,
but not the worst problem in the world.

Re: parallel_algorithm_assert2.cc

[David Edelsohn]

On Thu, Dec 8, 2016 at 10:03 AM, Jonathan Wakely  wrote:
> On 8 December 2016 at 17:09, David Edelsohn wrote:
>> Jonathan,
>>
>> I'm seeing a new failure on AIX.
>>
>> FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
>> (test for excess errors)
>> Excess errors:
>> xg++: error: libgomp.spec: No such file or directory
>>
>> Does the testsuite driver assume that libgomp.spec already is
>> installed in the correct install location?
>
> Ah, I think the DG directives are in the wrong order.
>
> Does this help?
>
> --- 
> a/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
> +++ 
> b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
> @@ -1,6 +1,6 @@
> -// { dg-require-parallel-mode "" }
>  // { dg-options "-fopenmp -D_GLIBCXX_PARALLEL" { target *-*-* } }
>  // { dg-do run }
> +// { dg-require-parallel-mode "" }
>
>  // Copyright (C) 2016 Free Software Foundation, Inc.
>  //

Placing the dg-do run directive first fixes the problem.  That is what
I committed.

Thanks, David

gcc-6-20161208 is now available

[gccadmin]

Snapshot gcc-6-20161208 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161208/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 243467

You'll find:

 gcc-6-20161208.tar.bz2   Complete GCC

  MD5=99218a771c7dc60504793ba237f72e46
  SHA1=178e3a72f76162966da57bcd0cb4094d0b3bed2c

Diffs from 6-20161201 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
So my patches for 33562 will detect the partial dead store in "foo", but I
never wrote the bits to narrow partial dead stores.

The difficulty in optimizing this particular case will be rewriting the
CONSTRUCTOR node.  Though it may be as simple as walking down the CONSTRUCTOR
and splicing out components which correspond to dead assignments -- I'll have
to familiarize myself with the guts of how to walk CONSTRUCTOR nodes. 
Hopefully they're at least in-order and extracting byte offsets is easy :-)

[Bug fortran/78737] linking error with deferred, undefined user-defined derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

--- Comment #1 from Jerry DeLisle  ---
I cc'ed Paul on this one. Not sure what is going on here, but I will be looking
at it.

GCC Subversion tree conflicts

[Ethin Probst]

While checking out the latest GCC SVN branch (rev. 243,465 as of
December 08, 2016), the following conflicts were detected by
subversion:
[subversion output]
Summary of conflicts:
  Tree conflicts: 34
Tree conflict on 'gcc/INSTALL'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h

  (r)  - accept current working copy state
  (p)  - resolve the conflict later  [postpone]
  (q)  - postpone all remaining conflicts
  (h)  - show this help (also '?')
Words in square brackets are the corresponding --accept option arguments.

Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/INSTALL'
Tree conflict on 'gcc/config'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/config'
Tree conflict on 'gcc/contrib'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/contrib'
Tree conflict on 'gcc/fixincludes'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/fixincludes'
Tree conflict on 'gcc/gcc'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/gcc'
Tree conflict on 'gcc/gnattools'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/gnattools'
Tree conflict on 'gcc/gotools'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/gotools'
Tree conflict on 'gcc/include'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/include'
Tree conflict on 'gcc/intl'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/intl'
Tree conflict on 'gcc/libada'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libada'
Tree conflict on 'gcc/libatomic'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libatomic'
Tree conflict on 'gcc/libbacktrace'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libbacktrace'
Tree conflict on 'gcc/libcc1'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libcc1'
Tree conflict on 'gcc/libcilkrts'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libcilkrts'
Tree conflict on 'gcc/libcpp'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libcpp'
Tree conflict on 'gcc/libdecnumber'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libdecnumber'
Tree conflict on 'gcc/libffi'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libffi'
Tree conflict on 'gcc/libgcc'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libgcc'
Tree conflict on 'gcc/libgfortran'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libgfortran'
Tree conflict on 'gcc/libgo'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libgo'
Tree conflict on 'gcc/libgomp'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r
Resolved conflicted state of 'gcc/libgomp'
Tree conflict on 'gcc/libiberty'
   > local dir unversioned, incoming dir add upon update
Select: (r) mark resolved, (p) postpone, (q) quit resolution, 

Re: [Patch, fortran, RFC] Add warning for missing location information

[Mikael Morin]

Le 08/12/2016 à 22:50, Thomas Koenig a écrit :

Am 08.12.2016 um 21:01 schrieb Mikael Morin:

Le 08/12/2016 à 20:26, Thomas Koenig a écrit :

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked
the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.



Hello,

I have one comment.

This error;
+gfc_warning_internal (0, "No location in statement statement");

is not very helpful, especially without location.



Could you at least provide the statement type? There is
gfc_ascii_statement you can use for that.


gfc_ascii_statement works with gfc_statement only,
here, we are dealing with gfc_exec_op.


Of course. :-(


What I could do is to add a gfc_debug_code function to
dump-parse-tree and add a comment that, if this part of
the code is encountered, you should examine the expression
using that particular function call using a debugger.

Of course, I could also just dump the statement to stderr,
but somehow that does not quite conform to all the elegang
error handling infrastructure in gcc :-)


Yes, please don’t do that.


So, what do people think?

As the code is disabled for releases anyway, I don’t mind the patch 
getting in as is. So OK from my side.

[C++ PATCH] P0490R0 GB 20: decomposition declaration should commit to tuple interpretation early

[Jakub Jelinek]

Hi!

Issaquah papers have been recently published and there are two
decomp changes.  One I've sent a partially working patch privately and am
lost with, the other one is that whenever std::tuple_size is a
complete type, we should commit to the std::tuple* way - so if it is
missing value static data member/enum or it isn't a constant expression
we should just error out instead of trying to decompose as other structs.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or shall I move the diagnostics from get_tuple_size to the caller (only
return error_mark_node from there)?

2016-12-08  Jakub Jelinek  

P0490R0 GB 20: decomposition declaration should commit to tuple
interpretation early
* decl.c (get_tuple_size): Add LOC argument, make static.  If
inst is error_mark_node or non-complete type, return NULL_TREE,
otherwise if lookup_qualified_name fails or doesn't fold into
INTEGER_CST, complain and return error_mark_node.
(get_tuple_element_type, get_tuple_decomp_init): Make static.
(cp_finish_decomp): Pass LOC to get_tuple_size.  If it returns
error_mark_node, fail.

* g++.dg/cpp1z/decomp10.C (f1): Adjust expected diagnostics.

--- gcc/cp/decl.c.jj2016-12-07 17:19:10.0 +0100
+++ gcc/cp/decl.c   2016-12-08 16:52:10.029095252 +0100
@@ -7259,8 +7259,8 @@ find_decomp_class_base (location_t loc,
 
 /* Return std::tuple_size::value.  */
 
-tree
-get_tuple_size (tree type)
+static tree
+get_tuple_size (location_t loc, tree type)
 {
   tree args = make_tree_vec (1);
   TREE_VEC_ELT (args, 0) = type;
@@ -7268,6 +7268,11 @@ get_tuple_size (tree type)
 /*in_decl*/NULL_TREE,
 /*context*/std_node,
 /*entering_scope*/false, tf_none);
+  if (inst == error_mark_node)
+return NULL_TREE;
+  inst = complete_type (inst);
+  if (!COMPLETE_TYPE_P (inst))
+return NULL_TREE;
   tree val = lookup_qualified_name (inst, get_identifier ("value"),
/*type*/false, /*complain*/false);
   if (TREE_CODE (val) == VAR_DECL || TREE_CODE (val) == CONST_DECL)
@@ -7275,12 +7280,16 @@ get_tuple_size (tree type)
   if (TREE_CODE (val) == INTEGER_CST)
 return val;
   else
-return NULL_TREE;
+{
+  error_at (loc, "%::value%> is not an integral "
+"constant expression", type);
+  return error_mark_node;
+}
 }
 
 /* Return std::tuple_element::type.  */
 
-tree
+static tree
 get_tuple_element_type (tree type, unsigned i)
 {
   tree args = make_tree_vec (2);
@@ -7297,7 +7306,7 @@ get_tuple_element_type (tree type, unsig
 
 /* Return e.get() or get(e).  */
 
-tree
+static tree
 get_tuple_decomp_init (tree decl, unsigned i)
 {
   tree get_id = get_identifier ("get");
@@ -7342,6 +7351,7 @@ store_decomp_type (tree v, tree t)
 decomp_type_table = hash_map::create_ggc (13);
   decomp_type_table->put (v, t);
 }
+
 tree
 lookup_decomp_type (tree v)
 {
@@ -7500,8 +7510,10 @@ cp_finish_decomp (tree decl, tree first,
  DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
}
 }
-  else if (tree tsize = get_tuple_size (type))
+  else if (tree tsize = get_tuple_size (loc, type))
 {
+  if (tsize == error_mark_node)
+   goto error_out;
   eltscnt = tree_to_uhwi (tsize);
   if (count != eltscnt)
goto cnt_mismatch;
--- gcc/testsuite/g++.dg/cpp1z/decomp10.C.jj2016-11-15 09:57:00.0 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp10.C   2016-12-08 16:48:55.833555410 
+0100
@@ -7,7 +7,7 @@ namespace std {
 
 struct A1 { int i,j; } a1;
 template<> struct std::tuple_size {  };
-void f1() { auto [ x ] = a1; } // { dg-error "decomposes into 2" }
+void f1() { auto [ x ] = a1; } // { dg-error "is not an integral constant 
expression" }
 
 struct A2 { int i,j; } a2;
 template<> struct std::tuple_size { enum { value = 5 }; };


Jakub

[PATCH] Reassoc zero_one_operation fixes (PR tree-optimization/78726)

[Jakub Jelinek]

Hi!

The following testcases show two bugs in zero_one_operation (used during
undistribute optimization) and functions it calls.
The first one (wrong-code) is fixed by the
+  tree orig_def = *def;
and
-  if (stmts_to_fix.length () > 0)
+  if (stmts_to_fix.length () > 0 || *def == orig_def)
changes in zero_one_operation - e.g. in the testcase we have before reassoc
  _6 = _5 * a_11;
  _7 = _5 * _6;
and call zero_one_operation for _7 with op a_11.  The last stmt isn't pushed
into stmts_to_fix, the *def stmt is handled specially in
make_new_ssa_for_all_defs.  And the previous one, while it is pushed, it is
popped from there again, because the stmt is removed and instead _6 use
is replaced with _5.  That changes what value _7 holds, so we want to use
a new SSA_NAME for it (or deal with debug stmts and reset flow sensitive
info etc.).

The second one is wrong-debug, make_new_ssa_for_def replaces the uses of old
lhs with the new lhs (which is fine in the code uses, but for debug info
because we zeroed out a_11 we want to say that previous uses of _7 are now
the _7's replacement * a_11.  Which is what the rest of the patch does
and there is a guality testcase that verifies it (previously it would fail).

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

2016-12-08  Jakub Jelinek  

PR tree-optimization/78726
* tree-ssa-reassoc.c (make_new_ssa_for_def): Add OPCODE and OP
argument.  For lhs uses in debug stmts, don't replace lhs with
new_lhs, but with a debug temp set to new_lhs opcode op.
(make_new_ssa_for_all_defs): Add OPCODE argument, pass OPCODE and
OP down to make_new_ssa_for_def.
(zero_one_operation): Call make_new_ssa_for_all_defs even when
stmts_to_fix is empty, if *def has not changed yet.  Pass
OPCODE to make_new_ssa_for_all_defs.

* gcc.c-torture/execute/pr78726.c: New test.
* gcc.dg/guality/pr78726.c: New test.

--- gcc/tree-ssa-reassoc.c.jj   2016-11-09 16:34:58.0 +0100
+++ gcc/tree-ssa-reassoc.c  2016-12-08 15:53:13.768894146 +0100
@@ -1153,12 +1153,12 @@ decrement_power (gimple *stmt)
SSA.  Also return the new SSA.  */
 
 static tree
-make_new_ssa_for_def (gimple *stmt)
+make_new_ssa_for_def (gimple *stmt, enum tree_code opcode, tree op)
 {
   gimple *use_stmt;
   use_operand_p use;
   imm_use_iterator iter;
-  tree new_lhs;
+  tree new_lhs, new_debug_lhs = NULL_TREE;
   tree lhs = gimple_get_lhs (stmt);
 
   new_lhs = make_ssa_name (TREE_TYPE (lhs));
@@ -1167,8 +1167,28 @@ make_new_ssa_for_def (gimple *stmt)
   /* Also need to update GIMPLE_DEBUGs.  */
   FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
 {
+  tree repl = new_lhs;
+  if (is_gimple_debug (use_stmt))
+   {
+ if (new_debug_lhs == NULL_TREE)
+   {
+ new_debug_lhs = make_node (DEBUG_EXPR_DECL);
+ gdebug *def_temp
+   = gimple_build_debug_bind (new_debug_lhs,
+  build2 (opcode, TREE_TYPE (lhs),
+  new_lhs, op),
+  stmt);
+ DECL_ARTIFICIAL (new_debug_lhs) = 1;
+ TREE_TYPE (new_debug_lhs) = TREE_TYPE (lhs);
+ SET_DECL_MODE (new_debug_lhs, TYPE_MODE (TREE_TYPE (lhs)));
+ gimple_set_uid (def_temp, gimple_uid (stmt));
+ gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
+ gsi_insert_after (, def_temp, GSI_SAME_STMT);
+   }
+ repl = new_debug_lhs;
+   }
   FOR_EACH_IMM_USE_ON_STMT (use, iter)
-   SET_USE (use, new_lhs);
+   SET_USE (use, repl);
   update_stmt (use_stmt);
 }
   return new_lhs;
@@ -1179,7 +1199,7 @@ make_new_ssa_for_def (gimple *stmt)
if *DEF is not OP.  */
 
 static void
-make_new_ssa_for_all_defs (tree *def, tree op,
+make_new_ssa_for_all_defs (tree *def, enum tree_code opcode, tree op,
   vec _to_fix)
 {
   unsigned i;
@@ -1189,10 +1209,10 @@ make_new_ssa_for_all_defs (tree *def, tr
   && TREE_CODE (*def) == SSA_NAME
   && (stmt = SSA_NAME_DEF_STMT (*def))
   && gimple_code (stmt) != GIMPLE_NOP)
-*def = make_new_ssa_for_def (stmt);
+*def = make_new_ssa_for_def (stmt, opcode, op);
 
   FOR_EACH_VEC_ELT (stmts_to_fix, i, stmt)
-make_new_ssa_for_def (stmt);
+make_new_ssa_for_def (stmt, opcode, op);
 }
 
 /* Find the single immediate use of STMT's LHS, and replace it
@@ -1232,6 +1252,7 @@ propagate_op_to_single_use (tree op, gim
 static void
 zero_one_operation (tree *def, enum tree_code opcode, tree op)
 {
+  tree orig_def = *def;
   gimple *stmt = SSA_NAME_DEF_STMT (*def);
   /* PR72835 - Record the stmt chain that has to be updated such that
  we dont use the same LHS when the values computed are different.  */
@@ -1335,8 +1356,8 @@ zero_one_operation (tree *def, enum tree
 }
   while (1);
 
-  if (stmts_to_fix.length () > 0)
-

Re: [Patch, fortran, RFC] Add warning for missing location information

[Thomas Koenig]

Am 08.12.2016 um 21:01 schrieb Mikael Morin:

Le 08/12/2016 à 20:26, Thomas Koenig a écrit :

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked
the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.



Hello,

I have one comment.

This error;
+gfc_warning_internal (0, "No location in statement statement");

is not very helpful, especially without location.



Could you at least provide the statement type? There is
gfc_ascii_statement you can use for that.


gfc_ascii_statement works with gfc_statement only,
here, we are dealing with gfc_exec_op.

What I could do is to add a gfc_debug_code function to
dump-parse-tree and add a comment that, if this part of
the code is encountered, you should examine the expression
using that particular function call using a debugger.

Of course, I could also just dump the statement to stderr,
but somehow that does not quite conform to all the elegang
error handling infrastructure in gcc :-)

So, what do people think?

Regards

Thomas

Re: [PATCH 5/9] Introduce selftest::locate_file (v4)

[David Malcolm]

On Thu, 2016-12-01 at 14:29 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > +  /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so
> > that
> > + flag_self_test contains the path to the selftest subdirectory
> > of the
> > + source tree (without a trailing slash).  Copy it up to
> > + path_to_selftest_files, to avoid selftest.c depending on
> > + option-handling.  */
> > +  path_to_selftest_files = flag_self_test;
> > +
> 
> What kind of dependency are you avoiding? If it's just one include
> I'd 
> prefer to get rid of the extraneous variable.
> 
> Otherwise ok.

I attempted to eliminate the global, and include "options.h" from
selftest.c, and to use flag_self_test directly (implicitly accessing
the global_options global).

The *code* changes were relatively simple, with only one extra
#include.

However, from a linker perspective, it's more awkward.  selftest.o is
used by (amongst other things) OBJS-libcommon: libcommon.a currently
has selftest.o, but doesn't have options.o.  Various things in
libcommon.a use selftest.o for selftests and thus libcommon.a needs
selftest.o.

Hence doing so brings in a dependency on the option-handling objects
into libcommon.a, which seems wrong to me.

It seems simplest to go with either:

(A) the approach in the patch, with an extra global, keeping the
selftest code independent from gcc's option-handling code (both at
compile time and link time) or

(B) add the path as an extra param, passing it in at all callsites,
so that every
   locate_file (some_path)
in the kit becomes
   locate_file (flag_self_test, some_path)

Is (A) OK, or would you prefer (B)?   (I prefer (A) fwiw)

Thanks
Dave

[PATCH, middle-end]: Fix PR78738, unrecognized insn with -ffast-math

[Uros Bizjak]

Hello!

Attached patch fixes fall-out from excess-precision improvements
patch. As shown in the PR, the code throughout the compiler assumes
FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is in
effect. The patch puts back two lines, removed by excess-precision
improvements patch.

2016-12-08  Uros Bizjak  

PR middle-end/78738
* toplev.c (init_excess_precision): Initialize flag_excess_precision
to EXCESS_PRECISION_FAST for flag_unsafe_math_optimizations.

testsuite/ChangeLog:

2016-12-08  Uros Bizjak  

PR middle-end/78738
* gcc.target/i386/pr78738.c: New test.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

OK for mainline?

Uros.
Index: testsuite/gcc.target/i386/pr78738.c
===
--- testsuite/gcc.target/i386/pr78738.c (nonexistent)
+++ testsuite/gcc.target/i386/pr78738.c (working copy)
@@ -0,0 +1,10 @@
+/* PR middle-end/78738 */
+/* { dg-do compile } */
+/* { dg-options "-O -std=c99 -ffast-math -mfpmath=387" } */
+
+double round (double);
+
+int foo (double a)
+{
+  return round (a);
+}
Index: toplev.c
===
--- toplev.c(revision 243456)
+++ toplev.c(working copy)
@@ -1691,6 +1691,8 @@ init_excess_precision (void)
 {
   gcc_assert (flag_excess_precision_cmdline != EXCESS_PRECISION_DEFAULT);
   flag_excess_precision = flag_excess_precision_cmdline;
+  if (flag_unsafe_math_optimizations)
+flag_excess_precision = EXCESS_PRECISION_FAST;
 }
 
 /* Initialize things that are both lang-dependent and target-dependent.

Re: [PATCH] PR fortran/65173 -- kill off old_cl_list from gfc_namespace.

[Steve Kargl]

On Thu, Dec 08, 2016 at 07:58:37AM +0100, Paul Richard Thomas wrote:
> 
> "Accidence" == state of fixing non-deterministic ICEs? :-)
> 
> OK for trunk.
> 
> Thanks for dealing with this kind of dead wood.
> 

Committed revision 243463.

-- 
Steve

[Bug fortran/78350] ICE in gfc_code2string(): Bad code, at fortran/misc.c:193

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|WAITING |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing.

[Bug fortran/65173] ICE while compiling wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0
   Severity|minor   |normal

--- Comment #14 from kargl at gcc dot gnu.org ---
Fixed on trunk. Closing.

[Bug fortran/69064] [5/6/7 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|5.5 |7.0
   Severity|minor   |normal

--- Comment #55 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing.

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing

[Bug fortran/65173] ICE while compiling wrong code

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463=gcc=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

[Bug fortran/69064] [5/6/7 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type

[kargl at gcc dot gnu.org]

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

--- Comment #54 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463=gcc=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

[Bug fortran/78350] ICE in gfc_code2string(): Bad code, at fortran/misc.c:193

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463=gcc=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463=gcc=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

patch to fix PR78671

[Vladimir N Makarov]

The following patch fixes

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

The patch was successfully bootstrapped and tested on x86-64.

Committed as rev. 243462.


Index: ChangeLog
===
--- ChangeLog	(revision 243461)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2016-12-08  Vladimir Makarov  
+
+	PR rtl-optimization/78671
+	* lra-assign.c (lra-assigns.c): Check prohibited regs for an
+	allocno class.
+
 2016-12-08  Uros Bizjak  
 
 	* gcc.target/i386/i386.h (HARD_REGNO_NREGS): Use GENERAL_REGNO_P.
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 243461)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2016-12-08  Vladimir Makarov  
+
+	PR rtl-optimization/78671
+	* gcc.target/i386/pr78671.c: New.
+
 2015-12-08  Wilco Dijkstra  
 
 	PR target/78733
Index: lra-assigns.c
===
--- lra-assigns.c	(revision 243305)
+++ lra-assigns.c	(working copy)
@@ -628,9 +628,13 @@ find_hard_regno_for_1 (int regno, int *c
 	hard_regno = ira_class_hard_regs[rclass][i];
   if (! overlaps_hard_reg_set_p (conflict_set,
  PSEUDO_REGNO_MODE (regno), hard_regno)
-	  /* We can not use prohibited_class_mode_regs because it is
-	 not defined for all classes.  */
 	  && HARD_REGNO_MODE_OK (hard_regno, PSEUDO_REGNO_MODE (regno))
+	  /* We can not use prohibited_class_mode_regs for all classes
+	 because it is not defined for all classes.  */
+	  && (ira_allocno_class_translate[rclass] != rclass
+	  || ! TEST_HARD_REG_BIT (ira_prohibited_class_mode_regs
+  [rclass][PSEUDO_REGNO_MODE (regno)],
+  hard_regno))
 	  && ! TEST_HARD_REG_BIT (impossible_start_hard_regs, hard_regno)
 	  && (nregs_diff == 0
 	  || (WORDS_BIG_ENDIAN
Index: testsuite/gcc.target/i386/pr78671.c
===
--- testsuite/gcc.target/i386/pr78671.c	(revision 0)
+++ testsuite/gcc.target/i386/pr78671.c	(working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-march=skylake-avx512 -Og" } */
+
+typedef unsigned __int128 u128;
+typedef unsigned __int128 v64u128 __attribute__ ((vector_size (64)));
+
+v64u128
+foo (u128 u128_3, v64u128 v64u128_3, v64u128 v64u128_2, v64u128 v64u128_1,
+ v64u128 v64u128_0)
+{
+  v64u128_0 <<= 1;
+  v64u128_2 >>= 0 != v64u128_2;
+  v64u128_3[v64u128_3[0]] &= 1;
+  v64u128_3 = v64u128_3 & 1;
+  v64u128_2 = v64u128_2 >> 1 | v64u128_2 << v64u128_1[0];
+  v64u128_0[0] >>= 127;
+  return u128_3 + v64u128_0 + v64u128_2 + v64u128_3;
+}

[Bug rtl-optimization/78671] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213 with -Og -march=skylake-avx512

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Dec  8 21:14:42 2016
New Revision: 243462

URL: https://gcc.gnu.org/viewcvs?rev=243462=gcc=rev
Log:
2016-12-08  Vladimir Makarov  

PR rtl-optimization/78671
* lra-assign.c (lra-assigns.c): Check prohibited regs for an
allocno class.

2016-12-08  Vladimir Makarov  

PR rtl-optimization/78671
* gcc.target/i386/pr78671.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78671.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug c/78165] avoid printing type suffix for constants in %E output

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Committed in r243461.

[Bug c/78165] avoid printing type suffix for constants in %E output

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  8 21:08:06 2016
New Revision: 243461

URL: https://gcc.gnu.org/viewcvs?rev=243461=gcc=rev
Log:
PR c/78165 - avoid printing type suffix for constants in %E output

gcc/c-family/ChangeLog:

PR c/78165
   * c-pretty-print (pp_c_integer_constant): Avoid formatting type
 suffix.
gcc/testsuite/ChangeLog:


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pretty-print.c
trunk/gcc/testsuite/g++.dg/debug/dwarf2/integer-typedef.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
trunk/gcc/testsuite/g++.dg/inherit/covariant7.C

Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Marek Polacek]

This test ICEs since r240072 where Tom disallowed using va_list * as a first
argument to va_arg.  I think the problem is in the ADDR_EXPR check in
gimplify_va_arg_expr.  It's meant to handle Case 1, but the valist doesn't
always have to be ADDR_EXPR.  E.g. for this testcase build_va_arg creates
VA_ARG_EXPR <&*s>
but during clone_body this is transformed into
VA_ARG_EXPR 
so we have a valid valist, but it's not an ADDR_EXPR, so we don't call
targetm.canonical_va_list_type and crash on the subsequent assert.

Tom, does this make sense to you?  [Although I haven't seen Tom here on ML
lately...]

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

2016-12-08  Marek Polacek  

PR middle-end/78716
* gimplify.c (gimplify_va_arg_expr): Don't require ADDR_EXPR for
Case 1.

* g++.dg/other/vararg-5.C: New.

diff --git gcc/gimplify.c gcc/gimplify.c
index 8611060..08c4faa 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -12642,8 +12642,7 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq *pre_p,
   if (have_va_type == error_mark_node)
 return GS_ERROR;
   have_va_type = targetm.canonical_va_list_type (have_va_type);
-  if (have_va_type == NULL_TREE
-  && TREE_CODE (valist) == ADDR_EXPR)
+  if (have_va_type == NULL_TREE)
 /* Handle 'Case 1: Not an array type' from c-common.c/build_va_arg.  */
 have_va_type
   = targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
diff --git gcc/testsuite/g++.dg/other/vararg-5.C 
gcc/testsuite/g++.dg/other/vararg-5.C
index e69de29..9327bd6 100644
--- gcc/testsuite/g++.dg/other/vararg-5.C
+++ gcc/testsuite/g++.dg/other/vararg-5.C
@@ -0,0 +1,24 @@
+// PR middle-end/78716
+// { dg-do compile }
+
+template 
+  struct a;
+  template  struct b;
+  template  class e : 
b::c {
+public:
+typedef e f;
+  typedef typename b::c g;
+e(__builtin_va_list *s) : g(__builtin_va_arg(*s, 
int)) {}
+  };
+template <> struct b { typedef e<> c; };
+template <> struct e<> { template  e(h); };
+template  class a : public e {};
+template 
+class a : e::f> {
+  public:
+  template 
+ a(a) : a::f(0) {}
+};
+template  a<> r(i, j, k, l);
+void q() { a(r(4, 6, 9, 7)); }

Marek

Re: Merge from trunk to gccgo branch

[Ian Lance Taylor]

I now merged trunk revision 243459 to the gccgo branch.

Ian

libgo patch committed: mark unused parameters as unused

[Ian Lance Taylor]

This patch to libgo marks the unused parameters in the non-x86 code of
the new file aeshash.c as unused, to avoid build warnings.
Bootstrapped on x86_64-pc-linux-gnu, test compiled using an ARM
cross-compiler.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 243445)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-78e3527fcaf4ffd33b22e39a56e5d076844302be
+ac59bb383e1b446c68465af793722dd0e84abefb
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/runtime/aeshash.c
===
--- libgo/runtime/aeshash.c (revision 243445)
+++ libgo/runtime/aeshash.c (working copy)
@@ -575,7 +575,10 @@ uintptr aeshashbody(void* p, uintptr see
 
 #else // !defined(__i386__) && !defined(__x86_64__)
 
-uintptr aeshashbody(void* p, uintptr seed, uintptr size, Slice aeskeysched) {
+uintptr aeshashbody(void* p __attribute__((unused)),
+   uintptr seed __attribute__((unused)),
+   uintptr size __attribute__((unused)),
+   Slice aeskeysched __attribute__((unused))) {
// We should never get here on a non-x86 system.
runtime_throw("impossible call to aeshashbody");
 }

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Martin Sebor]

On 12/08/2016 01:28 PM, Marek Polacek wrote:

On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:

On 12/08/2016 01:05 PM, Jason Merrill wrote:

If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.


What about:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
};

?  That ICEs in the same way.


My patch would make GCC to reject this too, but the new 'else' needs to
be removed from the patch, i.e.


Clang accepts this test case although it does reject the originally
submitted test case with the messages below.  I think GCC should
accept the latter case for compatibility.  If it is accepted then
rejecting the original test case will make the array initialization
irregular.  I think it would be nice if they both could accepted
but I don't know how much work it would be to make it work.

Martin

t.C:4:12: warning: in-class initialization of non-static data member is 
a C++11

  extension [-Wc++11-extensions]
  char a[] = "foo";
   ^
t.C:4:12: error: array bound cannot be deduced from an in-class initializer
t.C:3:8: warning: private field 'b' is not used [-Wunused-private-field]
  bool b;
   ^
t.C:4:8: warning: private field 'a' is not used [-Wunused-private-field]
  char a[] = "foo";
   ^
3 warnings and 1 error generated.

Re: Default associative containers constructors/destructor/assignment

[François Dumont]

On 06/12/2016 12:54, Jonathan Wakely wrote:

On 20/11/16 19:14 +0100, François Dumont wrote:
Talking about _M_color I just realize that move semantic doesn't copy 
_M_color. Shouldn't we capture it along with all the other _M_header 
information ?


Is it needed? I think the current code does the right thing, doesn't
it? I'd prefer not to change it without a testcase showing why we need
to.


I was hoping you knew it. So I kept it unchanged and will add to my TODO 
to check this.


Committed now.

François

[Bug middle-end/78738] [7 Regression] ICE in extract_insn, at recog.c:2311

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|rtl-optimization|middle-end
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |7.0

--- Comment #4 from Uroš Bizjak  ---
Testing a patch.

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Marek Polacek]

On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
> On 12/08/2016 01:05 PM, Jason Merrill wrote:
> > If the problem is the member initializer, we can diagnose that
> > directly rather than wait until we're in a constructor.
> 
> What about:
> struct Foo {
> int a;
> char ary[];
> Foo () : ary ("bob"){}
> };
> 
> ?  That ICEs in the same way.

My patch would make GCC to reject this too, but the new 'else' needs to
be removed from the patch, i.e.

2016-12-08  Marek Polacek  

PR c++/72775
* init.c (perform_member_init): Diagnose initialization of a flexible
array member in a constructor.

* g++.dg/ext/flexary20.C: New.

diff --git gcc/cp/init.c gcc/cp/init.c
index b4b6cdb..01009c9 100644
--- gcc/cp/init.c
+++ gcc/cp/init.c
@@ -800,6 +800,10 @@ perform_member_init (tree member, tree init)
   in that case.  */
init = build_x_compound_expr_from_list (init, ELK_MEM_INIT,
tf_warning_or_error);
+  if (TREE_CODE (type) == ARRAY_TYPE
+  && TYPE_DOMAIN (type) == NULL_TREE)
+   error_at (DECL_SOURCE_LOCATION (member),
+ "initialization of a flexible array member in a constructor");
 
   if (init)
finish_expr_stmt (cp_build_modify_expr (input_location, decl,
diff --git gcc/testsuite/g++.dg/ext/flexary20.C 
gcc/testsuite/g++.dg/ext/flexary20.C
index e69de29..ff97b06 100644
--- gcc/testsuite/g++.dg/ext/flexary20.C
+++ gcc/testsuite/g++.dg/ext/flexary20.C
@@ -0,0 +1,49 @@
+// PR c++/72775
+// { dg-do compile { target c++11 } }
+// { dg-options -Wno-pedantic }
+
+struct S {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  S () {}
+};
+
+struct T {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+};
+
+struct U {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  U ();
+};
+
+U::U() {}
+
+int
+main ()
+{
+  struct T t;
+}
+
+struct V {
+  int i;
+  struct W {
+int j;
+char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  } w;
+  V () {}
+};
+
+template 
+struct X {
+  int i;
+  T a[] = "foo"; // { dg-error "initialization of a flexible array member in a 
constructor" }
+};
+
+void
+fn ()
+{
+  struct X x;
+}

Marek

Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged trunk revision 243445 to the gccgo branch.

Ian

Re: [PATCH] Fix bug in MEM parsing in patches 8a/8b

[Bernd Schmidt]

On 12/08/2016 09:39 PM, David Malcolm wrote:


OK as adjustments to patches 8a and 8b?


Ok. Is it possible to adjust these macros to return something like a 
const reference to ensure people can't make this kind of error?



Bernd

[PATCH] Fix bug in MEM parsing in patches 8a/8b

[David Malcolm]

Testing the patch kit on i686 showed numerous failures of this
assertion in set_mem_attributes_minus_bitpos in emit-rtl.c:

  1821gcc_assert (!defattrs->offset_known_p);

when expanding "main" in the rtl.exp test files, after parsing
an __RTL-tagged function.

Root cause is various assignments within the RTL parser of the
form:

1222  MEM_OFFSET (x) = atoi (name.string);

where a MEM_* macro appears on the left-hand side of an assignment.

These macros are defined as a field lookup on the result of a call
to get_mem_attrs, e.g.:

  #define MEM_OFFSET(RTX) (get_mem_attrs (RTX)->offset)

get_mem_attrs can return the struct mem_attrs * of an rtx, but if
it isn't set, it returns:
   mode_mem_attrs[(int) GET_MODE (x)];

which is this field within struct GTY(()) target_rtl:
  /* The default memory attributes for each mode.  */
  struct mem_attrs *x_mode_mem_attrs[(int) MAX_MACHINE_MODE];

These assignments in the parser were erroneously writing to these
default per-mode values, rather than assigning to a unique-per-rtx
instance of struct mem_attrs.

The fix is to call the appropriate set_mem_ functions in the
parser, e.g. set_mem_offset; the patch below is intended as a tweak
to patch 8a of the kit, and would be merged with it before committing.

The patch also adds extra test coverage for MEM parsing.  This extends
the target-independent selftests, and so would go into patch 8b.

Tested for targets x86_64-pc-linux-gnu, i686-pc-linux-gnu,
and aarch64-linux-gnu, and on powerpc-ibm-aix7.1.3.0.

OK as adjustments to patches 8a and 8b?

For patch 8a:
  gcc/ChangeLog:
* read-rtl-function.c
(function_reader::handle_any_trailing_information): Replace writes
through macros MEM_ALIAS_SET, MEM_OFFSET, MEM_SIZE, MEM_ALIGN,
and MEM_ADDR_SPACE with calls to set_mem_ functions.  Add missing
call to unread_char when handling "A" for alignment.

For patch 8b:
  gcc/ChangeLog:
* read-rtl-function.c (selftest::test_loading_mem): New function.
(selftest::read_rtl_function_c_tests): Call it.
  gcc/testsuite/ChangeLog:
* selftests/mem.rtl: New file.
---
 gcc/read-rtl-function.c | 55 -
 gcc/testsuite/selftests/mem.rtl |  9 +++
 2 files changed, 58 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/selftests/mem.rtl

diff --git a/gcc/read-rtl-function.c b/gcc/read-rtl-function.c
index 5188b86..c3f5c64 100644
--- a/gcc/read-rtl-function.c
+++ b/gcc/read-rtl-function.c
@@ -1201,7 +1201,7 @@ function_reader::handle_any_trailing_information (rtx x)
  int ch;
  require_char_ws ('[');
  read_name ();
- MEM_ALIAS_SET (x) = atoi (name.string);
+ set_mem_alias_set (x, atoi (name.string));
  /* We have either a MEM_EXPR, or a space.  */
  if (peek_char () != ' ')
{
@@ -1218,8 +1218,7 @@ function_reader::handle_any_trailing_information (rtx x)
  if (ch == '+')
{
  read_name ();
- MEM_OFFSET_KNOWN_P (x) = 1;
- MEM_OFFSET (x) = atoi (name.string);
+ set_mem_offset (x, atoi (name.string));
}
  else
unread_char (ch);
@@ -1229,7 +1228,7 @@ function_reader::handle_any_trailing_information (rtx x)
  if (ch == 'S')
{
  read_name ();
- MEM_SIZE (x) = atoi (name.string);
+ set_mem_size (x, atoi (name.string));
}
  else
unread_char (ch);
@@ -1239,8 +1238,10 @@ function_reader::handle_any_trailing_information (rtx x)
  if (ch == 'A' && peek_char () != 'S')
{
  read_name ();
- MEM_ALIGN (x) = atoi (name.string);
+ set_mem_align (x, atoi (name.string));
}
+ else
+   unread_char (ch);
 
  /* Handle optional " AS" for MEM_ADDR_SPACE.  */
  ch = read_skip_spaces ();
@@ -1248,7 +1249,7 @@ function_reader::handle_any_trailing_information (rtx x)
{
  read_char ();
  read_name ();
- MEM_ADDR_SPACE (x) = atoi (name.string);
+ set_mem_addr_space (x, atoi (name.string));
}
  else
unread_char (ch);
@@ -2102,6 +2103,47 @@ test_loading_bb_index ()
   ASSERT_EQ (42, bb42->index);
 }
 
+/* Verify that function_reader::handle_any_trailing_information correctly
+   parses all the possible items emitted for a MEM.  */
+
+static void
+test_loading_mem ()
+{
+  rtl_dump_test t (SELFTEST_LOCATION, locate_file ("mem.rtl"));
+
+  ASSERT_STREQ ("test_mem", IDENTIFIER_POINTER (DECL_NAME (cfun->decl)));
+  ASSERT_TRUE (cfun);
+
+  /* Verify parsing of "[42 i+17 S8 A128 AS5]".  */
+  rtx_insn *insn_1 = get_insn_by_uid (1);
+  rtx set1 = single_set (insn_1);
+  rtx mem1 = SET_DEST (set1);
+  ASSERT_EQ (42, MEM_ALIAS_SET (mem1));
+  /* "+17".  */
+  ASSERT_TRUE (MEM_OFFSET_KNOWN_P (mem1));
+  

[Bug c++/64380] Missed optimization: smarter dead store elimination in dtors

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-08
 CC||law at redhat dot com
 Ever confirmed|0   |1

Re: [Patch, fortran, RFC] Add warning for missing location information

[Mikael Morin]

Le 08/12/2016 à 20:26, Thomas Koenig a écrit :

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.



Hello,

I have one comment.

This error;
+gfc_warning_internal (0, "No location in statement statement");

is not very helpful, especially without location.
Could you at least provide the statement type? There is 
gfc_ascii_statement you can use for that.


Thanks
Mikael

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Nathan Sidwell]

On 12/08/2016 01:05 PM, Jason Merrill wrote:

If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.


What about:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
};

?  That ICEs in the same way.

nathan

--
Nathan Sidwell

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #9 from Gerhard Steinmetz  
---

Frankly speaking, it's difficile. Smells more invalid than valid.
As a side note, I do not have any production code using a contruct 
similar to that in comment 0 or in recursive_interface_*.


Still affects some examples from testsuite/gfortran.dg :
  - data_value_1.f90
  - recursive_interface_1.f90
  - recursive_interface_2.f90


$ gfortran-7-20161204 -c recursive_interface_1.f90
$ gfortran-7-20161204 -fimplicit-none -c recursive_interface_1.f90
recursive_interface_1.f90:16:0:

   function baz() result(r3)

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064
0x7c7b83 gfc_typenode_for_spec(gfc_typespec*, bool)
../../gcc/fortran/trans-types.c:1064
0x7c5c03 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2167
0x7c670b gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3030
0x7c68bc gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3023
0x75130f build_function_decl
../../gcc/fortran/trans-decl.c:2157
0x75674b gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:2833
0x733137 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2149
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug rtl-optimization/54421] Extra movdqa when accessing quadwords in a 128-bit SSE register

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
It looks like we went through a series of improvements resulting in the current
compiler generating:

   movhlps %xmm0, %xmm1
movq%xmm0, %rdx
movq%xmm1, %rax
orq %rax, %rdx
sete%al
movzbl  %al, %eax
ret


ie, it operates solely on registers and thus avoids the unnecessary stack
loads/stores.

Given it was a progression over time, I'm not going to bisect each improvement.
 It's just not worth the effort.

Re: [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

[Bernd Edlinger]

Hi Wilco,

On 11/30/16 18:01, Bernd Edlinger wrote:
> I attached the completely untested follow-up patch now, but I would
> like to post that one again for review, after I applied my current
> patch, which is still waiting for final review (please feel pinged!).
>
>
> This is really exciting...
>
>


when testing the follow-up patch I discovered a single regression
in gcc.dg/fixed-point/convert-sat.c that was caused by a mis-compilation
of the libgcc function __gnu_satfractdasq.

I think it triggerd a latent bug in the carryin_compare patterns.

everything is as expected until reload.  First what is left over
of a split cmpdi_insn followed by a former cmpdi_unsigned, if the
branch is not taken.

(insn 109 10 110 2 (set (reg:CC 100 cc)
 (compare:CC (reg:SI 0 r0 [orig:124 _10 ] [124])
 (const_int 0 [0]))) 
"../../../gcc-trunk/libgcc/fixed-bit.c":785 196 {*arm_cmpsi_insn}
  (nil))
(insn 110 109 13 2 (parallel [
 (set (reg:CC 100 cc)
 (compare:CC (reg:SI 1 r1 [orig:125 _10+4 ] [125])
 (const_int -1 [0x])))
 (set (reg:SI 3 r3 [123])
 (minus:SI (plus:SI (reg:SI 1 r1 [orig:125 _10+4 ] [125])
 (const_int -1 [0x]))
 (ltu:SI (reg:CC_C 100 cc)
 (const_int 0 [0]
 ]) "../../../gcc-trunk/libgcc/fixed-bit.c":785 32 
{*subsi3_carryin_compare_const}
  (nil))
(jump_insn 13 110 31 2 (set (pc)
 (if_then_else (ge (reg:CC_NCV 100 cc)
 (const_int 0 [0]))
 (label_ref:SI 102)
 (pc))) "../../../gcc-trunk/libgcc/fixed-bit.c":785 204 
{arm_cond_branch}
  (int_list:REG_BR_PROB 6400 (nil))

(note 31 13 97 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note 97 31 114 3 NOTE_INSN_DELETED)
(insn 114 97 113 3 (set (reg:SI 2 r2 [orig:127+4 ] [127])
 (const_int -1 [0x])) 
"../../../gcc-trunk/libgcc/fixed-bit.c":831 630 {*arm_movsi_vfp}
  (expr_list:REG_EQUIV (const_int -1 [0x])
 (nil)))
(insn 113 114 107 3 (set (reg:SI 3 r3 [126])
 (const_int 2147483647 [0x7fff])) 
"../../../gcc-trunk/libgcc/fixed-bit.c":831 630 {*arm_movsi_vfp}
  (expr_list:REG_EQUIV (const_int 2147483647 [0x7fff])
 (nil)))
(insn 107 113 108 3 (set (reg:CC 100 cc)
 (compare:CC (reg:SI 1 r1 [orig:125 _10+4 ] [125])
 (reg:SI 2 r2 [orig:127+4 ] [127]))) 
"../../../gcc-trunk/libgcc/fixed-bit.c":831 196 {*arm_cmpsi_insn}
  (nil))


Note that the CC register is not really set as implied by insn 110,
because the C flag depends on the comparison of r1, 0x and the
carry flag from insn 109.  Therefore in the postreload pass the
insn 107 appears to be unnecessary, as if should compute
exactly the same CC flag, as insn 110, i.e. not dependent on
previous CC flag.  I think all carryin_compare patterns are
wrong because they do not describe the true value of the CC reg.

I think the CC reg is actually dependent on left, right and CC-in
value, as in the new version of the patch it must be a computation
in DI mode without overflow, as in my new version of the patch.

I attached an update of the followup patch which is not yet adjusted
on your pending negdi patch.  Reg-testing is no yet done, but the
mis-compilation on libgcc is fixed at least.

What do you think?


Thanks
Bernd.
2016-12-08  Bernd Edlinger  

	PR target/77308
	* config/arm/arm.md (subdi3_compare1, subsi3_carryin_compare,
	subsi3_carryin_compare_const, negdi2_compare): Fix the CC reg dataflow.
	(*arm_negdi2, *arm_cmpdi_unsigned): Split early except for
TARGET_NEON and TARGET_IWMMXT.
	(*arm_cmpdi_insn): Split early except for
	TARGET_NEON and TARGET_IWMMXT.  Fix the CC reg dataflow.
	* config/arm/thumb2.md (*thumb2_negdi2): Split early except for
	TARGET_NEON and TARGET_IWMMXT.

testsuite:
2016-12-08  Bernd Edlinger  

	PR target/77308
	* gcc.target/arm/pr77308-2.c: New test.

--- gcc/config/arm/arm.md.orig	2016-12-08 16:01:43.290595127 +0100
+++ gcc/config/arm/arm.md	2016-12-08 19:04:22.251065848 +0100
@@ -1086,8 +1086,8 @@
 })
 
 (define_insn_and_split "subdi3_compare1"
-  [(set (reg:CC CC_REGNUM)
-	(compare:CC
+  [(set (reg:CC_NCV CC_REGNUM)
+	(compare:CC_NCV
 	  (match_operand:DI 1 "register_operand" "r")
 	  (match_operand:DI 2 "register_operand" "r")))
(set (match_operand:DI 0 "register_operand" "=")
@@ -1098,10 +1098,15 @@
   [(parallel [(set (reg:CC CC_REGNUM)
 		   (compare:CC (match_dup 1) (match_dup 2)))
 	  (set (match_dup 0) (minus:SI (match_dup 1) (match_dup 2)))])
-   (parallel [(set (reg:CC CC_REGNUM)
-		   (compare:CC (match_dup 4) (match_dup 5)))
-	 (set (match_dup 3) (minus:SI (minus:SI (match_dup 4) (match_dup 5))
-			   (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0])]
+   (parallel [(set (reg:CC_C CC_REGNUM)
+		   (compare:CC_C
+		 (zero_extend:DI (match_dup 4))
+		

[Bug middle-end/35302] Missing partial dead store elimination

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
Richi fixed this back in 2009:

2009-11-23  Richard Guenther  

* tree-dfa.c (get_ref_base_and_extent): Adjust maximum access
size for DECL bases.

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from Nathan Sidwell  ---
Fixed on 5, 6 & HEAD

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

--- Comment #14 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec  8 19:27:32 2016
New Revision: 243457

URL: https://gcc.gnu.org/viewcvs?rev=243457=gcc=rev
Log:
PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

PR c++/78551
* g++.dg/cpp1y/pr78551.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/pr78551.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

Re: [Patch, fortran, RFC] Add warning for missing location information

[Thomas Koenig]

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked the
discussion on whether it is ok to add your part of the patch. Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.

Regards

Thomas

[Bug target/78733] [7 Regression] bootstrap broken on aarch64-linux-gnu

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from wilco at gcc dot gnu.org ---
Fixed in r243456.

Re: [PATCH] Fix c++/78621 generic lambda mangling

[Nathan Sidwell]

On 12/08/2016 02:08 PM, Jason Merrill wrote:


Right.  Which is because they act as normal template parameters rather
than like the auto type-specifier does in, say, a variable declaration.
But indeed this produces bad mangling, and using Da in the mangling of a
generic lambda seems reasonable.  You've probably seen my mail to the
ABI list about it.  Are you still on that list?


Yes, thanks.


This use of tsubst can meet {TYPE,EXPR}_PARAMETER_PACKs, so I had to
extend tsubst to process those objects.


Hmm, we have deliberately avoided this in the past, since pack
expansions mean different things in different contexts.  Can you use
tsubst_arg_types instead?


... will investigate.


Also, the name "make_auto_for_mangle" doesn't really indicate that it's
doing a substitution of the function parameter types.


yeah, probably not the best name anymore. (it started out as just 
creating the single auto type, but then I moved all the other stuff into 
it.)


nathan
--
Nathan Sidwell

Re: [PATCH][AArch64] Fix PR78733

[Wilco Dijkstra]

James Greenhalgh wrote:
>
> I presume you also made a testsuite run?
> 
> You should be able to do something like:
> 
>  make check RUNTESTFLAGS="--target_board=unix/-mpc-relative-literal-loads"

Yes the results of that looked OK, the 250 new failures are gone. I've 
committed the fix.

Wilco

[Bug target/78733] [7 Regression] bootstrap broken on aarch64-linux-gnu

[wilco at gcc dot gnu.org]

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

--- Comment #10 from wilco at gcc dot gnu.org ---
Author: wilco
Date: Thu Dec  8 19:18:33 2016
New Revision: 243456

URL: https://gcc.gnu.org/viewcvs?rev=243456=gcc=rev
Log:
This patch fixes an issue in aarch64_classify_address.  TImode and TFmode
can either use a 64-bit LDP/STP or 128-bit LDR/STR.  The addressing mode
must be carefully modelled as the intersection of both.  This is done for
the immediate offsets, however load_store_pair_p must be set as well to
avoid LDP with a PC-relative address if aarch64_pcrelative_literal_loads
is true.

gcc/
PR target/78733
* config/aarch64/aarch64.c (aarch64_classify_address):
Set load_store_pair_p for TImode and TFmode.

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

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[PATCH, i386]: Use GENERAL_REGNO_P some more

[Uros Bizjak]

No functional changes.

2016-12-08  Uros Bizjak  

* gcc.target/i386/i386.h (HARD_REGNO_NREGS): Use GENERAL_REGNO_P.
(HARD_REGNO_NREGS_HAS_PADDING): Ditto.  Simplify macro.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 83ffd4e..8bc31f9 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1080,22 +1080,19 @@ extern const char *host_detect_local_cpu (int argc, 
const char **argv);
applied to them.  */
 
 #define HARD_REGNO_NREGS(REGNO, MODE)  \
-  (STACK_REGNO_P (REGNO) || SSE_REGNO_P (REGNO) || MMX_REGNO_P (REGNO) \
-   || MASK_REGNO_P (REGNO) || BND_REGNO_P (REGNO)  \
-   ? (COMPLEX_MODE_P (MODE) ? 2 :  \
-  (((MODE == V64SFmode) || (MODE == V64SImode)) ? 4 : 1))  \
-   : ((MODE) == XFmode \
+  (GENERAL_REGNO_P (REGNO) \
+   ? ((MODE) == XFmode \
   ? (TARGET_64BIT ? 2 : 3) \
   : ((MODE) == XCmode  \
 ? (TARGET_64BIT ? 4 : 6)   \
-: CEIL (GET_MODE_SIZE (MODE), UNITS_PER_WORD
+: CEIL (GET_MODE_SIZE (MODE), UNITS_PER_WORD)))\
+   : (COMPLEX_MODE_P (MODE) ? 2 :  \
+  (((MODE == V64SFmode) || (MODE == V64SImode)) ? 4 : 1)))
 
 #define HARD_REGNO_NREGS_HAS_PADDING(REGNO, MODE)  \
-  ((TARGET_128BIT_LONG_DOUBLE && !TARGET_64BIT)
\
-   ? (STACK_REGNO_P (REGNO) || SSE_REGNO_P (REGNO) || MMX_REGNO_P (REGNO) \
-  ? 0  \
-  : ((MODE) == XFmode || (MODE) == XCmode))
\
-   : 0)
+  (TARGET_128BIT_LONG_DOUBLE && !TARGET_64BIT  \
+   && GENERAL_REGNO_P (REGNO)  \
+   && ((MODE) == XFmode || (MODE) == XCmode))
 
 #define HARD_REGNO_NREGS_WITH_PADDING(REGNO, MODE) ((MODE) == XFmode ? 4 : 8)
 

[Bug other/78252] C++ demangler crashes with infinite recursion with lambda (auto)

[curlypaul924 at gmail dot com]

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

Paul Brannan  changed:

   What|Removed |Added

 CC||curlypaul924 at gmail dot com

--- Comment #4 from Paul Brannan  ---
I can confirm Nathan's patch fixes the crash I was seeing with
_ZSt7forwardIRZN3Foo3BarEvEUlRT_iE_EOS1_RNSt16remove_referenceIS1_E4typeE

[Bug rtl-optimization/78738] [7 Regression] ICE in extract_insn, at recog.c:2311

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Following patch fixes the failure:

--cut here--
Index: toplev.c
===
--- toplev.c(revision 243444)
+++ toplev.c(working copy)
@@ -1691,6 +1691,8 @@ init_excess_precision (void)
 {
   gcc_assert (flag_excess_precision_cmdline != EXCESS_PRECISION_DEFAULT);
   flag_excess_precision = flag_excess_precision_cmdline;
+  if (flag_unsafe_math_optimizations)
+flag_excess_precision = EXCESS_PRECISION_FAST;
 }

 /* Initialize things that are both lang-dependent and target-dependent.
--cut here--

Re: [PATCH] Fix c++/78621 generic lambda mangling

[Jason Merrill]

On 12/07/2016 01:30 PM, Nathan Sidwell wrote:

This patch fixes the generic lambda mangling bug that caused the
demangler to infinitely recurse (78252).  The generic's auto parms fail
the is_auto check because that's testing for the 'auto' identifier,
whereas the parms are distinct template type parms named 'auto:$N'.


Right.  Which is because they act as normal template parameters rather 
than like the auto type-specifier does in, say, a variable declaration. 
But indeed this produces bad mangling, and using Da in the mangling of a 
generic lambda seems reasonable.  You've probably seen my mail to the 
ABI list about it.  Are you still on that list?



Amending is_auto to do a textual compare of the identifier breaks
things, and is insufficient anyway.  The mangler's squangling must (a)
squangle subsequent auto uses as expected and (b) NOT squangle
subsequent template type parm references to refer the the lambda's autos.


Wow, I haven't seen the term "squangling" in more than a decade.  Did we 
ever use that in reference to the new ABI?



This use of tsubst can meet {TYPE,EXPR}_PARAMETER_PACKs, so I had to
extend tsubst to process those objects.


Hmm, we have deliberately avoided this in the past, since pack 
expansions mean different things in different contexts.  Can you use 
tsubst_arg_types instead?


Also, the name "make_auto_for_mangle" doesn't really indicate that it's 
doing a substitution of the function parameter types.


Jason

[Bug rtl-optimization/78738] [7 Regression] ICE in extract_insn, at recog.c:2311

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-08
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Looks like the effect of excess_precision changes.

In i386.h, we define:

/* Whether to allow x87 floating-point arithmetic on MODE (one of
   SFmode, DFmode and XFmode) in the current excess precision
   configuration.  */
#define X87_ENABLE_ARITH(MODE) \
  (flag_excess_precision == EXCESS_PRECISION_FAST || (MODE) == XFmode)

/* Likewise, whether to allow direct conversions from integer mode
   IMODE (HImode, SImode or DImode) to MODE.  */
#define X87_ENABLE_FLOAT(MODE, IMODE)   \
  (flag_excess_precision == EXCESS_PRECISION_FAST   \
   || (MODE) == XFmode  \
   || ((MODE) == DFmode && (IMODE) == SImode)   \
   || (IMODE) == HImode)

and relevant pattern in i386.md:

(define_insn "*fop__comm"
  [(set (match_operand:MODEF 0 "register_operand" "=f,x,v")
(match_operator:MODEF 3 "binary_fp_operator"
  [(match_operand:MODEF 1 "nonimmediate_operand" "%0,0,v")
   (match_operand:MODEF 2 "nonimmediate_operand" "fm,xm,vm")]))]
  "((SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
|| (TARGET_80387 && X87_ENABLE_ARITH (mode)))
   && COMMUTATIVE_ARITH_P (operands[3])
   && !(MEM_P (operands[1]) && MEM_P (operands[2]))"

The testcase generates the insn from ix86_emit_i387_round, where
flag_excess_precision is set to EXCESS_PRECISION_STANDARD.

IMO, we want to set flag_excess_precision to EXCESS_PRECISION_FAST for
-ffast-math.

Confirmed, CC author of the patch.

[Bug c/78666] conflicting attribute alloc_size accepted

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Thu, 8 Dec 2016, msebor at gcc dot gnu.org wrote:

> But what is specifying multiple declarations of the same function with
> different sets of attributes supposed to mean?  Is it supposed to apply the
> union of all of them?  How should conflicts be resolved?  Should the rules be
> expected to be consistent across attributes with different names?

It should be the result of merging them (taking the union), with conflicts 
diagnosed.  What conflicts depends on the attribute in question.  We have 
e.g. the comp_type_attributes hook for targets to use to detect conflicts 
(which x86 uses for regparm and other calling convention attributes).

Note that glibc relies on being able to apply both attributes (hidden 
visibility, at least) and asm renaming to built-in functions after their 
built-in and explicit declarations (see include/string.h).

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

--- Comment #13 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec  8 18:37:03 2016
New Revision: 243451

URL: https://gcc.gnu.org/viewcvs?rev=243451=gcc=rev
Log:
PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

PR c++/78551
* g++.dg/cpp1y/pr78551.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/pr78551.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

--- Comment #12 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec  8 18:34:04 2016
New Revision: 243448

URL: https://gcc.gnu.org/viewcvs?rev=243448=gcc=rev
Log:
PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

PR c++/78551
* g++.dg/cpp1y/pr78551.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr78551.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69398] [OOP] ICE on class with duplicate dimension attribute specified

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4) 
> The problem is that the class container is built too early (and thus we
> build a container for a scalar class variable).

To fix this, we have the following options:
1) "Rebuild" the class container when the relevant attributes change (such as
DIMENSION). That is probably the simplest solution, but a bit inefficient,
since we build containers that we don't need.
2) Or: Defer the container building to resolution stage, at least for scalar
class variables, since we don't know if a dimension declaration follows
somewhere after the class declaration. This might be a bit more tricky.
3) Defer the container building to resolution stage for all class variables, no
matter if it would be possible earlier. This might be the cleanest solution,
but might require major reworking of CLASS-specific code.

New Spanish PO file for 'gcc' (version 6.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/es.po

(This file, 'gcc-6.2.0.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Bug fortran/78741] New: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1534

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78741
   Summary: ICE in gfc_get_symbol_decl, at
fortran/trans-decl.c:1534
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code (symbol "g" name clash), down to at least 4.8.


$ cat z1.f90
subroutine s(n, x)
   integer :: n
   character(n) :: x
   character, pointer :: z(:)
   x = 'a'
   return
entry g(n, x)
   x = 'b'
contains
   subroutine g
  z(1) = x(1:1)
   end
end


$ gfortran-7-20161204 -c z1.f90
z1.f90:11:0:

   z(1) = x(1:1)

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1534
0x75b49a gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1533
0x7731af gfc_conv_variable
../../gcc/fortran/trans-expr.c:2494
0x76ee42 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7771
0x7789e2 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:9821
0x72e687 trans_code
../../gcc/fortran/trans.c:1790
0x75f708 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6271
0x75f557 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5251
0x75f557 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6200
0x6e73d0 translate_all_program_units
../../gcc/fortran/parse.c:6038
0x6e73d0 gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0

--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #15)
> Confirmed, this ICE is now completely gone on my environment.

Great! Closing.

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Jason Merrill]

If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.

On Wed, Dec 7, 2016 at 3:26 PM, Marek Polacek  wrote:
> We were crashing in finish_expr_stmt here:
>  676   /* If we ran into a problem, make sure we complained.  */
>  677   gcc_assert (expr != error_mark_node || seen_error ());
> Well, we ran into a problem, but never raised an error.  The problem was that
> we couldn't determine the max index of the array when default-initizalizing 
> the
> members (at the beginning of cp_parser_ctor_initializer_opt).  Jason's
> preference seems to be to disable initialization of a flexible array member in
> a constructor and that is what this patch attempts to do.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2016-12-07  Marek Polacek  
>
> PR c++/72775
> * init.c (perform_member_init): Diagnose initialization of a flexible
> array member in a constructor.
>
> * g++.dg/ext/flexary20.C: New.
>
> diff --git gcc/cp/init.c gcc/cp/init.c
> index b4b6cdb..01009c9 100644
> --- gcc/cp/init.c
> +++ gcc/cp/init.c
> @@ -800,6 +800,10 @@ perform_member_init (tree member, tree init)
>in that case.  */
> init = build_x_compound_expr_from_list (init, ELK_MEM_INIT,
> tf_warning_or_error);
> +  else if (TREE_CODE (type) == ARRAY_TYPE
> +  && TYPE_DOMAIN (type) == NULL_TREE)
> +   error_at (DECL_SOURCE_LOCATION (member),
> + "initialization of a flexible array member in a 
> constructor");
>
>if (init)
> finish_expr_stmt (cp_build_modify_expr (input_location, decl,
> diff --git gcc/testsuite/g++.dg/ext/flexary20.C 
> gcc/testsuite/g++.dg/ext/flexary20.C
> index e69de29..ff97b06 100644
> --- gcc/testsuite/g++.dg/ext/flexary20.C
> +++ gcc/testsuite/g++.dg/ext/flexary20.C
> @@ -0,0 +1,49 @@
> +// PR c++/72775
> +// { dg-do compile { target c++11 } }
> +// { dg-options -Wno-pedantic }
> +
> +struct S {
> +  int i;
> +  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
> in a constructor" }
> +  S () {}
> +};
> +
> +struct T {
> +  int i;
> +  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
> in a constructor" }
> +};
> +
> +struct U {
> +  int i;
> +  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
> in a constructor" }
> +  U ();
> +};
> +
> +U::U() {}
> +
> +int
> +main ()
> +{
> +  struct T t;
> +}
> +
> +struct V {
> +  int i;
> +  struct W {
> +int j;
> +char a[] = "foo"; // { dg-error "initialization of a flexible array 
> member in a constructor" }
> +  } w;
> +  V () {}
> +};
> +
> +template 
> +struct X {
> +  int i;
> +  T a[] = "foo"; // { dg-error "initialization of a flexible array member in 
> a constructor" }
> +};
> +
> +void
> +fn ()
> +{
> +  struct X x;
> +}
>
> Marek

[Bug testsuite/78740] New: test case powerpc/pr78691-ppc.c fails starting with its introduction in r243335

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78740
   Summary: test case powerpc/pr78691-ppc.c fails starting with
its introduction in r243335
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This fails on LE and probably just needs a test case change to restrict where
it runs.

spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/pr78691-ppc.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Os -m32 -S -o
pr78691-ppc.s
cc1: error: -m32 not supported in this configuration
compiler exited with status 1
output is:
cc1: error: -m32 not supported in this configuration

FAIL: gcc.target/powerpc/pr78691-ppc.c (test for excess errors)
Excess errors:
cc1: error: -m32 not supported in this configuration

Re: [PATCH] fix c++/78551 ICE in constexpr

[Jason Merrill]

On Wed, Dec 7, 2016 at 3:31 PM, Nathan Sidwell  wrote:
> This patch fixes 78551.  The union was a red herring.  The underlying
> problem is that we first initialize a char array with a string constant, and
> then zap a random element of that array.  That zapping expects to see a
> CONSTRUCTOR, not a STRING_CST.  Fixed by expanding the STRING_CST into a
> CONSTRUCTOR for each element, when we encounter this situation.
>
> Patch tested on HEAD and gcc-6 branch.

OK.

> Is gcc-5 still live (testcase is marked as a  5/6/7 regression)?

It is; you can check gcc.gnu.org to see current release status.

Incidentally, would you mind naming your attachments .diff rather than
.patch?  Gmail mishandles the latter.

Jason

Re: parallel_algorithm_assert2.cc

[Jonathan Wakely]

On 8 December 2016 at 17:09, David Edelsohn wrote:
> Jonathan,
>
> I'm seeing a new failure on AIX.
>
> FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
> (test for excess errors)
> Excess errors:
> xg++: error: libgomp.spec: No such file or directory
>
> Does the testsuite driver assume that libgomp.spec already is
> installed in the correct install location?

Ah, I think the DG directives are in the wrong order.

Does this help?

--- 
a/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
+++ 
b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
@@ -1,6 +1,6 @@
-// { dg-require-parallel-mode "" }
 // { dg-options "-fopenmp -D_GLIBCXX_PARALLEL" { target *-*-* } }
 // { dg-do run }
+// { dg-require-parallel-mode "" }

 // Copyright (C) 2016 Free Software Foundation, Inc.
 //

[Bug fortran/78739] New: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1477

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78739
   Summary: ICE in gfc_get_symbol_decl, at
fortran/trans-decl.c:1477
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

A tiny snippet of _invalid_ code, ICEs down to at least 4.8.
Backtrace similar to that of pr68846 comment 4 and pr70864 comment 3.


$ cat z1.f90
function f(n)
   f() = n
end


$ gfortran-7-20161204 -c z1.f90
z1.f90:1:0:

 function f(n)

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1477
0x75a352 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1477
0x75e5b7 generate_local_decl
../../gcc/fortran/trans-decl.c:5327
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x75f412 generate_local_vars
../../gcc/fortran/trans-decl.c:5527
0x75f412 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6206
0x6e73d0 translate_all_program_units
../../gcc/fortran/parse.c:6038
0x6e73d0 gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Pádraig Brady from comment #15)
> So it would be good to set the "Target Milestone" to 5.5

But it was also fixed for 4.9.4, so that's what the target milestone says.

You can't reliably use that query for "bugs fixed in 5.5" because it doesn't
find bugs fixed in (for example) both 4.9.4 and 5.5

And if we set the milestone to 5.5 you would just have the same problem trying
to find bugs fixed in 4.9.4

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[P at draigBrady dot com]

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

--- Comment #15 from Pádraig Brady  ---
Actually it is backported to 5.

So it would be good to set the "Target Milestone" to 5.5
so this is obvious from this bug and from the list of bugs fixed in 5.5
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED_id=166767=FIXED_milestone=5.5

thanks!

Re: [Patch, fortran] Ping! - PR77903 - [F08] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[Paul Richard Thomas]

On 5 December 2016 at 21:01, Paul Richard Thomas
 wrote:
> Dear All,
>
> It took me an excessively long time to realise that processing the
> typespec for an explicitly typed module procedure was wiping out the
> interface symbol and so preventing the comparison of characteristics
> between the interface and the separate module procedure. Transferring
> the module interface symbol to the tlink field, rather than the
> interface, fixed the problem without doing anything else.
>
> Note the comment in the gfortran.h about the use of the tlink field.
> It has been a while since this was used for change management. If it
> is preferred, I could introduce a union between tlink and some other
> suitable name; eg mod_proc_interface.
>
> Bootstraps and regtests on FC21/x86_64.
>
> OK for trunk and, after a decent interval, 6-branch?
>
> Paul
>
> 2016-12-06  Paul Thomas  
>
> PR fortran/77903
> * decl.c (get_proc_name): Use the symbol tlink field instead of
> the typespec interface field.
> (gfc_match_function_decl, gfc_match_submod_proc): Ditto.
> * gfortran.h : Since the symbol tlink field is no longer used
> by the frontend for change management, change the comment to
> reflect its current uses.
> * parse.c (get_modproc_result): Same as decl.c changes.
> * resolve.c (resolve_fl_procedure): Ditto.
>
> 2016-12-06  Paul Thomas  
>
> PR fortran/77903
> * gfortran.dg/submodule_20.f08: New test.



-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama