Re: [C++ PATCH] Fix ICE when dumping VEC_COND_EXPR (PR c++/80363)

[Richard Biener]

On Mon, Apr 10, 2017 at 10:34 PM, Jakub Jelinek  wrote:
> Hi!
>
> The following testcase emits vec_cond_expr not supported by dump_expr
> inside of error message.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?

Ok.

Richard.

> 2017-04-10  Jakub Jelinek  
>
> PR c++/80363
> * error.c (dump_expr): Handle VEC_COND_EXPR like COND_EXPR.
>
> * g++.dg/ext/pr80363.C: New test.
>
> --- gcc/cp/error.c.jj   2017-02-09 23:01:49.0 +0100
> +++ gcc/cp/error.c  2017-04-08 09:30:54.417681285 +0200
> @@ -2080,6 +2080,7 @@ dump_expr (cxx_pretty_printer *pp, tree
>break;
>
>  case COND_EXPR:
> +case VEC_COND_EXPR:
>pp_cxx_left_paren (pp);
>dump_expr (pp, TREE_OPERAND (t, 0), flags | TFF_EXPR_IN_PARENS);
>pp_string (pp, " ? ");
> --- gcc/testsuite/g++.dg/ext/pr80363.C.jj   2017-04-08 09:33:59.134213656 
> +0200
> +++ gcc/testsuite/g++.dg/ext/pr80363.C  2017-04-08 09:33:20.0 +0200
> @@ -0,0 +1,12 @@
> +// PR c++/80363
> +// { dg-do compile }
> +
> +typedef int V __attribute__((vector_size (16)));
> +
> +int
> +foo (V *a, V *b)
> +{
> +  if (*a < *b) // { dg-error "could not convert\[^#]*from" }
> +return 1;
> +  return 0;
> +}
>
> Jakub

Re: [PATCH] Partially revert undesirable widest literal type changes from 1999 (PR middle-end/79788, PR middle-end/80375)

[Richard Biener]

On Mon, Apr 10, 2017 at 10:42 PM, Jakub Jelinek  wrote:
> Hi!
>
> The http://gcc.gnu.org/ml/gcc-patches/1999-07/msg00031.html change
> appears to be IMHO highly undesirable loophole around the lack of
> TImode support on 32-bit targets.  Those targets return
> false from targetm.scalar_mode_supported_p (TImode) for a reason,
> while for some arithmetics operation perhaps the middle-end manages
> to emit something that doesn't ICE, as the following testcases shows
> there are various other cases which just ICE.
> While the 32-bit targets don't support __int128/__int128_t/__uint128_t,
> because of the above change one can use instead
> __typeof (1234567891234567891234567891234567812) or similar constructs
> to get variables of that type and similarly expressions can still have
> the 128-bit type, but as can be seen we don't really support those.
>
> Thus, this patch reverts the effect of the above patch for 32-bit targets,
> basically the type of the oversized literals is now __int128_t/__uint128_t
> on 64-bit targets as before, but only long long/unsigned long long on
> 32-bit targets.  While this is an ABI change, it affects only code on which
> we emit pedwarn, so I'd think it is unlikely to be used in the wild.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok if Joseph doesn't have a better idea.

It may be still worth noting that to the caveats section of changes.html.

Richard.

> 2017-04-10  Jakub Jelinek  
>
> PR middle-end/79788
> PR middle-end/80375
> * c-common.c (c_common_type_for_mode): Don't handle
> widest_*_literal_type_node here.
> c_common_signed_or_unsigned_type): Likewise.
> (c_common_nodes_and_builtins): Set widest_*_literal_type_node
> to *intTI_type_node or *intDI_type_node depending on whether
> TImode is supported by the target or not.
>
> * gcc.dg/pr79788-1.c: New test.
> * gcc.dg/pr79788-2.c: New test.
>
> --- gcc/c-family/c-common.c.jj  2017-03-31 08:39:08.0 +0200
> +++ gcc/c-family/c-common.c 2017-04-10 13:29:10.691179060 +0200
> @@ -2179,10 +2179,6 @@ c_common_type_for_mode (machine_mode mod
>return (unsignedp ? int_n_trees[i].unsigned_type
>   : int_n_trees[i].signed_type);
>
> -  if (mode == TYPE_MODE (widest_integer_literal_type_node))
> -return unsignedp ? widest_unsigned_literal_type_node
> -: widest_integer_literal_type_node;
> -
>if (mode == QImode)
>  return unsignedp ? unsigned_intQI_type_node : intQI_type_node;
>
> @@ -2412,8 +2408,6 @@ c_common_signed_or_unsigned_type (int un
>return (unsignedp ? int_n_trees[i].unsigned_type
>   : int_n_trees[i].signed_type);
>
> -  if (type1 == widest_integer_literal_type_node || type1 == 
> widest_unsigned_literal_type_node)
> -return unsignedp ? widest_unsigned_literal_type_node : 
> widest_integer_literal_type_node;
>  #if HOST_BITS_PER_WIDE_INT >= 64
>if (type1 == intTI_type_node || type1 == unsigned_intTI_type_node)
>  return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
> @@ -2534,10 +2528,6 @@ c_common_signed_or_unsigned_type (int un
>return (unsignedp ? int_n_trees[i].unsigned_type
>   : int_n_trees[i].signed_type);
>
> -  if (TYPE_OK (widest_integer_literal_type_node))
> -return (unsignedp ? widest_unsigned_literal_type_node
> -   : widest_integer_literal_type_node);
> -
>  #if HOST_BITS_PER_WIDE_INT >= 64
>if (TYPE_OK (intTI_type_node))
>  return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
> @@ -4164,17 +4154,16 @@ c_common_nodes_and_builtins (void)
>  #endif
>
>/* Create the widest literal types.  */
> -  widest_integer_literal_type_node
> -= make_signed_type (HOST_BITS_PER_WIDE_INT * 2);
> -  lang_hooks.decls.pushdecl (build_decl (UNKNOWN_LOCATION,
> -TYPE_DECL, NULL_TREE,
> -widest_integer_literal_type_node));
> -
> -  widest_unsigned_literal_type_node
> -= make_unsigned_type (HOST_BITS_PER_WIDE_INT * 2);
> -  lang_hooks.decls.pushdecl (build_decl (UNKNOWN_LOCATION,
> -TYPE_DECL, NULL_TREE,
> -widest_unsigned_literal_type_node));
> +  if (targetm.scalar_mode_supported_p (TImode))
> +{
> +  widest_integer_literal_type_node = intTI_type_node;
> +  widest_unsigned_literal_type_node = unsigned_intTI_type_node;
> +}
> +  else
> +{
> +  widest_integer_literal_type_node = intDI_type_node;
> +  widest_unsigned_literal_type_node = unsigned_intDI_type_node;
> +}
>
>signed_size_type_node = c_common_signed_type (size_type_node);
>
> --- gcc/testsuite/gcc.dg/pr79788-1.c.jj 2017-04-10 13:58:33.399248477 +0200
> +++ gcc/testsuite/gcc.dg/pr79788-1.c2017-04-10 13:59:17.980699210 +0200
> @@ -0,0 +1,11 @@
> +/* PR middle-end/79788 */
> +/* { dg-do compile } */
> +/* { dg

Re: One more path to fix PR70478

[Christophe Lyon]

Hi Vladimir,

On 10 April 2017 at 17:05, Vladimir Makarov  wrote:
>   This is the second try to fix
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
>
>   The first try patch triggered a latent bug and broke one Fortran testcase
> on x86-64.
>
>   The patch was successfully bootstrapped on x86-64 and tested on x86-64,
> ppc64, and aarch64.
>
>   Committed as rev. 246808.
>
>

This patch causes regression on arm*hf configurations:
  Executed from: gcc.target/arm/arm.exp
gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times ldrh\\tr[0-9]+ 2
gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times strh\\tr[0-9]+ 2
gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vld1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vmov\\.f16\\tr[0-9]+, s[0-9]+ 4
gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vmov\\.f16\\ts[0-9]+, r[0-9]+ 4
gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vst1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2

See 
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/246809/report-build-info.html

Is it just a matter of adjusting the testcases? (note that there is no
regression when forcing either:
-march=armv5t
-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard
in the runtestflags.

I would have to re--run the build/test manually to get the generated
code, let me know if it's needed.

Thanks,

Christophe

Re: [P1] [PATCH] [PR tree-optimization/80374] Do not try to convert integer_zero_node to undesirable types

[Richard Biener]

On Mon, Apr 10, 2017 at 9:20 PM, Jeff Law  wrote:
>
> fold_convert can fail for certain types.  It can fail either by returning a
> error_mark_node or triggering a gcc_assert depending on the exact situation.
>
> Both are problematical.  This patch checks that we can convert
> integer_zero_node to the proper type before calling fold_convert.
>
> Bootstrapped and regression tested on x86_64.  Installing on the trunk.

I am testing the proper fix below (NULLPTR_TYPE is somewhat special...)

Richard.

Index: gcc/tree-ssa-dom.c
===
--- gcc/tree-ssa-dom.c  (revision 246832)
+++ gcc/tree-ssa-dom.c  (working copy)
@@ -701,13 +701,12 @@ derive_equivalences_from_bit_ior (tree n
  const_and_copies *const_and_copies,
  int recursion_limit)
 {
-  if (recursion_limit == 0
-  || !fold_convertible_p (TREE_TYPE (name), integer_zero_node))
+  if (recursion_limit == 0)
 return;

   if (TREE_CODE (name) == SSA_NAME)
 {
-  tree value = fold_convert (TREE_TYPE (name), integer_zero_node);
+  tree value = build_zero_cst (TREE_TYPE (name));

   /* This records the equivalence for the toplevel object.  */
   record_equality (name, value, const_and_copies);


> Jeff
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 6edad21..7db5359 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,10 @@
> +2017-04-10  Jeff Law  
> +
> +   PR tree-optimization/80374
> +   * tree-ssa-dom.c (derive_equivalences_from_bit_ior): Do not try to
> +   record anything if we can not convert integer_zero_node to the
> +   desired type.
> +
>  2017-04-10  Bin Cheng  
>
> PR tree-optimization/80153
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index b87d0ee..6ed3c99 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2017-04-10  Jeff Law  
> +
> +   PR tree-optimization/80374
> +   * g++.dg/pr80374.c: New test.
> +
>  2017-04-10  Daniel Santos 
>
> PR testsuite/79867
> diff --git a/gcc/testsuite/g++.dg/pr80374.C b/gcc/testsuite/g++.dg/pr80374.C
> new file mode 100644
> index 000..b02b656
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pr80374.C
> @@ -0,0 +1,19 @@
> +void a (const char *, const char *, int, const char *)
> +  __attribute__ ((__noreturn__));
> +template 
> +void
> +c () try
> +  {
> +throw;
> +  }
> +catch (b d)
> +  {
> +if (d)
> +  a ("", "", 2, __PRETTY_FUNCTION__);
> +  }
> +main ()
> +{
> +  using e = decltype (nullptr);
> +  c ();
> +}
> +
> diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
> index d2263bb..d9e5942 100644
> --- a/gcc/tree-ssa-dom.c
> +++ b/gcc/tree-ssa-dom.c
> @@ -701,7 +701,8 @@ derive_equivalences_from_bit_ior (tree name,
>   const_and_copies *const_and_copies,
>   int recursion_limit)
>  {
> -  if (recursion_limit == 0)
> +  if (recursion_limit == 0
> +  || !fold_convertible_p (TREE_TYPE (name), integer_zero_node))
>  return;
>
>if (TREE_CODE (name) == SSA_NAME)
>

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Richard Biener]

On Mon, 10 Apr 2017, Pedro Alves wrote:

> On 04/10/2017 01:50 PM, Richard Biener wrote:
> 
> > +void *operator new(__SIZE_TYPE__, void *p2) { return p2; }
> > +struct B { B(int i_) : i(i_) {} int i; };
> > +struct X
> > +{
> > +  unsigned char buf[sizeof (B)];
> > +};
> 
> Pedantically, shouldn't there be something here to enforce
> X's alignment to be at least the same as B's ?
> 
> > +
> > +int __attribute__((noinline)) foo()
> > +{
> > +  X x, y;
> > +  new (&x) B (0);

Right.  I'll do

  X x alignas(B), y alignas(B);

Meanwhile need to debug a LTO bootstrap failure caused by the patch.

Richard.

Re: [PATCH] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

[Andreas Krebbel]

On 04/10/2017 11:37 PM, Ulrich Weigand wrote:
> Dominik Vogt wrote:
> 
>> So, we could add a special case for const0_rtx that generates the
>> LT pattern and does not rely on Combine, and get rid of the
>> peephole.  I'm not sure this is worthwhile thoug, because the
>> peephole has other beneficial effects (as discussed), and until
>> we've solved the problems preventing Combine from merging L+LTR in
>> some cases, this is the best we have.  What do you think?
> 
> If we removed the peephole (for now), the patch now only touches
> parts of the backend used to emit atomic instructions, so code
> generation for any code that doesn't use those is guaranteed to
> be unchanged.  Given that we're quite late in the cycle, this
> might be a good idea at this point ...
> 
> But I don't see anything actually incorrect in the peephole, and
> it might indeed be a good thing in general -- just maybe more
> appropriate for the next stage1. 
> 
> Andreas, do you have an opinion on this?

Yes, the change is unrelated to the rest of the patch and therefore should go 
into a separate patch.
But I'm fine with applying both right now.
The peephole surprisingly often helped code generation.  There appear to be 
plenty of cases where
the L+LTR combination could not be handled otherwise. Dominik reviewed the 
speccpu diffs and there
were only improvements.

-Andreas-

Re: [PATCH] avoid using types wider than int for width and precision (PR 80364)

[Jakub Jelinek]

On Mon, Apr 10, 2017 at 04:16:42PM -0600, Martin Sebor wrote:
> gcc/ChangeLog:
> 
>   PR middle-end/80364
>   * gimple-ssa-sprintf.c (get_int_range): Remove second argument and
>   always use the int type.
>   (directive::set_width, directive::set_precision, format_character):
>   Adjust.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR middle-end/80364
>   * gcc.dg/tree-ssa/builtin-sprintf-warn-16.c: New test.

> @@ -961,10 +962,16 @@ get_int_range (tree arg, tree type, HOST_WIDE_INT 
> *pmin, HOST_WIDE_INT *pmax,
>/* True if the argument's range cannot be determined.  */
>bool unknown = true;
>  
> -  type = TREE_TYPE (arg);
> +  tree argtype = TREE_TYPE (arg);
>  
> +  /* Ignore invalid arguments with greater precision that that
> +  of the expected type (e.g., in sprintf("%*i", 12LL, i)).
> +  They will have been detected and diagnosed by -Wformat and
> +  so it's not important to complicate this code to try to deal
> +  with them again.  */
>if (TREE_CODE (arg) == SSA_NAME
> -   && TREE_CODE (type) == INTEGER_TYPE)
> +   && TREE_CODE (argtype) == INTEGER_TYPE

I think you want
  && INTEGRAL_TYPE_P (argtype)
here instead of that last line, the middle-end considers conversions between
integral types useless (except for bool vs. non-bool conversions if the
other type has precision != 1), so if one does:
enum E { E0 = -__INT_MAX__ - 1, E1 = 1, E2 = 2, E3 = 3, E4 = __INT_MAX__ };
  enum E e = ...;
  snprintf (... "...%.*s...", ..., e, ...);
then you could very well have there ENUMERAL_TYPE etc.

Ok for trunk with that change.

Jakub

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Richard Biener]

On Mon, 10 Apr 2017, Jason Merrill wrote:

> On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener  wrote:
> > On Mon, 10 Apr 2017, Jason Merrill wrote:
> >> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener  wrote:
> >> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
> >> > for arrays of unsigned char or std::byte.
> >>
> >> I think it would be good to have a flag to select whether these
> >> semantics apply to any char variant and std::byte, only unsigned char
> >> and std::byte, or only std::byte.
> >
> > Any suggestion?  Not sure we really need it (I'm hesitant to write
> > all the testcases to verify it actually works).
> 
> Well, there's existing code that uses plain char (e.g. boost) that I
> want to support.  If there's a significant optimization penalty for
> allowing that, we probably also want to be able to limit the impact.
> If there isn't much penalty, let's just support all char variants.

I haven't assessed the penalty involved but it can't be worse than
the situation we had in GCC 6.  So I think it's reasonable to support
all char variants for now.  One could add some instrumenting to
alias_set_subset_of / alias_sets_conflict_p but it would only yield
an upper bound on the number of failed queries (TBAA is a quite early
out before PTA info is used for example).

The following variant -- added missing

Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c   (revision 246832)
+++ gcc/cp/tree.c   (working copy)
@@ -972,6 +979,7 @@ build_cplus_array_type (tree elt_type, t
 as it will overwrite alignment etc. of all variants.  */
  TYPE_SIZE (t) = TYPE_SIZE (m);
  TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (m);
+ TYPE_TYPELESS_STORAGE (t) = TYPE_TYPELESS_STORAGE (m);
}
 
  TYPE_MAIN_VARIANT (t) = m;

that caused LTO bootstrap to fail and removed the tree-ssa-structalias.c
change (committed separately) [LTO] bootstrapped and tested ok on 
x86_64-unknown-linux-gnu.

I've tested some template examples and they seem to work fine.

Ok for trunk?

Disclaimer: there might still be an issue with cross-language LTO
support, but it might at most result in TYPE_TYPELESS_STORAGE
getting lost.  Trying to craft a testcase to verify my theory.

Thanks,
Richard.

2017-04-11  Richard Biener  

PR c++/79671
cp/
* tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
for arrays of unsigned char or std::byte.

* tree-core.h (tree_type_common): Add typeless_storage flag.
* tree.h (TYPE_TYPELESS_STORAGE): New macro.
(canonical_type_used_p): Add arrays with TYPE_TYPELESS_STORAGE.
* alias.c (alias_set_entry): Add has_typeless_storage member.
(alias_set_subset_of): Handle it.
(alias_sets_conflict_p): Likewise.
(init_alias_set_entry): Initialize it.
(get_alias_set): For ARRAY_TYPEs handle TYPE_TYPELESS_STORAGE.
(record_alias_subset): Likewise.
* lto-streamer-out.c (hash_tree): Hash TYPE_TYPELESS_STORAGE.
* tree-streamer-in.c (unpack_ts_type_common_value_fields): Stream
TYPE_TYPELESS_STORAGE.
* tree-streamer-out.c (pack_ts_type_common_value_fields): Likewise.

lto/
* lto.c (compare_tree_sccs_1): Compare TYPE_TYPELESS_STORAGE.

* g++.dg/torture/pr79671.C: New testcase.

Index: gcc/alias.c
===
--- gcc/alias.c (revision 246832)
+++ gcc/alias.c (working copy)
@@ -136,6 +136,9 @@ struct GTY(()) alias_set_entry {
   bool is_pointer;
   /* Nonzero if is_pointer or if one of childs have has_pointer set.  */
   bool has_pointer;
+  /* Nonzero if we have a child serving as typeless storage (or are
+ such storage ourselves).  */
+  bool has_typeless_storage;
 
   /* The children of the alias set.  These are not just the immediate
  children, but, in fact, all descendants.  So, if we have:
@@ -419,7 +422,8 @@ alias_set_subset_of (alias_set_type set1
   /* Check if set1 is a subset of set2.  */
   ase2 = get_alias_set_entry (set2);
   if (ase2 != 0
-  && (ase2->has_zero_child
+  && (ase2->has_typeless_storage
+ || ase2->has_zero_child
  || (ase2->children && ase2->children->get (set1
 return true;
 
@@ -480,7 +484,8 @@ alias_sets_conflict_p (alias_set_type se
   /* See if the first alias set is a subset of the second.  */
   ase1 = get_alias_set_entry (set1);
   if (ase1 != 0
-  && ase1->children && ase1->children->get (set2))
+  && (ase1->has_typeless_storage
+ || (ase1->children && ase1->children->get (set2
 {
   ++alias_stats.num_dag;
   return 1;
@@ -489,7 +494,8 @@ alias_sets_conflict_p (alias_set_type se
   /* Now do the same, but with the alias sets reversed.  */
   ase2 = get_alias_set_entry (set2);
   if (ase2 != 0
-  && ase2->children && ase2->children->get (set1))
+  && (a

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Florian Weimer]

On 04/06/2017 09:12 PM, Richard Biener wrote:

Right.  The kernel also has many APIs which return multiple
variable-length data blocks, such as getdents64, and many more
interfaces in combination with read/recv system calls.  Variable length

means that you cannot declare the appropriate type after the first data

item, so you technically have to use malloc.

POSIX interfaces which exhibit a similar pattern are getpwnam_r and
friends, but for them, you can probably use malloc without ill effect
(although there are still performance concerns).



Can you give a concrete example which shows the issue and how typeless_storage 
helps?


An example is in libffi/src/closures.c:

  char buf[MAXPATHLEN * 3];

  if (getmntent_r (last_mntent, &mnt, buf, sizeof (buf)) == NULL)
return -1;

The intent is that buf is untyped storage, from which the getmntent_r 
function can allocate objects as needed (instead of using malloc).


Based on your earlier comments, GCC already supports that without any 
further source code annotations.


Thanks,
Florian

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Richard Biener]

On Tue, 11 Apr 2017, Florian Weimer wrote:

> On 04/06/2017 09:12 PM, Richard Biener wrote:
> > > Right.  The kernel also has many APIs which return multiple
> > > variable-length data blocks, such as getdents64, and many more
> > > interfaces in combination with read/recv system calls.  Variable length
> > > 
> > > means that you cannot declare the appropriate type after the first data
> > > 
> > > item, so you technically have to use malloc.
> > > 
> > > POSIX interfaces which exhibit a similar pattern are getpwnam_r and
> > > friends, but for them, you can probably use malloc without ill effect
> > > (although there are still performance concerns).
> 
> > Can you give a concrete example which shows the issue and how
> > typeless_storage helps?
> 
> An example is in libffi/src/closures.c:
> 
>   char buf[MAXPATHLEN * 3];
> 
>   if (getmntent_r (last_mntent, &mnt, buf, sizeof (buf)) == NULL)
> return -1;
> 
> The intent is that buf is untyped storage, from which the getmntent_r function
> can allocate objects as needed (instead of using malloc).
> 
> Based on your earlier comments, GCC already supports that without any further
> source code annotations.

Yes.

Richard.

[PATCH] Fix simplify-rtx.c ICE with vector float (not (neg)) (PR rtl-optimization/80385)

[Jakub Jelinek]

Hi!

The x86 intrinsics allow andnot on MODE_VECTOR_FLOAT modes, but
such modes have NULL CONSTM1_RTX and are not appropriate for the
transformation anyway.

The following patch fixes that, ok if bootstrap/regtest passes?
Or would you prefer to replace the
&& CONSTM1_RTX (mode)
check with e.g.
&& (MODE_CLASS (mode) == MODE_INT
|| MODE_CLASS (mode) == MODE_VECTOR_INT)
(dunno if we want to handle that way also partial int modes or not,
no experience with those)?
The transformation relies on 2's complement, so certainly doesn't apply
to floating modes (scalar or vector), but even MODE_COMPLEX_INT doesn't
have CONSTM1_RTX.

2017-04-11  Jakub Jelinek  

PR rtl-optimization/80385
* simplify-rtx.c (simplify_unary_operation_1): Don't transform
(not (neg X)) into (plus X -1) for complex or non-integral modes.

* g++.dg/opt/pr80385.C: New test.

--- gcc/simplify-rtx.c.jj   2017-04-04 07:32:57.0 +0200
+++ gcc/simplify-rtx.c  2017-04-11 12:26:05.550834274 +0200
@@ -932,8 +932,10 @@ simplify_unary_operation_1 (enum rtx_cod
  && XEXP (op, 1) == constm1_rtx)
return simplify_gen_unary (NEG, mode, XEXP (op, 0), mode);
 
-  /* Similarly, (not (neg X)) is (plus X -1).  */
-  if (GET_CODE (op) == NEG)
+  /* Similarly, (not (neg X)) is (plus X -1).  Only do this for
+modes that have CONSTM1_RTX, i.e. MODE_INT, MODE_PARTIAL_INT
+and MODE_VECTOR_INT.  */
+  if (GET_CODE (op) == NEG && CONSTM1_RTX (mode))
return simplify_gen_binary (PLUS, mode, XEXP (op, 0),
CONSTM1_RTX (mode));
 
--- gcc/testsuite/g++.dg/opt/pr80385.C.jj   2017-04-11 12:36:36.421806796 
+0200
+++ gcc/testsuite/g++.dg/opt/pr80385.C  2017-04-11 12:36:11.0 +0200
@@ -0,0 +1,14 @@
+// PR rtl-optimization/80385
+// { dg-do compile { target { i?86-*-* x86_64-*-* } } }
+// { dg-options "-Ofast -msse2" }
+
+#include 
+
+__m128 a, e;
+struct A { __m128 b; A (); A (__m128 x) : b(x) {} };
+A operator+ (A, A);
+A operator- (A) { __m128 c = -a; return c; }
+A foo (A x) { __m128 d = x.b; return _mm_andnot_ps (d, e); }
+struct B { A n[1]; };
+void bar (B x) { A f = foo (x.n[0]); A g = f + A (); }
+void baz () { B h; B i; A j; i.n[0] = -j; h = i; B k = h; bar (k); }

Jakub

[PATCH 3/3] When remapping paths, only match whole path components

[Ximin Luo]

Change the remapping algorithm so that each old_prefix only matches paths that
have old_prefix as a whole path component prefix.  (A whole path component is a
part of a path that begins and ends at a directory separator or at either end
of the path string.)

This remapping algorithm is more predictable than the old algorithm, because
there is no chance of mappings for one directory interfering with mappings for
other directories.  It contains less corner cases and is therefore nicer for
clients to use.  For these reasons, in our BUILD_PATH_PREFIX_MAP specification
we recommend this algorithm, and it would be good for GCC to follow suit.

This does technically break backwards compatibility but I don't think anyone
would be reasonably depending on the corner cases of the previous algorithm,
which are surprising and counterintuitive.

Acknowledgements


Discussions with Michael Woerister and other members of the Rust compiler team
on Github, and discussions with Daniel Shahaf on the rb-general@ mailing list
on lists.reproducible-builds.org.

ChangeLogs
--

gcc/ChangeLog:

2017-04-09  Ximin Luo  

* doc/invoke.texi (Environment Variables): Document form and behaviour
of BUILD_PATH_PREFIX_MAP.

libiberty/ChangeLog:

2017-04-09  Ximin Luo  

* prefix-map.c: When remapping paths, only match whole path components.

Index: gcc-7-20170409/gcc/doc/invoke.texi
===
--- gcc-7-20170409.orig/gcc/doc/invoke.texi
+++ gcc-7-20170409/gcc/doc/invoke.texi
@@ -26637,6 +26637,26 @@ Recognize EUCJP characters.
 If @env{LANG} is not defined, or if it has some other value, then the
 compiler uses @code{mblen} and @code{mbtowc} as defined by the default locale 
to
 recognize and translate multibyte characters.
+
+@item BUILD_PATH_PREFIX_MAP
+@findex BUILD_PATH_PREFIX_MAP
+If this variable is set, it specifies an ordered map used to transform
+filepaths output in debugging symbols and expansions of the @code{__FILE__}
+macro.  This may be used to achieve fully reproducible output.  In the context
+of running GCC within a higher-level build tool, it is typically more reliable
+than setting command line arguments such as @option{-fdebug-prefix-map} or
+common environment variables such as @env{CFLAGS}, since the build tool may
+save these latter values into other output outside of GCC's control.
+
+The value is of the form
+@samp{@var{dst@r{[0]}}=@var{src@r{[0]}}:@var{dst@r{[1]}}=@var{src@r{[1]}}@r{@dots{}}}.
+If any @var{dst@r{[}i@r{]}} or @var{src@r{[}i@r{]}} contains @code{%}, @code{=}
+or @code{:} characters, they must be replaced with @code{%#}, @code{%+}, and
+@code{%.} respectively.
+
+Whenever GCC emits a filepath that starts with a whole path component matching
+@var{src@r{[}i@r{]}} for some @var{i}, with rightmost @var{i} taking priority,
+the matching part is replaced with @var{dst@r{[}i@r{]}} in the final output.
 @end table
 
 @noindent
Index: gcc-7-20170409/libiberty/prefix-map.c
===
--- gcc-7-20170409.orig/libiberty/prefix-map.c
+++ gcc-7-20170409/libiberty/prefix-map.c
@@ -87,12 +87,22 @@ struct prefix_map *
 prefix_map_find (struct prefix_map *map, const char *old_name,
 const char **suffix, size_t *suf_len)
 {
+  size_t len;
+
   for (; map; map = map->next)
-if (filename_ncmp (old_name, map->old_prefix, map->old_len) == 0)
-  {
-   *suf_len = strlen (*suffix = old_name + map->old_len);
-   break;
-  }
+{
+  len = map->old_len;
+  /* Ignore trailing path separators at the end of old_prefix */
+  while (len > 0 && IS_DIR_SEPARATOR (map->old_prefix[len-1])) len--;
+  /* Check if old_name matches old_prefix at a path component boundary */
+  if (! filename_ncmp (old_name, map->old_prefix, len)
+ && (IS_DIR_SEPARATOR (old_name[len])
+ || old_name[len] == '\0'))
+   {
+ *suf_len = strlen (*suffix = old_name + len);
+ break;
+   }
+}
 
   return map;
 }

[PATCH 1/3] Use BUILD_PATH_PREFIX_MAP envvar for debug-prefix-map

[Ximin Luo]

Define the BUILD_PATH_PREFIX_MAP environment variable, and treat it as implicit
-fdebug-prefix-map CLI options specified before any explicit such options.

Much of the generic code for applying and parsing prefix-maps is implemented in
libiberty instead of the dwarf2 parts of the code, in order to make subsequent
patches unrelated to debuginfo easier.

Acknowledgements


Daniel Kahn Gillmor who wrote the patch for r231835, which saved me a lot of
time figuring out what to edit.

HW42 for discussion on the details of the proposal, and for suggesting that we
retain the ability to map the prefix to something other than ".".

Other contributors to the BUILD_PATH_PREFIX_MAP specification, see
https://reproducible-builds.org/specs/build-path-prefix-map/

ChangeLogs
--

include/ChangeLog:

2017-04-09  Ximin Luo  

* prefix-map.h: New file implementing the BUILD_PATH_PREFIX_MAP
specification; includes code from /gcc/final.c and code adapted from
examples attached to the specification.

libiberty/ChangeLog:

2017-04-09  Ximin Luo  

* prefix-map.c: New file implementing the BUILD_PATH_PREFIX_MAP
specification; includes code from /gcc/final.c and code adapted from
examples attached to the specification.
* Makefile.in: Update for new files.

gcc/ChangeLog:

2017-04-09  Ximin Luo  

* debug.h: Declare add_debug_prefix_map_from_envvar.
* final.c: Define add_debug_prefix_map_from_envvar, and refactor
prefix-map utilities to use equivalent code from libiberty instead.
* opts-global.c: (handle_common_deferred_options): Call
add_debug_prefix_map_from_envvar before processing options.

gcc/testsuite/ChangeLog:

2017-04-09  Ximin Luo  

* lib/gcc-dg.exp: Allow dg-set-compiler-env-var to take only one
argument in which case it unsets the given env var.
* gcc.dg/debug/dwarf2/build_path_prefix_map-1.c: New test.
* gcc.dg/debug/dwarf2/build_path_prefix_map-2.c: New test.

Index: gcc-7-20170409/include/prefix-map.h
===
--- /dev/null
+++ gcc-7-20170409/include/prefix-map.h
@@ -0,0 +1,94 @@
+/* Declarations for manipulating filename prefixes.
+   Written 2017 by Ximin Luo 
+   This code is in the public domain. */
+
+#ifndef _PREFIX_MAP_H
+#define _PREFIX_MAP_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#ifdef HAVE_STDLIB_H
+#include 
+#endif
+
+/* Linked-list of mappings from old prefixes to new prefixes.  */
+
+struct prefix_map
+{
+  const char *old_prefix;
+  const char *new_prefix;
+  size_t old_len;
+  size_t new_len;
+  struct prefix_map *next;
+};
+
+
+/* Find a mapping suitable for the given OLD_NAME in the linked list MAP.\
+
+   If a mapping is found, writes a pointer to the non-matching suffix part of
+   OLD_NAME in SUFFIX, and its length in SUF_LEN.
+
+   Returns NULL if there was no suitable mapping.  */
+struct prefix_map *
+prefix_map_find (struct prefix_map *map, const char *old_name,
+const char **suffix, size_t *suf_len);
+
+/* Prepend a prefix map before a given SUFFIX.
+
+   The remapped name is written to NEW_NAME and returned as a const pointer. No
+   allocations are performed; the caller must ensure it can hold at least
+   MAP->NEW_LEN + SUF_LEN + 1 characters.  */
+const char *
+prefix_map_prepend (struct prefix_map *map, char *new_name,
+   const char *suffix, size_t suf_len);
+
+/* Remap a filename.
+
+   Returns OLD_NAME unchanged if there was no remapping, otherwise returns a
+   pointer to newly-allocated memory for the remapped filename.  The memory is
+   allocated by the given ALLOC function, which also determines who is
+   responsible for freeing it.  */
+#define prefix_map_remap_alloc_(map_head, old_name, alloc)\
+  __extension__
   \
+  ({  \
+const char *__suffix; \
+size_t __suf_len; \
+struct prefix_map *__map; \
+(__map = prefix_map_find ((map_head), (old_name), &__suffix, &__suf_len))  
\
+  ? prefix_map_prepend (__map,\
+   (char *) alloc (__map->new_len + __suf_len + 1),   \
+   __suffix, __suf_len)   \
+  : (old_name);   \
+  })
+
+/* Remap a filename.
+
+   Returns OLD_NAME unchanged if there was no remapping, otherwise returns a
+   stack-allocated pointer to the newly-remapped filename.  */
+#define prefix_map_remap_alloca(map_head, old_name) \
+  prefix_map_remap_alloc_ (map_head, old_name, alloca)
+
+
+/* Parse prefix-maps acc

[PATCH v2] Generate reproducible output independently of the build-path

[Ximin Luo]

(Please keep me on CC, I am not subscribed)

Background
==

Previous background is here: 
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00182.html

Upon further discussion, we decided to add support for multiple mappings and to
rename the environment variable to BUILD_PATH_PREFIX_MAP. We have also prepared
a document that describes how this works in detail, so that projects can be
confident that they are interoperable:

https://reproducible-builds.org/specs/build-path-prefix-map/

The specification is currently in DRAFT status, awaiting some final feedback,
including what the GCC maintainers think about it.

If one is interested in reading about this topic in the wider context of
reproducible builds, there's some more background here:

https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables

Proposal


This patch series adds a new environment variable BUILD_PATH_PREFIX_MAP. When
this is set, GCC will treat this as extra implicit "-fdebug-prefix-map=$value"
command-line arguments that precede any explicit ones. This makes the final
binary output reproducible, and also hides the unreproducible value (the source
path prefixes) from CFLAGS et. al. which many build tools (understandably)
embed as-is into their build output.

This environment variable also acts on the __FILE__ macro, mapping it in the
same way that debug-prefix-map works for debug symbols. We have seen that
__FILE__ is also a very large source of unreproducibility, and is represented
quite heavily in the 3k+ figure given earlier.

Finally, we tweak the mapping algorithm so that it applies only to whole path
components when matching prefixes. This algorithm contains fewer corner cases
and is more predictable, so it is easier for users to figure out how to set the
mapping appropriately, and it is better as a standardised algorithm that other
build tools might like to adopt. (The original idea came from discussions with
some rustc developers about this same topic.) This does technically break
backwards-compatibility, but I was under the impression that this option was
not seen as such a critical feature, that this would be too important. I am
also happy to justify it in more detail on request.

Nevertheless, for this reason our draft specification currently offers two
algorithms for implementers, but I would reduce this to one if the GCC
maintainers agree to accept this third patch.

Testing
===

I've tested these patches on a Debian unstable x86_64-linux-gnu schroot running
inside a Debian jessie system, on a full-bootstrap build. The output of
contrib/compare_tests is as follows:


gcc-7-20170409$ contrib/compare_tests ../gcc-build-0 ../gcc-build-1
# Comparing directories
## Dir1=../gcc-build-0: 8 sum files
## Dir2=../gcc-build-1: 8 sum files

# Comparing 8 common sum files
## /bin/sh contrib/compare_tests  /tmp/gxx-sum1.24154 /tmp/gxx-sum2.24154
New tests that PASS:

gcc.dg/cpp/build_path_prefix_map-1.c (test for excess errors)
gcc.dg/cpp/build_path_prefix_map-1.c execution test
gcc.dg/cpp/build_path_prefix_map-2.c (test for excess errors)
gcc.dg/cpp/build_path_prefix_map-2.c execution test
gcc.dg/debug/dwarf2/build_path_prefix_map-1.c (test for excess errors)
gcc.dg/debug/dwarf2/build_path_prefix_map-1.c scan-assembler DW_AT_comp_dir: 
"DWARF2TEST/gcc
gcc.dg/debug/dwarf2/build_path_prefix_map-2.c (test for excess errors)
gcc.dg/debug/dwarf2/build_path_prefix_map-2.c scan-assembler DW_AT_comp_dir: "/

# No differences found in 8 common sum files


I can also provide the full logs on request.

--

I've also fuzzed the prefix-map code using AFL with ASAN enabled. Due to how
AFL works I did not fuzz this patch directly but a smaller program with just
the parser and remapper, available here:

https://anonscm.debian.org/cgit/reproducible/build-path-prefix-map-spec.git/tree/consume

Over the course of about ~4k cycles, no crashes were found.

To reproduce, you could run something like:

$ echo performance | sudo tee 
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
$ make CC=afl-gcc clean reset-fuzz-pecsplit.c fuzz-pecsplit.c

--

I will soon test this patch backported to Debian GCC-6 on
tests.reproducible-builds.org and will have results in a few days or weeks.
Some preliminary tests earlier gave good results (about +40 packages
reproducible over ~2 days) but we had to abort due to some misscheduling.

Copyright disclaimer


I dedicate these patches to the public domain by waiving all of my rights to
the work worldwide under copyright law, including all related and neighboring
rights, to the extent allowed by law.

See https://creativecommons.org/publicdomain/zero/1.0/legalcode for full text.

Please let me know if the above is insufficient and I will be happy to sign any
relevant forms.

However, I would prefer it if the prefix-map.{h,c} remain public domain since
its code is also duplicated in our "example code" repo (url above), which is
meant for other projects to copy+paste.

[PATCH 2/3] Use BUILD_PATH_PREFIX_MAP envvar to transform __FILE__

[Ximin Luo]

Use the BUILD_PATH_PREFIX_MAP environment variable when expanding the __FILE__
macro, in the same way that debug-prefix-map works for debugging symbol paths.

This patch follows similar lines to the earlier patch for SOURCE_DATE_EPOCH.
Specifically, we read the environment variable not in libcpp but via a hook
which has an implementation defined in gcc/c-family.  However, to achieve this
is more complex than the earlier patch: we need to share the prefix_map data
structure and associated functions between libcpp and c-family.  Therefore, we
need to move these to libiberty.  (For comparison, the SOURCE_DATE_EPOCH patch
did not need this because time_t et. al. are in the standard C library.)

Acknowledgements


Dhole  who wrote the earlier patch for SOURCE_DATE_EPOCH
which saved me a lot of time on figuring out what to edit.

ChangeLogs
--

gcc/c-family/ChangeLog:

2017-03-27  Ximin Luo  

* c-common.c (cb_get_build_path_prefix_map): Define new call target.
* c-common.h (cb_get_build_path_prefix_map): Declare call target.
* c-lex.c (init_c_lex): Set the get_build_path_prefix_map callback.

libcpp/ChangeLog:

2017-03-27  Ximin Luo  

* include/cpplib.h (cpp_callbacks): Add get_build_path_prefix_map
callback.
* init.c (cpp_create_reader): Initialise build_path_prefix_map field.
* internal.h (cpp_reader): Add new field build_path_prefix_map.
* macro.c (_cpp_builtin_macro_text): Set the build_path_prefix_map
field if unset and apply it when expanding __FILE__ macros.

gcc/testsuite/ChangeLog:

2017-03-27  Ximin Luo  

* gcc.dg/cpp/build_path_prefix_map-1.c: New test.
* gcc.dg/cpp/build_path_prefix_map-2.c: New test.

Index: gcc-7-20170402/gcc/c-family/c-common.c
===
--- gcc-7-20170402.orig/gcc/c-family/c-common.c
+++ gcc-7-20170402/gcc/c-family/c-common.c
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.
 
 #include "config.h"
 #include "system.h"
+#include "prefix-map.h"
 #include "coretypes.h"
 #include "target.h"
 #include "function.h"
@@ -8012,6 +8013,25 @@ cb_get_source_date_epoch (cpp_reader *pf
   return (time_t) epoch;
 }
 
+/* Read BUILD_PATH_PREFIX_MAP from environment to have deterministic relative
+   paths to replace embedded absolute paths to get reproducible results.
+   Returns NULL if BUILD_PATH_PREFIX_MAP is badly formed.  */
+
+prefix_map **
+cb_get_build_path_prefix_map (cpp_reader *pfile ATTRIBUTE_UNUSED)
+{
+  prefix_map **map = XCNEW (prefix_map *);
+
+  const char *arg = getenv ("BUILD_PATH_PREFIX_MAP");
+  if (!arg || prefix_map_parse (map, arg))
+return map;
+
+  free (map);
+  error_at (input_location, "environment variable BUILD_PATH_PREFIX_MAP is "
+   "not well formed; see the GCC documentation for more details.");
+  return NULL;
+}
+
 /* Callback for libcpp for offering spelling suggestions for misspelled
directives.  GOAL is an unrecognized string; CANDIDATES is a
NULL-terminated array of candidate strings.  Return the closest
Index: gcc-7-20170402/gcc/c-family/c-common.h
===
--- gcc-7-20170402.orig/gcc/c-family/c-common.h
+++ gcc-7-20170402/gcc/c-family/c-common.h
@@ -1085,6 +1085,11 @@ extern time_t cb_get_source_date_epoch (
__TIME__ can store.  */
 #define MAX_SOURCE_DATE_EPOCH HOST_WIDE_INT_C (253402300799)
 
+/* Read BUILD_PATH_PREFIX_MAP from environment to have deterministic relative
+   paths to replace embedded absolute paths to get reproducible results.
+   Returns NULL if BUILD_PATH_PREFIX_MAP is badly formed.  */
+extern prefix_map **cb_get_build_path_prefix_map (cpp_reader *pfile);
+
 /* Callback for libcpp for offering spelling suggestions for misspelled
directives.  */
 extern const char *cb_get_suggestion (cpp_reader *, const char *,
Index: gcc-7-20170402/gcc/c-family/c-lex.c
===
--- gcc-7-20170402.orig/gcc/c-family/c-lex.c
+++ gcc-7-20170402/gcc/c-family/c-lex.c
@@ -81,6 +81,7 @@ init_c_lex (void)
   cb->read_pch = c_common_read_pch;
   cb->has_attribute = c_common_has_attribute;
   cb->get_source_date_epoch = cb_get_source_date_epoch;
+  cb->get_build_path_prefix_map = cb_get_build_path_prefix_map;
   cb->get_suggestion = cb_get_suggestion;
 
   /* Set the debug callbacks if we can use them.  */
Index: gcc-7-20170402/libcpp/include/cpplib.h
===
--- gcc-7-20170402.orig/libcpp/include/cpplib.h
+++ gcc-7-20170402/libcpp/include/cpplib.h
@@ -607,6 +607,9 @@ struct cpp_callbacks
   /* Callback to parse SOURCE_DATE_EPOCH from environment.  */
   time_t (*get_source_date_epoch) (cpp_reader *);
 
+  /* Callback to parse BUILD_PATH_PREFIX_MAP from environment.  */
+  struct prefix_map **(*get_build_path_prefix_map) (cpp_reader *);
+
   /* Callback for providing suggestions f

Re: [PATCH] Fix simplify-rtx.c ICE with vector float (not (neg)) (PR rtl-optimization/80385)

[Richard Biener]

On Tue, 11 Apr 2017, Jakub Jelinek wrote:

> Hi!
> 
> The x86 intrinsics allow andnot on MODE_VECTOR_FLOAT modes, but
> such modes have NULL CONSTM1_RTX and are not appropriate for the
> transformation anyway.
> 
> The following patch fixes that, ok if bootstrap/regtest passes?
> Or would you prefer to replace the
> && CONSTM1_RTX (mode)
> check with e.g.
> && (MODE_CLASS (mode) == MODE_INT
> || MODE_CLASS (mode) == MODE_VECTOR_INT)
> (dunno if we want to handle that way also partial int modes or not,
> no experience with those)?
> The transformation relies on 2's complement, so certainly doesn't apply
> to floating modes (scalar or vector), but even MODE_COMPLEX_INT doesn't
> have CONSTM1_RTX.

I think the patch is ok as-is.

Richard.

> 2017-04-11  Jakub Jelinek  
> 
>   PR rtl-optimization/80385
>   * simplify-rtx.c (simplify_unary_operation_1): Don't transform
>   (not (neg X)) into (plus X -1) for complex or non-integral modes.
> 
>   * g++.dg/opt/pr80385.C: New test.
> 
> --- gcc/simplify-rtx.c.jj 2017-04-04 07:32:57.0 +0200
> +++ gcc/simplify-rtx.c2017-04-11 12:26:05.550834274 +0200
> @@ -932,8 +932,10 @@ simplify_unary_operation_1 (enum rtx_cod
> && XEXP (op, 1) == constm1_rtx)
>   return simplify_gen_unary (NEG, mode, XEXP (op, 0), mode);
>  
> -  /* Similarly, (not (neg X)) is (plus X -1).  */
> -  if (GET_CODE (op) == NEG)
> +  /* Similarly, (not (neg X)) is (plus X -1).  Only do this for
> +  modes that have CONSTM1_RTX, i.e. MODE_INT, MODE_PARTIAL_INT
> +  and MODE_VECTOR_INT.  */
> +  if (GET_CODE (op) == NEG && CONSTM1_RTX (mode))
>   return simplify_gen_binary (PLUS, mode, XEXP (op, 0),
>   CONSTM1_RTX (mode));
>  
> --- gcc/testsuite/g++.dg/opt/pr80385.C.jj 2017-04-11 12:36:36.421806796 
> +0200
> +++ gcc/testsuite/g++.dg/opt/pr80385.C2017-04-11 12:36:11.0 
> +0200
> @@ -0,0 +1,14 @@
> +// PR rtl-optimization/80385
> +// { dg-do compile { target { i?86-*-* x86_64-*-* } } }
> +// { dg-options "-Ofast -msse2" }
> +
> +#include 
> +
> +__m128 a, e;
> +struct A { __m128 b; A (); A (__m128 x) : b(x) {} };
> +A operator+ (A, A);
> +A operator- (A) { __m128 c = -a; return c; }
> +A foo (A x) { __m128 d = x.b; return _mm_andnot_ps (d, e); }
> +struct B { A n[1]; };
> +void bar (B x) { A f = foo (x.n[0]); A g = f + A (); }
> +void baz () { B h; B i; A j; i.n[0] = -j; h = i; B k = h; bar (k); }
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Richard Biener]

On Tue, 11 Apr 2017, Richard Biener wrote:

> On Mon, 10 Apr 2017, Jason Merrill wrote:
> 
> > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener  wrote:
> > > On Mon, 10 Apr 2017, Jason Merrill wrote:
> > >> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener  
> > >> wrote:
> > >> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
> > >> > for arrays of unsigned char or std::byte.
> > >>
> > >> I think it would be good to have a flag to select whether these
> > >> semantics apply to any char variant and std::byte, only unsigned char
> > >> and std::byte, or only std::byte.
> > >
> > > Any suggestion?  Not sure we really need it (I'm hesitant to write
> > > all the testcases to verify it actually works).
> > 
> > Well, there's existing code that uses plain char (e.g. boost) that I
> > want to support.  If there's a significant optimization penalty for
> > allowing that, we probably also want to be able to limit the impact.
> > If there isn't much penalty, let's just support all char variants.
> 
> I haven't assessed the penalty involved but it can't be worse than
> the situation we had in GCC 6.  So I think it's reasonable to support
> all char variants for now.  One could add some instrumenting to
> alias_set_subset_of / alias_sets_conflict_p but it would only yield
> an upper bound on the number of failed queries (TBAA is a quite early
> out before PTA info is used for example).
> 
> The following variant -- added missing
> 
> Index: gcc/cp/tree.c
> ===
> --- gcc/cp/tree.c   (revision 246832)
> +++ gcc/cp/tree.c   (working copy)
> @@ -972,6 +979,7 @@ build_cplus_array_type (tree elt_type, t
>  as it will overwrite alignment etc. of all variants.  */
>   TYPE_SIZE (t) = TYPE_SIZE (m);
>   TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (m);
> + TYPE_TYPELESS_STORAGE (t) = TYPE_TYPELESS_STORAGE (m);
> }
>  
>   TYPE_MAIN_VARIANT (t) = m;
> 
> that caused LTO bootstrap to fail and removed the tree-ssa-structalias.c
> change (committed separately) [LTO] bootstrapped and tested ok on 
> x86_64-unknown-linux-gnu.
> 
> I've tested some template examples and they seem to work fine.
> 
> Ok for trunk?
> 
> Disclaimer: there might still be an issue with cross-language LTO
> support, but it might at most result in TYPE_TYPELESS_STORAGE
> getting lost.  Trying to craft a testcase to verify my theory.

Not too difficult in the end (see below).  A fix (below) is to
not treat arrays with differing TYPE_TYPELESS_STORAGE as
compatible for the purpose of computing TYPE_CANONICAL (and
thus recursively structures containing them).  While they'd
still alias each other (because currently a TYPE_TYPELESS_STORAGE
member makes the whole thing effectively alias anything) this
results in warnings in case such a type is used in the interface
between C and C++ (it's also considered a ODR type).

t.C:17:17: warning: type of ‘bar’ does not match original declaration 
[-Wlto-type-mismatch]
 extern "C" void bar (X *);
 ^
t2.c:5:6: note: ‘bar’ was previously declared here
 void bar (struct X *p) {}
  ^

if you add a struct X * parameter to bar().

So it's not the optimal solution here.  Another fix would be to
somehow make TYPE_TYPELESS_STORAGE "sticky" when merging canonical
types but there's not precedent in doing this kind of thing and
I'm not sure we'll get everything merged before computing alias
sets.

CCing Honza.

Richard.

2017-04-11  Richard Biener  

PR middle-end/79671
* tree.c (gimple_canonical_types_compatible_p): Do not treat
arrays with differing TYPE_TYPELESS_STORAGE as compatible.

* g++.dg/lto/pr79671_0.C: New testcase.
* g++.dg/lto/pr79671_1.c: Likewise.

Index: gcc/tree.c
===
*** gcc/tree.c  (revision 246835)
--- gcc/tree.c  (working copy)
*** gimple_canonical_types_compatible_p (con
*** 13709,13715 
trust_type_canonical)
  || TYPE_STRING_FLAG (t1) != TYPE_STRING_FLAG (t2)
  || TYPE_REVERSE_STORAGE_ORDER (t1) != TYPE_REVERSE_STORAGE_ORDER (t2)
! || TYPE_NONALIASED_COMPONENT (t1) != TYPE_NONALIASED_COMPONENT (t2))
return false;
else
{
--- 13709,13716 
trust_type_canonical)
  || TYPE_STRING_FLAG (t1) != TYPE_STRING_FLAG (t2)
  || TYPE_REVERSE_STORAGE_ORDER (t1) != TYPE_REVERSE_STORAGE_ORDER (t2)
! || TYPE_NONALIASED_COMPONENT (t1) != TYPE_NONALIASED_COMPONENT (t2)
! || TYPE_TYPELESS_STORAGE (t1) != TYPE_TYPELESS_STORAGE (t2))
return false;
else
{
Index: gcc/testsuite/g++.dg/lto/pr79671_0.C
===
*** gcc/testsuite/g++.dg/lto/pr79671_0.C(nonexistent)
--- gcc/test

[PATCH] Do not instrument register variables in object-size sanitizer (PR sanitizer/80387).

[Martin Liška]

Hello.

Even though the original test-case is slp target-specific, one can easily come 
up with a test-case
which fails on arbitrary target. Problem is a register variable that is used 
wrongly in a function call
that expects an address to be given. Fixed by not instrumenting such 
declarations.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
On x86_64-linux-gnu target ubsan.exp tests work.

Ready to be installed?
Martin
>From 87ce95625d97638a29efebdc0520599ce2379fbd Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 11 Apr 2017 09:58:19 +0200
Subject: [PATCH] Do not instrument register variables in object-size sanitizer
 (PR sanitizer/80387).

gcc/ChangeLog:

2017-04-11  Martin Liska  

	PR sanitizer/80387
	* ubsan.c (instrument_object_size): Do not instrument register
	variables.

gcc/testsuite/ChangeLog:

2017-04-11  Martin Liska  

	PR sanitizer/80387
	* gcc.dg/ubsan/pr70878.c: New test.
---
 gcc/testsuite/gcc.dg/ubsan/pr70878.c | 9 +
 gcc/ubsan.c  | 6 +-
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/ubsan/pr70878.c

diff --git a/gcc/testsuite/gcc.dg/ubsan/pr70878.c b/gcc/testsuite/gcc.dg/ubsan/pr70878.c
new file mode 100644
index 000..15b54e244fc
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ubsan/pr70878.c
@@ -0,0 +1,9 @@
+/* PR sanitizer/80878 */
+/* { dg-do compile { target { x86_64-*-* } } } */
+/* { dg-options "-fsanitize=object-size" } */
+
+void * sbrk ()
+{
+ volatile register unsigned int sp_r1 __asm__ ("ebx");
+ return __builtin_strcat ((char*)sp_r1, 0); /* { dg-warning "cast to pointer from integer of different size" } */
+}
diff --git a/gcc/ubsan.c b/gcc/ubsan.c
index 323c1ccdb49..c01d63318c2 100644
--- a/gcc/ubsan.c
+++ b/gcc/ubsan.c
@@ -1806,7 +1806,11 @@ instrument_object_size (gimple_stmt_iterator *gsi, bool is_lhs)
   bool decl_p = DECL_P (inner);
   tree base;
   if (decl_p)
-base = inner;
+{
+  if (DECL_REGISTER (inner))
+	return;
+  base = inner;
+}
   else if (TREE_CODE (inner) == MEM_REF)
 base = TREE_OPERAND (inner, 0);
   else
-- 
2.12.2

Re: [PATCH] Do not instrument register variables in object-size sanitizer (PR sanitizer/80387).

[Jakub Jelinek]

On Tue, Apr 11, 2017 at 02:33:52PM +0200, Martin Liška wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/ubsan/pr70878.c
> @@ -0,0 +1,9 @@
> +/* PR sanitizer/80878 */
> +/* { dg-do compile { target { x86_64-*-* } } } */

The target looks wrong.  In any case, it should be
i?86-*-* x86_64-*-*, e.g. on Solaris it is a multilib
compiler with -m32 default and -m64 optional.
Then the question is if you really need lp64 for the test
or not.  So either:
/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
and then guard the dg-warning with { target lp64 },
or
/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */

Please test the testcase with
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
ubsan.exp=pr70878.c'
Ok with one of those changes.

Jakub

Re: [PATCH] Do not instrument register variables in object-size sanitizer (PR sanitizer/80387).

[Martin Liška]

On 04/11/2017 02:52 PM, Jakub Jelinek wrote:
> On Tue, Apr 11, 2017 at 02:33:52PM +0200, Martin Liška wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/ubsan/pr70878.c
>> @@ -0,0 +1,9 @@
>> +/* PR sanitizer/80878 */
>> +/* { dg-do compile { target { x86_64-*-* } } } */
> 
> The target looks wrong.  In any case, it should be
> i?86-*-* x86_64-*-*, e.g. on Solaris it is a multilib
> compiler with -m32 default and -m64 optional.
> Then the question is if you really need lp64 for the test
> or not.  So either:
> /* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
> and then guard the dg-warning with { target lp64 },
> or
> /* { dg-do compile { target { { i?86-*-* x86_64-*-* } && lp64 } } } */
> 
> Please test the testcase with
> make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} 
> ubsan.exp=pr70878.c'
> Ok with one of those changes.

Thanks for help! I decided for the second variant. Survives the make check-gcc.
Installed as r246837.

Btw. I did typo in PR number, it's 70878 (fixed in changelog entry).

Martin

> 
>   Jakub
> 

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Richard Biener]

On Tue, 11 Apr 2017, Richard Biener wrote:

> On Tue, 11 Apr 2017, Richard Biener wrote:
> 
> > On Mon, 10 Apr 2017, Jason Merrill wrote:
> > 
> > > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener  
> > > wrote:
> > > > On Mon, 10 Apr 2017, Jason Merrill wrote:
> > > >> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener  
> > > >> wrote:
> > > >> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
> > > >> > for arrays of unsigned char or std::byte.
> > > >>
> > > >> I think it would be good to have a flag to select whether these
> > > >> semantics apply to any char variant and std::byte, only unsigned char
> > > >> and std::byte, or only std::byte.
> > > >
> > > > Any suggestion?  Not sure we really need it (I'm hesitant to write
> > > > all the testcases to verify it actually works).
> > > 
> > > Well, there's existing code that uses plain char (e.g. boost) that I
> > > want to support.  If there's a significant optimization penalty for
> > > allowing that, we probably also want to be able to limit the impact.
> > > If there isn't much penalty, let's just support all char variants.
> > 
> > I haven't assessed the penalty involved but it can't be worse than
> > the situation we had in GCC 6.  So I think it's reasonable to support
> > all char variants for now.  One could add some instrumenting to
> > alias_set_subset_of / alias_sets_conflict_p but it would only yield
> > an upper bound on the number of failed queries (TBAA is a quite early
> > out before PTA info is used for example).
> > 
> > The following variant -- added missing
> > 
> > Index: gcc/cp/tree.c
> > ===
> > --- gcc/cp/tree.c   (revision 246832)
> > +++ gcc/cp/tree.c   (working copy)
> > @@ -972,6 +979,7 @@ build_cplus_array_type (tree elt_type, t
> >  as it will overwrite alignment etc. of all variants.  */
> >   TYPE_SIZE (t) = TYPE_SIZE (m);
> >   TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (m);
> > + TYPE_TYPELESS_STORAGE (t) = TYPE_TYPELESS_STORAGE (m);
> > }
> >  
> >   TYPE_MAIN_VARIANT (t) = m;
> > 
> > that caused LTO bootstrap to fail and removed the tree-ssa-structalias.c
> > change (committed separately) [LTO] bootstrapped and tested ok on 
> > x86_64-unknown-linux-gnu.
> > 
> > I've tested some template examples and they seem to work fine.
> > 
> > Ok for trunk?
> > 
> > Disclaimer: there might still be an issue with cross-language LTO
> > support, but it might at most result in TYPE_TYPELESS_STORAGE
> > getting lost.  Trying to craft a testcase to verify my theory.
> 
> Not too difficult in the end (see below).  A fix (below) is to
> not treat arrays with differing TYPE_TYPELESS_STORAGE as
> compatible for the purpose of computing TYPE_CANONICAL (and
> thus recursively structures containing them).  While they'd
> still alias each other (because currently a TYPE_TYPELESS_STORAGE
> member makes the whole thing effectively alias anything) this
> results in warnings in case such a type is used in the interface
> between C and C++ (it's also considered a ODR type).
> 
> t.C:17:17: warning: type of ‘bar’ does not match original declaration 
> [-Wlto-type-mismatch]
>  extern "C" void bar (X *);
>  ^
> t2.c:5:6: note: ‘bar’ was previously declared here
>  void bar (struct X *p) {}
>   ^
> 
> if you add a struct X * parameter to bar().
> 
> So it's not the optimal solution here.  Another fix would be to
> somehow make TYPE_TYPELESS_STORAGE "sticky" when merging canonical
> types but there's not precedent in doing this kind of thing and
> I'm not sure we'll get everything merged before computing alias
> sets.
> 
> CCing Honza.

So after discussion and some more thinking we don't really benefit
(and really can't) from having different aggregates with such
members distignuishable via their alias set.  So the following
simplifies the approach and makes the above LTO bits trivial
by more following Bernds approach of assigning the types alias
set zero and instead of in the alias machinery propagate the
flag on the types.

It should also make reference_alias_ptr_type correct and it
does the flag propagation in type layout.

[LTO] bootstrap and regtest running on x86_64-unknown-linux-gnu.

The C++ bits are unchanged.

Richard.

2017-04-11  Richard Biener  
Bernd Edlinger  

PR middle-end/79671
* alias.c (component_uses_parent_alias_set_from): Handle
TYPE_TYPELESS_STORAGE.
(get_alias_set): Likewise.
* tree-core.h (tree_type_common): Add typeless_storage flag.
* tree.h (TYPE_TYPELESS_STORAGE): New macro.
* stor-layout.c (place_union_field): Set TYPE_TYPELESS_STORAGE
for types containing members with TYPE_TYPELESS_STORAGE.
(place_field): Likewise.
(layout_type): Likewise for ARRAY_TYPE.
* lto-streamer-out.c (hash_tree): Hash TYPE_TYPELESS_STORAGE.
* tree-streamer-in.

[C++ PATCH] Fix decomp ICEs in templates (PR c++/80370, take 2)

[Jakub Jelinek]

Hi!

On Mon, Apr 10, 2017 at 04:48:43PM -0400, Jason Merrill wrote:
> On Mon, Apr 10, 2017 at 4:35 PM, Jakub Jelinek  wrote:
> > - store_decomp_type (v[i], eltype);
> > + if (!processing_template_decl)
> > +   store_decomp_type (v[i], eltype);
> 
> This spot shouldn't change; we do want to remember the decltype even
> in a template.
> 
> > @@ -3935,7 +3935,10 @@ cxx_eval_constant_expression (const cons
> >return (*ctx->values->get (t));
> >
> >  case VAR_DECL:
> > -  if (DECL_HAS_VALUE_EXPR_P (t))
> > +  if (DECL_HAS_VALUE_EXPR_P (t)
> > + /* Don't recurse on DECL_VALUE_EXPR of decomposition decls
> > +that have not been finalized yet.  */
> > + && (!DECL_DECOMPOSITION_P (t) || TREE_TYPE (DECL_VALUE_EXPR (t
> 
> Hmm, we shouldn't get here in this case.  I think
> value_dependent_expression_p should return true for a VAR_DECL with
> type-dependent DECL_VALUE_EXPR.

So like this?  Or just type_dependent_expression_p check rather than
both?

2017-04-11  Jakub Jelinek  

PR c++/80370
* decl.c (cp_finish_decomp): If processing_template_decl on
non-dependent decl, only set TREE_TYPE on the v[i] decls, but don't
change their DECL_VALUE_EXPR nor cp_finish_decl them.  Instead make
sure DECL_VALUE_EXPR is the canonical NULL type ARRAY_REF for tsubst
processing.
* pt.c (value_dependent_expression_p) : For variables
with DECL_VALUE_EXPR, return true if DECL_VALUE_EXPR is type or
value dependent.

* g++.dg/cpp1z/decomp28.C: New test.

--- gcc/cp/decl.c.jj2017-04-10 22:26:56.441388051 +0200
+++ gcc/cp/decl.c   2017-04-11 15:21:24.473163169 +0200
@@ -7473,6 +7473,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  t = build4_loc (DECL_SOURCE_LOCATION (v[i]), ARRAY_REF,
  eltype, t, size_int (i), NULL_TREE,
@@ -7492,6 +7494,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  t = build1_loc (DECL_SOURCE_LOCATION (v[i]),
  i ? IMAGPART_EXPR : REALPART_EXPR, eltype,
@@ -7510,6 +7514,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  convert_vector_to_array_for_subscript (DECL_SOURCE_LOCATION (v[i]),
 &t, size_int (i));
@@ -7559,8 +7565,9 @@ cp_finish_decomp (tree decl, tree first,
  SET_DECL_VALUE_EXPR (v[i], NULL_TREE);
  DECL_HAS_VALUE_EXPR_P (v[i]) = 0;
}
- cp_finish_decl (v[i], init, /*constexpr*/false,
- /*asm*/NULL_TREE, LOOKUP_NORMAL);
+ if (!processing_template_decl)
+   cp_finish_decl (v[i], init, /*constexpr*/false,
+   /*asm*/NULL_TREE, LOOKUP_NORMAL);
}
 }
   else if (TREE_CODE (type) == UNION_TYPE)
@@ -7615,12 +7622,26 @@ cp_finish_decomp (tree decl, tree first,
  tt = TREE_OPERAND (tt, 0);
TREE_TYPE (v[i]) = TREE_TYPE (tt);
layout_decl (v[i], 0);
-   SET_DECL_VALUE_EXPR (v[i], tt);
-   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+   if (!processing_template_decl)
+ {
+   SET_DECL_VALUE_EXPR (v[i], tt);
+   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+ }
i++;
  }
 }
-  if (DECL_NAMESPACE_SCOPE_P (decl))
+  if (processing_template_decl)
+{
+  for (unsigned int i = 0; i < count; i++)
+   if (!DECL_HAS_VALUE_EXPR_P (v[i]))
+ {
+   tree a = build_nt (ARRAY_REF, decl, size_int (i),
+  NULL_TREE, NULL_TREE);
+   SET_DECL_VALUE_EXPR (v[i], a);
+   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+ }
+}
+  else if (DECL_NAMESPACE_SCOPE_P (decl))
 SET_DECL_ASSEMBLER_NAME (decl, mangle_decomp (decl, v));
 }
 
--- gcc/cp/pt.c.jj  2017-04-10 08:18:51.0 +0200
+++ gcc/cp/pt.c 2017-04-11 15:37:59.727673709 +0200
@@ -23576,6 +23576,13 @@ value_dependent_expression_p (tree expre
  || type_dependent_expression_p (DECL_INITIAL (expression))
  || value_dependent_expression_p (DECL_INITIAL (expression
return true;
+  if (DECL_HAS_VALUE_EXPR_P (expression))
+   {
+ tree value_expr = DECL_VALUE_EXPR (expression);
+ if (type_dependent_expression_p (value_expr)
+ || value_dependent_expression_p (value_expr))
+   return true;
+   }
   re

Re: [PATCH] Add function part to a same comdat group (PR ipa/80212).

[Martin Liška]

Hello.

This is my second attempt to fix the PR I worked on with Honza and Martin 
Jambor.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. 
Apart from that
octoploid confirmed it can survive LLVM build. And I can build Firefox and 
boost with the
patch on x86_64-linux-gnu.

Ready to be installed?
Martin
>From f8934791a3d345eb8c2c51beca07177c75e5f6ac Mon Sep 17 00:00:00 2001
From: marxin 
Date: Tue, 11 Apr 2017 14:22:50 +0200
Subject: [PATCH] Add function part to a same comdat group (PR ipa/80212).

gcc/ChangeLog:

2017-04-11  Martin Liska  

	PR ipa/80212
	* cgraph.c (cgraph_node::dump): Dump calls_comdat_local.
	* ipa-cp.c (determine_versionability): Handle calls_comdat_local
	flags.
	* ipa-split.c (split_function): Create a local comdat symbol
	if caller is in a comdat group.

gcc/testsuite/ChangeLog:

2017-04-11  Martin Liska  

	PR ipa/80212
	* g++.dg/ipa/pr80212.C: New test.
---
 gcc/cgraph.c   |  2 ++
 gcc/ipa-cp.c   |  2 ++
 gcc/ipa-split.c|  7 +++
 gcc/testsuite/g++.dg/ipa/pr80212.C | 18 ++
 4 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr80212.C

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 92ae0910c60..e505b10e211 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2123,6 +2123,8 @@ cgraph_node::dump (FILE *f)
 fprintf (f, " only_called_at_exit");
   if (tm_clone)
 fprintf (f, " tm_clone");
+  if (calls_comdat_local)
+fprintf (f, " calls_comdat_local");
   if (icf_merged)
 fprintf (f, " icf_merged");
   if (merged_comdat)
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 0b408149a88..756a335661d 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -614,6 +614,8 @@ determine_versionability (struct cgraph_node *node,
  decloned constructors, inlining is always better anyway.  */
   else if (node->comdat_local_p ())
 reason = "comdat-local function";
+  else if (node->calls_comdat_local)
+reason = "calls comdat-local function";
 
   if (reason && dump_file && !node->alias && !node->thunk.thunk_p)
 fprintf (dump_file, "Function %s/%i is not versionable, reason: %s.\n",
diff --git a/gcc/ipa-split.c b/gcc/ipa-split.c
index da3c2c62344..8993cae089c 100644
--- a/gcc/ipa-split.c
+++ b/gcc/ipa-split.c
@@ -1360,6 +1360,13 @@ split_function (basic_block return_bb, struct split_point *split_point,
 
   node->split_part = true;
 
+  if (cur_node->same_comdat_group)
+{
+  cur_node->calls_comdat_local = 1;
+  node->add_to_same_comdat_group (cur_node);
+}
+
+
   /* Let's take a time profile for splitted function.  */
   node->tp_first_run = cur_node->tp_first_run + 1;
 
diff --git a/gcc/testsuite/g++.dg/ipa/pr80212.C b/gcc/testsuite/g++.dg/ipa/pr80212.C
new file mode 100644
index 000..60d3b613035
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr80212.C
@@ -0,0 +1,18 @@
+// PR ipa/80212
+// { dg-options "-O2 --param partial-inlining-entry-probability=403796683 -fno-early-inlining" }
+
+struct b
+{
+  virtual b *c () const;
+};
+struct d : virtual b
+{
+};
+struct e : d
+{
+  e *
+  c () const
+  {
+  }
+};
+main () { e a; }
-- 
2.12.2

Re: [PATCH v5] S/390: Optimize atomic_compare_exchange and atomic_compare builtins.

[Dominik Vogt]

On Mon, Mar 27, 2017 at 09:27:35PM +0100, Dominik Vogt wrote:
> The attached patch optimizes the atomic_exchange and
> atomic_compare patterns on s390 and s390x (mostly limited to
> SImode and DImode).  Among general optimizaation, the changes fix
> most of the problems reported in PR 80080:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080
> 
> Bootstrapped and regression tested on a zEC12 with s390 and s390x
> biarch.

v5:
  * Generate LT pattern directly for const 0 value.
  * Split into three patches.

Bootstrapped and regression tested on a zEC12 with s390 and s390x
biarch.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
gcc/ChangeLog-dv-atomic-gcc7-1

* config/s390/s390.md ("cstorecc4"): Use load-on-condition and deal
with CCZmode for TARGET_Z196.
gcc/ChangeLog-dv-atomic-gcc7-2

* config/s390/s390.md (define_peephole2): New peephole to help
combining the load-and-test pattern with volatile memory.
gcc/ChangeLog-dv-atomic-gcc7-3

* s390-protos.h (s390_expand_cs_hqi): Removed.
(s390_expand_cs, s390_expand_atomic_exchange_tdsi): New prototypes.
* config/s390/s390.c (s390_emit_compare_and_swap): Handle all integer
modes as well as CCZ1mode and CCZmode.
(s390_expand_atomic_exchange_tdsi, s390_expand_atomic): Adapt to new
signature of s390_emit_compare_and_swap.
(s390_expand_cs_hqi): Likewise, make static.
(s390_expand_cs_tdsi): Generate an explicit compare before trying
compare-and-swap, in some cases.
(s390_expand_cs): Wrapper function.
(s390_expand_atomic_exchange_tdsi): New backend specific expander for
atomic_exchange.
(s390_match_ccmode_set): Allow CCZmode <-> CCZ1 mode.
* config/s390/s390.md ("atomic_compare_and_swap"): Merge the
patterns for small and large integers.  Forbid symref memory operands.
Move expander to s390.c.  Require cc register.
("atomic_compare_and_swap_internal")
("*atomic_compare_and_swap_1")
("*atomic_compare_and_swapdi_2")
("*atomic_compare_and_swapsi_3"): Use s_operand to forbid
symref memory operands.  Remove CC mode and call s390_match_ccmode
instead.
("atomic_exchange"): Allow and implement all integer modes.
gcc/testsuite/ChangeLog-dv-atomic-gcc7

* gcc.target/s390/md/atomic_compare_exchange-1.c: New test.
* gcc.target/s390/md/atomic_compare_exchange-1.inc: New test.
* gcc.target/s390/md/atomic_exchange-1.inc: New test.
>From fda471edcdea8b86d678514d4fa6cf11745cd2a5 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Mon, 10 Apr 2017 08:29:40 +0100
Subject: [PATCH 1/3] S/390: Use load-on-condition in cstorecc4.

---
 gcc/config/s390/s390.md | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 59f189c..6a1cab6 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -6518,13 +6518,30 @@
   [(parallel
 [(set (match_operand:SI 0 "register_operand" "")
  (match_operator:SI 1 "s390_eqne_operator"
-   [(match_operand:CCZ1 2 "register_operand")
+   [(match_operand 2 "cc_reg_operand")
(match_operand 3 "const0_operand")]))
  (clobber (reg:CC CC_REGNUM))])]
   ""
-  "emit_insn (gen_sne (operands[0], operands[2]));
-   if (GET_CODE (operands[1]) == EQ)
- emit_insn (gen_xorsi3 (operands[0], operands[0], const1_rtx));
+  "machine_mode mode = GET_MODE (operands[2]);
+   if (TARGET_Z196)
+ {
+   rtx cond, ite;
+
+   if (GET_CODE (operands[1]) == NE)
+cond = gen_rtx_NE (VOIDmode, operands[2], const0_rtx);
+   else
+cond = gen_rtx_EQ (VOIDmode, operands[2], const0_rtx);
+   ite = gen_rtx_IF_THEN_ELSE (SImode, cond, const1_rtx, const0_rtx);
+   emit_insn (gen_rtx_SET (operands[0], ite));
+ }
+   else
+ {
+   if (mode != CCZ1mode)
+FAIL;
+   emit_insn (gen_sne (operands[0], operands[2]));
+   if (GET_CODE (operands[1]) == EQ)
+emit_insn (gen_xorsi3 (operands[0], operands[0], const1_rtx));
+ }
DONE;")
 
 (define_insn_and_split "sne"
-- 
2.3.0

>From cf55c86d6c8b7aef1a669c9368410f32f333c59a Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Tue, 11 Apr 2017 12:18:01 +0100
Subject: [PATCH 2/3] S/390: Peephole to merge L followerd by LT.

In some situations this is not done by other optimization passed.
---
 gcc/config/s390/s390.md | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 6a1cab6..9baafcc 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -907,6 +907,21 @@
   [(set_attr "op_type" "RR,RXY")
(set_attr "z10prop" "z10_fr_E1,z10_fwd_A3") ])
 
+; Peephole to combine a load-and-test from volatile memory which combine does
+; not do.
+(define_peephole2
+  [(set (match_operand:GPR 0 "register_operand")
+   (match

Re: [PATCH] Add function part to a same comdat group (PR ipa/80212).

[Jan Hubicka]

> Hello.
> 
> This is my second attempt to fix the PR I worked on with Honza and Martin 
> Jambor.
> 
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests. 
> Apart from that
> octoploid confirmed it can survive LLVM build. And I can build Firefox and 
> boost with the
> patch on x86_64-linux-gnu.
> 
> Ready to be installed?
> Martin

> >From f8934791a3d345eb8c2c51beca07177c75e5f6ac Mon Sep 17 00:00:00 2001
> From: marxin 
> Date: Tue, 11 Apr 2017 14:22:50 +0200
> Subject: [PATCH] Add function part to a same comdat group (PR ipa/80212).
> 
> gcc/ChangeLog:
> 
> 2017-04-11  Martin Liska  
> 
>   PR ipa/80212
>   * cgraph.c (cgraph_node::dump): Dump calls_comdat_local.
>   * ipa-cp.c (determine_versionability): Handle calls_comdat_local
>   flags.
>   * ipa-split.c (split_function): Create a local comdat symbol
>   if caller is in a comdat group.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-04-11  Martin Liska  
> 
>   PR ipa/80212
>   * g++.dg/ipa/pr80212.C: New test.
> ---
>  gcc/cgraph.c   |  2 ++
>  gcc/ipa-cp.c   |  2 ++
>  gcc/ipa-split.c|  7 +++
>  gcc/testsuite/g++.dg/ipa/pr80212.C | 18 ++
>  4 files changed, 29 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/ipa/pr80212.C
> 
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 92ae0910c60..e505b10e211 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -2123,6 +2123,8 @@ cgraph_node::dump (FILE *f)
>  fprintf (f, " only_called_at_exit");
>if (tm_clone)
>  fprintf (f, " tm_clone");
> +  if (calls_comdat_local)
> +fprintf (f, " calls_comdat_local");
>if (icf_merged)
>  fprintf (f, " icf_merged");
>if (merged_comdat)
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index 0b408149a88..756a335661d 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -614,6 +614,8 @@ determine_versionability (struct cgraph_node *node,
>   decloned constructors, inlining is always better anyway.  */
>else if (node->comdat_local_p ())
>  reason = "comdat-local function";
> +  else if (node->calls_comdat_local)
> +reason = "calls comdat-local function";

Perhaps add a comment here that the call is versionable if we make sure that all
callers are inside of the comdat group.
We could improve it later if it becomes important.
>  
>if (reason && dump_file && !node->alias && !node->thunk.thunk_p)
>  fprintf (dump_file, "Function %s/%i is not versionable, reason: %s.\n",
> diff --git a/gcc/ipa-split.c b/gcc/ipa-split.c
> index da3c2c62344..8993cae089c 100644
> --- a/gcc/ipa-split.c
> +++ b/gcc/ipa-split.c
> @@ -1360,6 +1360,13 @@ split_function (basic_block return_bb, struct 
> split_point *split_point,
>  
>node->split_part = true;
>  
> +  if (cur_node->same_comdat_group)
> +{
> +  cur_node->calls_comdat_local = 1;
> +  node->add_to_same_comdat_group (cur_node);
> +}
Also please add a comment here as well.

Otherwise OK.  I would suggest commit the first part (fixing comdat local 
handling) 
first and ipa-split bits incrementally to simplify bisecting we may need to do 
in future
(I hope we won't)

Honza

[RFC] S/390: Alignment peeling prolog generation

[Robin Dapp]

Hi,

when looking at various vectorization examples on s390x I noticed that
we still peel vf/2 iterations for alignment even though vectorization
costs of unaligned loads and stores are the same as normal loads/stores.

A simple example is

void foo(int *restrict a, int *restrict b, unsigned int n)
{
  for (unsigned int i = 0; i < n; i++)
{
  b[i] = a[i] * 2 + 1;
}
}

which gets peeled unless __builtin_assume_aligned (a, 8) is used.

In tree-vect-data-refs.c there are several checks that involve costs  in
the peeling decision none of which seems to suffice in this case. For a
loop with only read DRs there is a check that has been triggering (i.e.
disable peeling) since we implemented the vectorization costs.

Here, we have DR_MISALIGNMENT (dr) == -1 for all DRs but the costs
should still dictate to never peel. I attached a tentative patch for
discussion which fixes the problem by checking the costs for npeel = 0
and npeel = vf/2 after ensuring we support all misalignments. Is there a
better way and place to do it? Are we missing something somewhere else
that would preclude the peeling from happening?

This is not indended for stage 4 obviously :)

Regards
 Robin
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 3fc762a..795c22c 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -1418,6 +1418,7 @@ vect_enhance_data_refs_alignment (loop_vec_info loop_vinfo)
   stmt_vec_info stmt_info;
   unsigned int npeel = 0;
   bool all_misalignments_unknown = true;
+  bool all_misalignments_supported = true;
   unsigned int vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
   unsigned possible_npeel_number = 1;
   tree vectype;
@@ -1547,6 +1548,7 @@ vect_enhance_data_refs_alignment (loop_vec_info loop_vinfo)
 }
 
   all_misalignments_unknown = false;
+
   /* Data-ref that was chosen for the case that all the
  misalignments are unknown is not relevant anymore, since we
  have a data-ref with known alignment.  */
@@ -1609,6 +1611,24 @@ vect_enhance_data_refs_alignment (loop_vec_info loop_vinfo)
   break;
 }
 }
+
+  /* Check if target supports misaligned data access for current data
+	 reference.  */
+  vectype = STMT_VINFO_VECTYPE (stmt_info);
+  machine_mode mode = TYPE_MODE (vectype);
+  if (targetm.vectorize.
+	  support_vector_misalignment (mode, TREE_TYPE (DR_REF (dr)),
+   DR_MISALIGNMENT (dr), false))
+	{
+	  vect_peeling_hash_insert (&peeling_htab, loop_vinfo,
+dr, 0);
+	  /* Also insert vf/2 peeling that will be used when all
+	 misalignments are unknown. */
+	  vect_peeling_hash_insert (&peeling_htab, loop_vinfo,
+dr, vf / 2);
+	}
+  else
+	all_misalignments_supported = false;
 }
 
   /* Check if we can possibly peel the loop.  */
@@ -1687,6 +1707,18 @@ vect_enhance_data_refs_alignment (loop_vec_info loop_vinfo)
 dr0 = first_store;
 }
 
+  /* If the target supports accessing all data references in a misaligned
+	 way, check costs to see if we can leave them unaligned and do not
+	 perform any peeling.  */
+  if (all_misalignments_supported)
+	{
+	  dr0 = vect_peeling_hash_choose_best_peeling (&peeling_htab,
+		   loop_vinfo, &npeel,
+		   &body_cost_vec);
+	  if (!dr0 || !npeel)
+	do_peeling = false;
+	}
+
   /* In case there are only loads with different unknown misalignments, use
  peeling only if it may help to align other accesses in the loop or
 	 if it may help improving load bandwith when we'd end up using

Re: [PATCH, GCC/ARM, gcc-5-branch] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

[Ramana Radhakrishnan]

On 10/04/17 13:12, Thomas Preudhomme wrote:

Hi,

Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
when LPAE extensions is available, which they are not for ARMv7-R. This
commit solve the issue by introducing a new feature bit to distinguish
LPAE extensions instead of deducing it from div instruction
availability.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* config/arm/arm-protos.h (FL_LPAE): Define macro.
(FL_FOR_ARCH7VE): Add FL_LPAE.
(arm_arch_lpae): Declare extern.
* config/arm/arm.c (arm_arch_lpae): Declare.
(arm_option_override): Define arm_arch_lpae.
* config/arm/arm.h (TARGET_HAVE_LPAE): Redefine in term of
arm_arch_lpae.

*** gcc/testsuite/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* gcc.target/arm/atomic_loaddi_10.c: New testcase.
* gcc.target/arm/atomic_loaddi_11.c: Likewise.

Is this ok for gcc-5-branch?


OK.

Ramana



Best regards,

Thomas

On 06/04/17 14:05, Ramana Radhakrishnan wrote:

On Mon, Mar 27, 2017 at 12:15 PM, Thomas Preudhomme
 wrote:

Hi,

Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R,
as shown by the testcase on this patch. However, LDRD is only atomic
when LPAE extensions is available, which they are not for ARMv7-R. This
commit solve the issue by introducing a new feature bit to distinguish
LPAE extensions instead of deducing it from div instruction
availability.



Ok but with the testsuite fix that I just approved,  please also fix
in gcc-5 branch.

Thanks,
Ramana



ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* config/arm/arm-protos.h (FL_LPAE): Define macro.
(FL_FOR_ARCH7VE): Add FL_LPAE.
(arm_arch_lpae): Declare extern.
* config/arm/arm.c (arm_arch_lpae): Declare.
(arm_option_override): Define arm_arch_lpae.
* config/arm/arm.h (TARGET_HAVE_LPAE): Redefine in term of
arm_arch_lpae.

*** gcc/testsuite/ChangeLog ***

2017-03-22  Thomas Preud'homme  

PR target/80082
* gcc.target/arm/atomic_loaddi_10.c: New testcase.
* gcc.target/arm/atomic_loaddi_11.c: Likewise.


Testing: bootstrapped for -march=armv7ve and testsuite shows no
regression.

Is this ok for gcc-6-branch?

Best regards,

Thomas

Re: [patch, libgfortran] Fix pointer declarations per coding standard

[Jerry DeLisle]

On 04/10/2017 11:05 PM, Janne Blomqvist wrote:
> On Tue, Apr 11, 2017 at 7:54 AM, Jerry DeLisle  wrote:
>> All,
>>
>> Attached patch is removing the space after * in many pointer declarations and
>> references in the files in the io sub-directory.
> 
> Hmm, I always considered having a space both before and after the "*"
> in declarations to be an idiosyncratic thing mandated by the GNU style
> guide, but now that I check
> https://www.gnu.org/prep/standards/standards.html#Formatting there is
> in fact no such thing.  Have I got it wrong all these years, or has
> this changed?
> 
> Anyway, good that we can fix this now. Thanks for the patch!
> 

Thanks for the second look. We all just keep working together for the greater 
good.

M   libgfortran/ChangeLog
M   libgfortran/io/close.c
M   libgfortran/io/fbuf.c
M   libgfortran/io/fbuf.h
M   libgfortran/io/format.c
M   libgfortran/io/inquire.c
M   libgfortran/io/intrinsics.c
M   libgfortran/io/list_read.c
M   libgfortran/io/lock.c
M   libgfortran/io/open.c
M   libgfortran/io/read.c
M   libgfortran/io/transfer.c
M   libgfortran/io/unit.c
M   libgfortran/io/unix.c
M   libgfortran/io/unix.h
M   libgfortran/io/write.c
Committed r246842

Re: [RFC] S/390: Alignment peeling prolog generation

[Bin.Cheng]

On Tue, Apr 11, 2017 at 3:38 PM, Robin Dapp  wrote:
> Hi,
>
> when looking at various vectorization examples on s390x I noticed that
> we still peel vf/2 iterations for alignment even though vectorization
> costs of unaligned loads and stores are the same as normal loads/stores.
>
> A simple example is
>
> void foo(int *restrict a, int *restrict b, unsigned int n)
> {
>   for (unsigned int i = 0; i < n; i++)
> {
>   b[i] = a[i] * 2 + 1;
> }
> }
>
> which gets peeled unless __builtin_assume_aligned (a, 8) is used.
>
> In tree-vect-data-refs.c there are several checks that involve costs  in
> the peeling decision none of which seems to suffice in this case. For a
> loop with only read DRs there is a check that has been triggering (i.e.
> disable peeling) since we implemented the vectorization costs.
>
> Here, we have DR_MISALIGNMENT (dr) == -1 for all DRs but the costs
> should still dictate to never peel. I attached a tentative patch for
> discussion which fixes the problem by checking the costs for npeel = 0
> and npeel = vf/2 after ensuring we support all misalignments. Is there a
> better way and place to do it? Are we missing something somewhere else
> that would preclude the peeling from happening?
>
> This is not indended for stage 4 obviously :)
Hi Robin,
Seems Richi added code like below comparing costs between aligned and
unsigned loads, and only peeling if it's beneficial:

  /* In case there are only loads with different unknown misalignments, use
 peeling only if it may help to align other accesses in the loop or
 if it may help improving load bandwith when we'd end up using
 unaligned loads.  */
  tree dr0_vt = STMT_VINFO_VECTYPE (vinfo_for_stmt (DR_STMT (dr0)));
  if (!first_store
  && !STMT_VINFO_SAME_ALIGN_REFS (
  vinfo_for_stmt (DR_STMT (dr0))).length ()
  && (vect_supportable_dr_alignment (dr0, false)
  != dr_unaligned_supported
  || (builtin_vectorization_cost (vector_load, dr0_vt, 0)
  == builtin_vectorization_cost (unaligned_load, dr0_vt, -1
do_peeling = false;

I think similar codes can be added for store cases too.

Thanks,
bin
>
> Regards
>  Robin

[arm] PR 80389 - if architecture and cpu mismatch, don't print an architecture name as a CPU name

[Richard Earnshaw (lists)]

In this PR we incorrectly print the architecture name in a .cpu
directive in the assembly file when the -mcpu and -march options
conflict (don't target the same base architecture).  In this case the
.arch overrides the .cpu directive and we should emit a .arch option.

Fixed thusly.

PR target/80389
* config/arm/arm.c (arm_configure_build_target): When -mcpu and -arch
conflict, set target->arch_name instead of target->cpu_name.

Tested on a cross compiler with no problems.  I'm doing a full bootstrap
as well, but that's very unlikely to hit this scenario, so committed anyway.

R.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 511e163..f04deed 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3098,15 +3098,15 @@ arm_configure_build_target (struct arm_build_target 
*target,
arm_selected_tune = arm_selected_cpu;
 
  arm_selected_cpu = arm_selected_arch;
+ target->arch_name = arm_selected_arch->name;
}
  else
{
  /* Architecture and CPU are essentially the same.
 Prefer the CPU setting.  */
  arm_selected_arch = NULL;
+ target->core_name = arm_selected_cpu->name;
}
-
- target->core_name = arm_selected_cpu->name;
}
   else
{

Re: [RFC] S/390: Alignment peeling prolog generation

[Robin Dapp]

Hi Bin,

> Seems Richi added code like below comparing costs between aligned and
> unsigned loads, and only peeling if it's beneficial:
> 
>   /* In case there are only loads with different unknown misalignments, 
> use
>  peeling only if it may help to align other accesses in the loop or
>  if it may help improving load bandwith when we'd end up using
>  unaligned loads.  */
>   tree dr0_vt = STMT_VINFO_VECTYPE (vinfo_for_stmt (DR_STMT (dr0)));
>   if (!first_store
>   && !STMT_VINFO_SAME_ALIGN_REFS (
>   vinfo_for_stmt (DR_STMT (dr0))).length ()
>   && (vect_supportable_dr_alignment (dr0, false)
>   != dr_unaligned_supported
>   || (builtin_vectorization_cost (vector_load, dr0_vt, 0)
>   == builtin_vectorization_cost (unaligned_load, dr0_vt, -1
> do_peeling = false;

yes this is the "special case" I was referring to. This successfully
avoids peeling when there is no store (after we had set vectorization
costs). My patch tries to check the costs for all references.

Regards
 Robin

Re: [RFC] S/390: Alignment peeling prolog generation

[Bin.Cheng]

On Tue, Apr 11, 2017 at 4:03 PM, Robin Dapp  wrote:
> Hi Bin,
>
>> Seems Richi added code like below comparing costs between aligned and
>> unsigned loads, and only peeling if it's beneficial:
>>
>>   /* In case there are only loads with different unknown misalignments, 
>> use
>>  peeling only if it may help to align other accesses in the loop or
>>  if it may help improving load bandwith when we'd end up using
>>  unaligned loads.  */
>>   tree dr0_vt = STMT_VINFO_VECTYPE (vinfo_for_stmt (DR_STMT (dr0)));
>>   if (!first_store
>>   && !STMT_VINFO_SAME_ALIGN_REFS (
>>   vinfo_for_stmt (DR_STMT (dr0))).length ()
>>   && (vect_supportable_dr_alignment (dr0, false)
>>   != dr_unaligned_supported
>>   || (builtin_vectorization_cost (vector_load, dr0_vt, 0)
>>   == builtin_vectorization_cost (unaligned_load, dr0_vt, -1
>> do_peeling = false;
>
> yes this is the "special case" I was referring to. This successfully
> avoids peeling when there is no store (after we had set vectorization
> costs). My patch tries to check the costs for all references.
I am not sure if all references need to be checked, on AArch64,
aligned/unaligned costs are set globally, so only need to make one
check here.

Thanks,
bin
>
> Regards
>  Robin
>

Re: [PATCH 0/3] ARC patches series

[Andrew Burgess]

* Claudiu Zissulescu  [2017-04-04 11:58:58 
+0200]:

> Hi Andrew,
> 
> Please find a number of small patches which are adding support to for CRT 
> long calls, and fixes some errors when generating dwarf information and 
> addresses.
> 
> Please let me know if more info is required,
> Claudiu
> 
> Claudiu Zissulescu (3):
>   [ARC] Update mode_dependent_address_p hook.
>   [ARC] DWARF emitting cleanup.
>   [ARC] Use long jumps for CRT calls

These all look fine.

Thanks,
Andrew


> 
>  gcc/config/arc/arc-protos.h |  1 -
>  gcc/config/arc/arc.c| 19 ++-
>  gcc/config/arc/arc.h| 14 +-
>  3 files changed, 7 insertions(+), 27 deletions(-)
> 
> -- 
> 1.9.1
> 

Re: One more path to fix PR70478

[Vladimir Makarov]

On 04/11/2017 03:30 AM, Christophe Lyon wrote:

Hi Vladimir,

On 10 April 2017 at 17:05, Vladimir Makarov  wrote:

   This is the second try to fix

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

   The first try patch triggered a latent bug and broke one Fortran testcase
on x86-64.

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

   Committed as rev. 246808.



I would have to re--run the build/test manually to get the generated
code, let me know if it's needed.
Yes, Christophe.  It would be helpful.  I've tried to reproduce it but I 
don't see the difference in the generated code.

Re: [RFC] S/390: Alignment peeling prolog generation

[Richard Biener]

On April 11, 2017 4:57:29 PM GMT+02:00, "Bin.Cheng"  
wrote:
>On Tue, Apr 11, 2017 at 3:38 PM, Robin Dapp 
>wrote:
>> Hi,
>>
>> when looking at various vectorization examples on s390x I noticed
>that
>> we still peel vf/2 iterations for alignment even though vectorization
>> costs of unaligned loads and stores are the same as normal
>loads/stores.
>>
>> A simple example is
>>
>> void foo(int *restrict a, int *restrict b, unsigned int n)
>> {
>>   for (unsigned int i = 0; i < n; i++)
>> {
>>   b[i] = a[i] * 2 + 1;
>> }
>> }
>>
>> which gets peeled unless __builtin_assume_aligned (a, 8) is used.
>>
>> In tree-vect-data-refs.c there are several checks that involve costs 
>in
>> the peeling decision none of which seems to suffice in this case. For
>a
>> loop with only read DRs there is a check that has been triggering
>(i.e.
>> disable peeling) since we implemented the vectorization costs.
>>
>> Here, we have DR_MISALIGNMENT (dr) == -1 for all DRs but the costs
>> should still dictate to never peel. I attached a tentative patch for
>> discussion which fixes the problem by checking the costs for npeel =
>0
>> and npeel = vf/2 after ensuring we support all misalignments. Is
>there a
>> better way and place to do it? Are we missing something somewhere
>else
>> that would preclude the peeling from happening?
>>
>> This is not indended for stage 4 obviously :)
>Hi Robin,
>Seems Richi added code like below comparing costs between aligned and
>unsigned loads, and only peeling if it's beneficial:
>
>/* In case there are only loads with different unknown misalignments,
>use
> peeling only if it may help to align other accesses in the loop or
> if it may help improving load bandwith when we'd end up using
> unaligned loads.  */
> tree dr0_vt = STMT_VINFO_VECTYPE (vinfo_for_stmt (DR_STMT (dr0)));
>  if (!first_store
>  && !STMT_VINFO_SAME_ALIGN_REFS (
>  vinfo_for_stmt (DR_STMT (dr0))).length ()
>  && (vect_supportable_dr_alignment (dr0, false)
>  != dr_unaligned_supported
>  || (builtin_vectorization_cost (vector_load, dr0_vt, 0)
>  == builtin_vectorization_cost (unaligned_load, dr0_vt, -1
>do_peeling = false;
>
>I think similar codes can be added for store cases too.

Note I was very conservative here to allow store bandwidth starved CPUs to 
benefit from aligning a store.

I think it would be reasonable to apply the same heuristic to the store case 
that we only peel for same cost if peeling would at least align two refs.

Richard.

>Thanks,
>bin
>>
>> Regards
>>  Robin

Re: One more path to fix PR70478

[Christophe Lyon]

On 11 April 2017 at 17:42, Vladimir Makarov  wrote:
>
>
> On 04/11/2017 03:30 AM, Christophe Lyon wrote:
>>
>> Hi Vladimir,
>>
>> On 10 April 2017 at 17:05, Vladimir Makarov  wrote:
>>>
>>>This is the second try to fix
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
>>>
>>>The first try patch triggered a latent bug and broke one Fortran
>>> testcase
>>> on x86-64.
>>>
>>>The patch was successfully bootstrapped on x86-64 and tested on
>>> x86-64,
>>> ppc64, and aarch64.
>>>
>>>Committed as rev. 246808.
>>>
>>>
>> I would have to re--run the build/test manually to get the generated
>> code, let me know if it's needed.
>
> Yes, Christophe.  It would be helpful.  I've tried to reproduce it but I
> don't see the difference in the generated code.
>

Here is what I observed (the "with-patch file is with your commit r246808,
the other is r246807)

--- armv8_2-fp16-move-1.s   2017-04-11 16:23:46.795264234 +
+++ armv8_2-fp16-move-1.s.with-patch2017-04-11 15:54:52.563210963 +
@@ -37,8 +37,8 @@
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
lsl r1, r1, #1
-   add r3, r0, r1
-   vld1.16 {d0[0]}, [r3]
+   ldrhr3, [r0, r1]@ __fp16
+   vmov.f16s0, r3  @ __fp16
bx  lr
.size   test_load_2, .-test_load_2
.align  2
@@ -64,9 +64,9 @@
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
+   vmov.f16r3, s0  @ __fp16
lsl r1, r1, #1
-   add r3, r0, r1
-   vst1.16 {d0[0]}, [r3]
+   strhr3, [r0, r1]@ __fp16
bx  lr
.size   test_store_2, .-test_store_2
.align  2


Christophe

Re: One more path to fix PR70478

[Ramana Radhakrishnan]

On Tue, Apr 11, 2017 at 5:26 PM, Christophe Lyon
 wrote:
> On 11 April 2017 at 17:42, Vladimir Makarov  wrote:
>>
>>
>> On 04/11/2017 03:30 AM, Christophe Lyon wrote:
>>>
>>> Hi Vladimir,
>>>
>>> On 10 April 2017 at 17:05, Vladimir Makarov  wrote:

This is the second try to fix

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

The first try patch triggered a latent bug and broke one Fortran
 testcase
 on x86-64.

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

Committed as rev. 246808.


>>> I would have to re--run the build/test manually to get the generated
>>> code, let me know if it's needed.
>>
>> Yes, Christophe.  It would be helpful.  I've tried to reproduce it but I
>> don't see the difference in the generated code.
>>
>
> Here is what I observed (the "with-patch file is with your commit r246808,
> the other is r246807)
>
> --- armv8_2-fp16-move-1.s   2017-04-11 16:23:46.795264234 +
> +++ armv8_2-fp16-move-1.s.with-patch2017-04-11 15:54:52.563210963 +
> @@ -37,8 +37,8 @@
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> lsl r1, r1, #1
> -   add r3, r0, r1
> -   vld1.16 {d0[0]}, [r3]
> +   ldrhr3, [r0, r1]@ __fp16
> +   vmov.f16s0, r3  @ __fp16
> bx  lr
> .size   test_load_2, .-test_load_2
> .align  2
> @@ -64,9 +64,9 @@
> @ args = 0, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> +   vmov.f16r3, s0  @ __fp16
> lsl r1, r1, #1
> -   add r3, r0, r1
> -   vst1.16 {d0[0]}, [r3]
> +   strhr3, [r0, r1]@ __fp16
> bx  lr
> .size   test_store_2, .-test_store_2
> .align  2
>

That's actually bad because we've now introduced additional moves
between the integer and FP register files. It could be something in
the backend but this is worth investigating further

Ramana

>
> Christophe

Re: [PATCH] avoid using types wider than int for width and precision (PR 80364)

[Martin Sebor]

   if (TREE_CODE (arg) == SSA_NAME
- && TREE_CODE (type) == INTEGER_TYPE)
+ && TREE_CODE (argtype) == INTEGER_TYPE


I think you want
  && INTEGRAL_TYPE_P (argtype)
here instead of that last line, the middle-end considers conversions between
integral types useless (except for bool vs. non-bool conversions if the
other type has precision != 1), so if one does:
enum E { E0 = -__INT_MAX__ - 1, E1 = 1, E2 = 2, E3 = 3, E4 = __INT_MAX__ };
  enum E e = ...;
  snprintf (... "...%.*s...", ..., e, ...);
then you could very well have there ENUMERAL_TYPE etc.


That's right.  I keep forgetting about this.  Thanks.



Ok for trunk with that change.


I committed r246846 with an additional change to make enums work
correctly.

Martin

Re: port contrib/download_prerequisites script to macOS

[Jerry DeLisle]

On 04/10/2017 11:59 AM, Damian Rouson wrote:

Thanks!  I'm asking Jerry to commit it.

Damian

On April 10, 2017 at 9:48:01 AM, Mike Stump (mikest...@comcast.net
) wrote:


On Apr 4, 2017, at 6:10 PM, Damian Rouson  wrote:
>
> The attached patch modifies the contrib/download_prerequisites script to work 
on macOS.

> Ok for trunk?

Don't know if others would prefer to review... assuming no strong feelings
against...

Ok.



No objections noted.

M   contrib/ChangeLog
M   contrib/download_prerequisites
Committed r246845

Thanks all,

Jerry

[C++ PATCH] Fix decomp ICEs in templates (PR c++/80370, take 3)

[Jakub Jelinek]

On Tue, Apr 11, 2017 at 03:41:39PM +0200, Jakub Jelinek wrote:
> So like this?  Or just type_dependent_expression_p check rather than
> both?

To answer myself, testing there both type_dependent_expression_p
and value_dependent_expression_p for value_expr breaks
the lambda-generic-const2.C testcase.  So I'll test this instead:

2017-04-11  Jakub Jelinek  

PR c++/80370
* decl.c (cp_finish_decomp): If processing_template_decl on
non-dependent decl, only set TREE_TYPE on the v[i] decls, but don't
change their DECL_VALUE_EXPR nor cp_finish_decl them.  Instead make
sure DECL_VALUE_EXPR is the canonical NULL type ARRAY_REF for tsubst
processing.
* pt.c (value_dependent_expression_p) : For variables
with DECL_VALUE_EXPR, return true if DECL_VALUE_EXPR is type
dependent.

* g++.dg/cpp1z/decomp28.C: New test.

--- gcc/cp/decl.c.jj2017-04-10 22:26:56.441388051 +0200
+++ gcc/cp/decl.c   2017-04-11 15:21:24.473163169 +0200
@@ -7473,6 +7473,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  t = build4_loc (DECL_SOURCE_LOCATION (v[i]), ARRAY_REF,
  eltype, t, size_int (i), NULL_TREE,
@@ -7492,6 +7494,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  t = build1_loc (DECL_SOURCE_LOCATION (v[i]),
  i ? IMAGPART_EXPR : REALPART_EXPR, eltype,
@@ -7510,6 +7514,8 @@ cp_finish_decomp (tree decl, tree first,
{
  TREE_TYPE (v[i]) = eltype;
  layout_decl (v[i], 0);
+ if (processing_template_decl)
+   continue;
  tree t = unshare_expr (dexp);
  convert_vector_to_array_for_subscript (DECL_SOURCE_LOCATION (v[i]),
 &t, size_int (i));
@@ -7559,8 +7565,9 @@ cp_finish_decomp (tree decl, tree first,
  SET_DECL_VALUE_EXPR (v[i], NULL_TREE);
  DECL_HAS_VALUE_EXPR_P (v[i]) = 0;
}
- cp_finish_decl (v[i], init, /*constexpr*/false,
- /*asm*/NULL_TREE, LOOKUP_NORMAL);
+ if (!processing_template_decl)
+   cp_finish_decl (v[i], init, /*constexpr*/false,
+   /*asm*/NULL_TREE, LOOKUP_NORMAL);
}
 }
   else if (TREE_CODE (type) == UNION_TYPE)
@@ -7615,12 +7622,26 @@ cp_finish_decomp (tree decl, tree first,
  tt = TREE_OPERAND (tt, 0);
TREE_TYPE (v[i]) = TREE_TYPE (tt);
layout_decl (v[i], 0);
-   SET_DECL_VALUE_EXPR (v[i], tt);
-   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+   if (!processing_template_decl)
+ {
+   SET_DECL_VALUE_EXPR (v[i], tt);
+   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+ }
i++;
  }
 }
-  if (DECL_NAMESPACE_SCOPE_P (decl))
+  if (processing_template_decl)
+{
+  for (unsigned int i = 0; i < count; i++)
+   if (!DECL_HAS_VALUE_EXPR_P (v[i]))
+ {
+   tree a = build_nt (ARRAY_REF, decl, size_int (i),
+  NULL_TREE, NULL_TREE);
+   SET_DECL_VALUE_EXPR (v[i], a);
+   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
+ }
+}
+  else if (DECL_NAMESPACE_SCOPE_P (decl))
 SET_DECL_ASSEMBLER_NAME (decl, mangle_decomp (decl, v));
 }
 
--- gcc/cp/pt.c.jj  2017-04-11 19:06:52.871624849 +0200
+++ gcc/cp/pt.c 2017-04-11 19:10:39.795803274 +0200
@@ -23576,6 +23576,12 @@ value_dependent_expression_p (tree expre
  || type_dependent_expression_p (DECL_INITIAL (expression))
  || value_dependent_expression_p (DECL_INITIAL (expression
return true;
+  if (DECL_HAS_VALUE_EXPR_P (expression))
+   {
+ tree value_expr = DECL_VALUE_EXPR (expression);
+ if (type_dependent_expression_p (value_expr))
+   return true;
+   }
   return false;
 
 case DYNAMIC_CAST_EXPR:
--- gcc/testsuite/g++.dg/cpp1z/decomp28.C.jj2017-04-11 15:21:24.473163169 
+0200
+++ gcc/testsuite/g++.dg/cpp1z/decomp28.C   2017-04-11 15:21:24.473163169 
+0200
@@ -0,0 +1,39 @@
+// PR c++/80370
+// { dg-do compile { target c++14 } }
+// { dg-options "" }
+
+namespace std {
+  template  struct tuple_size;
+  template  struct tuple_element;
+  template  struct tuple {};
+  template  struct tuple_size> { static constexpr 
int value = 1; };
+  template  struct tuple_element<0, tuple> 
{ typedef T type; };
+  template  int& get (tuple);
+}
+
+template 
+void
+foo (std::tuple b)
+{
+  auto [c] = b;// { dg-warning "decomposition declaration only 
available with" "" { target c++14_down } }
+}
+
+t

[committed] Don't optimize away OpenMP tasks with empty bodies, but with depend clauses (PR libgomp/80394)

[Jakub Jelinek]

Hi!

Tasks that have depend clauses can't be optimized away even if they
have empty body, the depend clause still has important side-effects.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk, queued for backporting.

2017-04-11  Jakub Jelinek  

PR libgomp/80394
* omp-low.c (scan_omp_task): Don't optimize away empty tasks
if they have any depend clauses.

* testsuite/libgomp.c/pr80394.c: New test.

--- gcc/omp-low.c.jj2017-03-29 07:11:14.0 +0200
+++ gcc/omp-low.c   2017-04-11 15:17:32.608077934 +0200
@@ -1857,9 +1857,11 @@ scan_omp_task (gimple_stmt_iterator *gsi
   tree name, t;
   gomp_task *stmt = as_a  (gsi_stmt (*gsi));
 
-  /* Ignore task directives with empty bodies.  */
+  /* Ignore task directives with empty bodies, unless they have depend
+ clause.  */
   if (optimize > 0
-  && empty_body_p (gimple_omp_body (stmt)))
+  && empty_body_p (gimple_omp_body (stmt))
+  && !omp_find_clause (gimple_omp_task_clauses (stmt), OMP_CLAUSE_DEPEND))
 {
   gsi_replace (gsi, gimple_build_nop (), false);
   return;
--- libgomp/testsuite/libgomp.c/pr80394.c.jj2017-04-11 15:14:18.783514493 
+0200
+++ libgomp/testsuite/libgomp.c/pr80394.c   2017-04-11 15:13:56.460795111 
+0200
@@ -0,0 +1,22 @@
+/* PR libgomp/80394 */
+
+int
+main ()
+{
+  int x = 0;
+  #pragma omp parallel shared(x)
+  #pragma omp single
+  {
+#pragma omp task depend(inout: x)
+{
+  for (int i = 0; i < 10; i++)
+asm volatile ("" : : : "memory");
+  x += 5;
+}
+#pragma omp task if (0) depend(inout: x)
+;
+if (x != 5)
+  __builtin_abort ();
+  }
+  return 0;
+}

Jakub

[committed] Fix UB in simplify-rtx.c (PR middle-end/80100)

[Jakub Jelinek]

Hi!

The following testcase triggers UB in simplify_binary_operation_1,
in particular trueop1 is 2 and it is shifted up by 63.  Later we want
to shift it down (arithmetically) again by 63 and compare against the
original value and only optimize if there is match, i.e. if trueop1
can be safely shifted up.  In cases it can't we don't want to trigger
UB, so the following patch just uses unsigned shift that is well defined
and then implementation defined conversion to signed type we rely on
everywhere.  We still want mask to be signed so that the right shift
is arithmetic.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.

2017-04-11  Jakub Jelinek  

PR middle-end/80100
* simplify-rtx.c (simplify_binary_operation_1) : Perform
left shift in unsigned HOST_WIDE_INT type.

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

--- gcc/simplify-rtx.c.jj   2017-04-11 16:09:22.003071899 +0200
+++ gcc/simplify-rtx.c  2017-04-11 16:01:44.350830295 +0200
@@ -2741,8 +2741,8 @@ simplify_binary_operation_1 (enum rtx_co
   && CONST_INT_P (XEXP (op0, 1))
   && INTVAL (XEXP (op0, 1)) < HOST_BITS_PER_WIDE_INT)
 {
-  int count = INTVAL (XEXP (op0, 1));
-  HOST_WIDE_INT mask = INTVAL (trueop1) << count;
+ int count = INTVAL (XEXP (op0, 1));
+ HOST_WIDE_INT mask = UINTVAL (trueop1) << count;
 
   if (mask >> count == INTVAL (trueop1)
  && trunc_int_for_mode (mask, mode) == mask
--- gcc/testsuite/gcc.dg/pr80100.c.jj   2017-04-11 16:22:42.706047192 +0200
+++ gcc/testsuite/gcc.dg/pr80100.c  2017-04-11 16:22:29.0 +0200
@@ -0,0 +1,9 @@
+/* PR middle-end/80100 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+long int
+foo (long int x)
+{
+  return 2L | ((x - 1L) >> (__SIZEOF_LONG__ * __CHAR_BIT__ - 1));
+}

Jakub

Re: One more path to fix PR70478

[Vladimir Makarov]

On 04/11/2017 11:42 AM, Vladimir Makarov wrote:



Yes, Christophe.  It would be helpful.  I've tried to reproduce it but 
I don't see the difference in the generated code.



Never mind.  I've reproduced it.  Thanks.

[PATCH, GCC, stage4] Fix type for .init_array.* and .fini_array.* sections

[Thomas Preudhomme]

Hi,

Several tests started failing for ARM targets (eg. gcc.dg/initpri1.c)
after change 6f9dbcd42f2cf034a9a21f46842c08d2e88449db in binutils. This
is because the non-default priority init_array and fini_array sections
are not created with NOTYPE flag as is the case for default priority
init_array and fini_array sections (see default_section_type_flags in
varasm.c for instance). This patch fixes the issue.

ChangeLog entry is as follows:

*** gcc/ChangeLog ***

2017-04-11  Thomas Preud'homme  

* config/arm/arm.c (arm_elf_asm_cdtor): Create non-default
priority .init_array and .fini_array section with SECTION_NOTYPE
flag.

Testing: with this patch test gcc.dg/initpri1.c succeeds but fails
without.

Is this ok for stage4?

Best regards,

Thomas
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index a2d80cfd645928fb8b3178a8e0c7173adce5d598..f3a6b64b16896e82d6e7a66726a929f0572542d9 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -22593,7 +22593,7 @@ arm_elf_asm_cdtor (rtx symbol, int priority, bool is_ctor)
   sprintf (buf, "%s.%.5u",
 	   is_ctor ? ".init_array" : ".fini_array",
 	   priority);
-  s = get_section (buf, SECTION_WRITE, NULL_TREE);
+  s = get_section (buf, SECTION_WRITE | SECTION_NOTYPE, NULL_TREE);
 }
   else if (is_ctor)
 s = ctors_section;

Re: [C++ PATCH] Fix decomp ICEs in templates (PR c++/80370, take 3)

[Jason Merrill]

OK.

On Tue, Apr 11, 2017 at 1:13 PM, Jakub Jelinek  wrote:
> On Tue, Apr 11, 2017 at 03:41:39PM +0200, Jakub Jelinek wrote:
>> So like this?  Or just type_dependent_expression_p check rather than
>> both?
>
> To answer myself, testing there both type_dependent_expression_p
> and value_dependent_expression_p for value_expr breaks
> the lambda-generic-const2.C testcase.  So I'll test this instead:
>
> 2017-04-11  Jakub Jelinek  
>
> PR c++/80370
> * decl.c (cp_finish_decomp): If processing_template_decl on
> non-dependent decl, only set TREE_TYPE on the v[i] decls, but don't
> change their DECL_VALUE_EXPR nor cp_finish_decl them.  Instead make
> sure DECL_VALUE_EXPR is the canonical NULL type ARRAY_REF for tsubst
> processing.
> * pt.c (value_dependent_expression_p) : For variables
> with DECL_VALUE_EXPR, return true if DECL_VALUE_EXPR is type
> dependent.
>
> * g++.dg/cpp1z/decomp28.C: New test.
>
> --- gcc/cp/decl.c.jj2017-04-10 22:26:56.441388051 +0200
> +++ gcc/cp/decl.c   2017-04-11 15:21:24.473163169 +0200
> @@ -7473,6 +7473,8 @@ cp_finish_decomp (tree decl, tree first,
> {
>   TREE_TYPE (v[i]) = eltype;
>   layout_decl (v[i], 0);
> + if (processing_template_decl)
> +   continue;
>   tree t = unshare_expr (dexp);
>   t = build4_loc (DECL_SOURCE_LOCATION (v[i]), ARRAY_REF,
>   eltype, t, size_int (i), NULL_TREE,
> @@ -7492,6 +7494,8 @@ cp_finish_decomp (tree decl, tree first,
> {
>   TREE_TYPE (v[i]) = eltype;
>   layout_decl (v[i], 0);
> + if (processing_template_decl)
> +   continue;
>   tree t = unshare_expr (dexp);
>   t = build1_loc (DECL_SOURCE_LOCATION (v[i]),
>   i ? IMAGPART_EXPR : REALPART_EXPR, eltype,
> @@ -7510,6 +7514,8 @@ cp_finish_decomp (tree decl, tree first,
> {
>   TREE_TYPE (v[i]) = eltype;
>   layout_decl (v[i], 0);
> + if (processing_template_decl)
> +   continue;
>   tree t = unshare_expr (dexp);
>   convert_vector_to_array_for_subscript (DECL_SOURCE_LOCATION (v[i]),
>  &t, size_int (i));
> @@ -7559,8 +7565,9 @@ cp_finish_decomp (tree decl, tree first,
>   SET_DECL_VALUE_EXPR (v[i], NULL_TREE);
>   DECL_HAS_VALUE_EXPR_P (v[i]) = 0;
> }
> - cp_finish_decl (v[i], init, /*constexpr*/false,
> - /*asm*/NULL_TREE, LOOKUP_NORMAL);
> + if (!processing_template_decl)
> +   cp_finish_decl (v[i], init, /*constexpr*/false,
> +   /*asm*/NULL_TREE, LOOKUP_NORMAL);
> }
>  }
>else if (TREE_CODE (type) == UNION_TYPE)
> @@ -7615,12 +7622,26 @@ cp_finish_decomp (tree decl, tree first,
>   tt = TREE_OPERAND (tt, 0);
> TREE_TYPE (v[i]) = TREE_TYPE (tt);
> layout_decl (v[i], 0);
> -   SET_DECL_VALUE_EXPR (v[i], tt);
> -   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
> +   if (!processing_template_decl)
> + {
> +   SET_DECL_VALUE_EXPR (v[i], tt);
> +   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
> + }
> i++;
>   }
>  }
> -  if (DECL_NAMESPACE_SCOPE_P (decl))
> +  if (processing_template_decl)
> +{
> +  for (unsigned int i = 0; i < count; i++)
> +   if (!DECL_HAS_VALUE_EXPR_P (v[i]))
> + {
> +   tree a = build_nt (ARRAY_REF, decl, size_int (i),
> +  NULL_TREE, NULL_TREE);
> +   SET_DECL_VALUE_EXPR (v[i], a);
> +   DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
> + }
> +}
> +  else if (DECL_NAMESPACE_SCOPE_P (decl))
>  SET_DECL_ASSEMBLER_NAME (decl, mangle_decomp (decl, v));
>  }
>
> --- gcc/cp/pt.c.jj  2017-04-11 19:06:52.871624849 +0200
> +++ gcc/cp/pt.c 2017-04-11 19:10:39.795803274 +0200
> @@ -23576,6 +23576,12 @@ value_dependent_expression_p (tree expre
>   || type_dependent_expression_p (DECL_INITIAL (expression))
>   || value_dependent_expression_p (DECL_INITIAL (expression
> return true;
> +  if (DECL_HAS_VALUE_EXPR_P (expression))
> +   {
> + tree value_expr = DECL_VALUE_EXPR (expression);
> + if (type_dependent_expression_p (value_expr))
> +   return true;
> +   }
>return false;
>
>  case DYNAMIC_CAST_EXPR:
> --- gcc/testsuite/g++.dg/cpp1z/decomp28.C.jj2017-04-11 15:21:24.473163169 
> +0200
> +++ gcc/testsuite/g++.dg/cpp1z/decomp28.C   2017-04-11 15:21:24.473163169 
> +0200
> @@ -0,0 +1,39 @@
> +// PR c++/80370
> +// { dg-do compile { target c++14 } }
> +// { dg-options "" }
> +
> +namespace std {
> +  template  struct tuple_size;
> +  template  struct tuple_element;
> +  template  struct tuple {};
> +  template  struct tuple_size> { static constexpr

Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Jason Merrill]

On Tue, Apr 11, 2017 at 9:35 AM, Richard Biener  wrote:
> On Tue, 11 Apr 2017, Richard Biener wrote:
>
>> On Tue, 11 Apr 2017, Richard Biener wrote:
>>
>> > On Mon, 10 Apr 2017, Jason Merrill wrote:
>> >
>> > > On Mon, Apr 10, 2017 at 11:30 AM, Richard Biener  
>> > > wrote:
>> > > > On Mon, 10 Apr 2017, Jason Merrill wrote:
>> > > >> On Mon, Apr 10, 2017 at 8:50 AM, Richard Biener  
>> > > >> wrote:
>> > > >> > * tree.c (build_cplus_array_type): Set TYPE_TYPELESS_STORAGE
>> > > >> > for arrays of unsigned char or std::byte.
>> > > >>
>> > > >> I think it would be good to have a flag to select whether these
>> > > >> semantics apply to any char variant and std::byte, only unsigned char
>> > > >> and std::byte, or only std::byte.
>> > > >
>> > > > Any suggestion?  Not sure we really need it (I'm hesitant to write
>> > > > all the testcases to verify it actually works).
>> > >
>> > > Well, there's existing code that uses plain char (e.g. boost) that I
>> > > want to support.  If there's a significant optimization penalty for
>> > > allowing that, we probably also want to be able to limit the impact.
>> > > If there isn't much penalty, let's just support all char variants.
>> >
>> > I haven't assessed the penalty involved but it can't be worse than
>> > the situation we had in GCC 6.  So I think it's reasonable to support
>> > all char variants for now.  One could add some instrumenting to
>> > alias_set_subset_of / alias_sets_conflict_p but it would only yield
>> > an upper bound on the number of failed queries (TBAA is a quite early
>> > out before PTA info is used for example).
>> >
>> > The following variant -- added missing
>> >
>> > Index: gcc/cp/tree.c
>> > ===
>> > --- gcc/cp/tree.c   (revision 246832)
>> > +++ gcc/cp/tree.c   (working copy)
>> > @@ -972,6 +979,7 @@ build_cplus_array_type (tree elt_type, t
>> >  as it will overwrite alignment etc. of all variants.  */
>> >   TYPE_SIZE (t) = TYPE_SIZE (m);
>> >   TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (m);
>> > + TYPE_TYPELESS_STORAGE (t) = TYPE_TYPELESS_STORAGE (m);
>> > }
>> >
>> >   TYPE_MAIN_VARIANT (t) = m;
>> >
>> > that caused LTO bootstrap to fail and removed the tree-ssa-structalias.c
>> > change (committed separately) [LTO] bootstrapped and tested ok on
>> > x86_64-unknown-linux-gnu.
>> >
>> > I've tested some template examples and they seem to work fine.
>> >
>> > Ok for trunk?
>> >
>> > Disclaimer: there might still be an issue with cross-language LTO
>> > support, but it might at most result in TYPE_TYPELESS_STORAGE
>> > getting lost.  Trying to craft a testcase to verify my theory.
>>
>> Not too difficult in the end (see below).  A fix (below) is to
>> not treat arrays with differing TYPE_TYPELESS_STORAGE as
>> compatible for the purpose of computing TYPE_CANONICAL (and
>> thus recursively structures containing them).  While they'd
>> still alias each other (because currently a TYPE_TYPELESS_STORAGE
>> member makes the whole thing effectively alias anything) this
>> results in warnings in case such a type is used in the interface
>> between C and C++ (it's also considered a ODR type).
>>
>> t.C:17:17: warning: type of ‘bar’ does not match original declaration
>> [-Wlto-type-mismatch]
>>  extern "C" void bar (X *);
>>  ^
>> t2.c:5:6: note: ‘bar’ was previously declared here
>>  void bar (struct X *p) {}
>>   ^
>>
>> if you add a struct X * parameter to bar().
>>
>> So it's not the optimal solution here.  Another fix would be to
>> somehow make TYPE_TYPELESS_STORAGE "sticky" when merging canonical
>> types but there's not precedent in doing this kind of thing and
>> I'm not sure we'll get everything merged before computing alias
>> sets.
>>
>> CCing Honza.
>
> So after discussion and some more thinking we don't really benefit
> (and really can't) from having different aggregates with such
> members distignuishable via their alias set.  So the following
> simplifies the approach and makes the above LTO bits trivial
> by more following Bernds approach of assigning the types alias
> set zero and instead of in the alias machinery propagate the
> flag on the types.
>
> It should also make reference_alias_ptr_type correct and it
> does the flag propagation in type layout.
>
> [LTO] bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> The C++ bits are unchanged.

The C++ bits are OK.

Jason

[PATCH] handle enumerated types in -Wformat-overflow (PR 80397)

[Martin Sebor]

In a review of my fix for bug 80364 Jakub pointed out that to
determine whether an argument to an integer directive is of
an integer type the gimple-ssa-sprintf pass tests the type code
for equality to INTEGER_TYPE when it should instead be using
INTEGRAL_TYPE_P().  This has the effect of the pass being unable
to use the available range of arguments of enumerated types,
resulting in both false positives and false negatives, and in
some cases, in emitting suboptimal code.

The attached patch replaces those tests with INTEGRAL_TYPE_P().

Since this is not a regression I submit it for GCC 8.

Martin
PR tree-optimization/80397 - missing -Wformat-overflow with arguments of enum types

gcc/ChangeLog:

	PR tree-optimization/80397
	* gimple-ssa-sprintf.c (format_integer): Use INTEGRAL_TYPE_P()
	instead of testing for equality to INTEGER_TYPE.

gcc/testsuite/ChangeLog:

	PR tree-optimization/80397
	* gcc.dg/tree-ssa/builtin-sprintf-warn-17.c: New test.
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 2e62086..d63d5be 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1249,7 +1249,7 @@ format_integer (const directive &dir, tree arg)
 
   return res;
 }
-  else if (TREE_CODE (TREE_TYPE (arg)) == INTEGER_TYPE
+  else if (INTEGRAL_TYPE_P (TREE_TYPE (arg))
 	   || TREE_CODE (TREE_TYPE (arg)) == POINTER_TYPE)
 /* Determine the type of the provided non-constant argument.  */
 argtype = TREE_TYPE (arg);
@@ -1269,7 +1269,7 @@ format_integer (const directive &dir, tree arg)
 
   if (arg
   && TREE_CODE (arg) == SSA_NAME
-  && TREE_CODE (argtype) == INTEGER_TYPE)
+  && INTEGRAL_TYPE_P (argtype))
 {
   /* Try to determine the range of values of the integer argument
 	 (range information is not available for pointers).  */
@@ -1314,7 +1314,7 @@ format_integer (const directive &dir, tree arg)
 	  if (code == NOP_EXPR)
 		{
 		  tree type = TREE_TYPE (gimple_assign_rhs1 (def));
-		  if (TREE_CODE (type) == INTEGER_TYPE
+		  if (INTEGRAL_TYPE_P (type)
 		  || TREE_CODE (type) == POINTER_TYPE)
 		argtype = type;
 		}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-17.c b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-17.c
new file mode 100644
index 000..e043938
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-17.c
@@ -0,0 +1,62 @@
+/* PR tree-optimization/80397 - missing -Wformat-overflow with arguments
+   of enum types
+   { dg-do compile }
+   { dg-options "-O2 -Wall -Wformat-overflow=1 -ftrack-macro-expansion=0" }
+   { dg-require-effective-target int32plus } */
+
+void sink (char*);
+
+long long integer_range (long long min, long long max)
+{
+  extern long long integer_value (void);
+  long long n = integer_value ();
+  return n < min || max < n ? min : n;
+}
+
+typedef enum { i0, imax = __INT_MAX__ } Int;
+typedef enum { ll0, llmax = __LONG_LONG_MAX__ } LLong;
+
+#define R(T, min, max) (T)integer_range (min, max)
+
+char buffer[1];
+#define T(fmt, ...)		\
+  __builtin_sprintf (buffer + 1, fmt, __VA_ARGS__), sink (buffer)
+
+void test_bool (_Bool b)
+{
+  T ("%hhi", b);   // { dg-warning "writing 1 byte" }
+  T ( "%hi", b);   // { dg-warning "writing 1 byte" }
+  T (  "%i", b);   // { dg-warning "writing 1 byte" }
+}
+
+void test_enum (void)
+{
+  T ("%hhi", R (Int,1, 1));   // { dg-warning "writing 1 byte" }
+  T ("%hhi", R (Int,1,22));   // { dg-warning "between 1 and 2 bytes" }
+
+  T ( "%hi", R (Int,1, 2));   // { dg-warning "writing 1 " }
+  T ( "%hi", R (Int,1,22));   // { dg-warning "between 1 and 2 " }
+  T ( "%hi", R (Int,   22,   333));   // { dg-warning "between 2 and 3 " }
+  T ( "%hi", R (Int,  333,  ));   // { dg-warning "between 3 and 4 " }
+
+  T (  "%i", R (Int,1, 1));   // { dg-warning "writing 1 " }
+  T (  "%i", R (Int,1,22));   // { dg-warning "between 1 and 2 " }
+  T (  "%i", R (Int,   22,   333));   // { dg-warning "between 2 and 3 " }
+  T (  "%i", R (Int,  333,  ));   // { dg-warning "between 3 and 4 " }
+  T (  "%i", R (Int, , 5));   // { dg-warning "between 4 and 5 " }
+
+#if __LONG_MAX__ == __LONG_LONG_MAX__
+#  define LLI "%li"
+#else
+#  define LLI "%lli"
+#endif
+
+  T (LLI, R (LLong,1, 1));   // { dg-warning "writing 1 " }
+  T (LLI, R (LLong,1,22));   // { dg-warning "between 1 and 2 " }
+  T (LLI, R (LLong,   22,   333));   // { dg-warning "between 2 and 3 " }
+  T (LLI, R (LLong,  333,  ));   // { dg-warning "between 3 and 4 " }
+  T (LLI, R (LLong, , 5));   // { dg-warning "between 4 and 5 " }
+
+  T (LLI, R (LLong, , 1234567890));  // { dg-warning "between 4 and 10 " }
+  T (LLI, R (LLong, , 12345678901)); // { dg-warning "between 4 and 11 " }
+}

One more patch for PR70478

[Vladimir Makarov]

A recent patch for PR70478 introduced a regression on ARM.   Here is an 
additional patch to fix it.


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

Committed as rev. 246854.


Index: ChangeLog
===
--- ChangeLog	(revision 246853)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2017-04-11  Vladimir Makarov  
+
+	PR rtl-optimization/70478
+	* lra-constraints.c (process_alt_operands): Check memory for
+	disfavoring memory insn operand.
+
 2017-04-11  Jakub Jelinek  
 
 	PR middle-end/80100
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 246808)
+++ lra-constraints.c	(working copy)
@@ -2722,12 +2722,14 @@ process_alt_operands (int only_alternati
 		}
 		}
 
-	  /* When we use memory operand, the insn should read the
-		 value from memory and even if we just wrote a value
-		 into the memory it is costly in comparison with an
-		 insn alternative which does not use memory
-		 (e.g. register or immediate operand).  */
-	  if (no_regs_p && offmemok)
+	  /* When we use an operand requiring memory in given
+		 alternative, the insn should write *and* read the
+		 value to/from memory it is costly in comparison with
+		 an insn alternative which does not use memory
+		 (e.g. register or immediate operand).  We exclude
+		 memory operand for such case as we can satisfy the
+		 memory constraints by reloading address.  */
+	  if (no_regs_p && offmemok && !MEM_P (op))
 		{
 		  if (lra_dump_file != NULL)
 		fprintf

Re: One more path to fix PR70478

[Vladimir Makarov]

On 04/11/2017 03:30 AM, Christophe Lyon wrote:

Hi Vladimir,

On 10 April 2017 at 17:05, Vladimir Makarov  wrote:

   This is the second try to fix

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

   The first try patch triggered a latent bug and broke one Fortran testcase
on x86-64.

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

   Committed as rev. 246808.



This patch causes regression on arm*hf configurations:
   Executed from: gcc.target/arm/arm.exp
 gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times ldrh\\tr[0-9]+ 2
 gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times strh\\tr[0-9]+ 2
 gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vld1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
 gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vmov\\.f16\\tr[0-9]+, s[0-9]+ 4
 gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vmov\\.f16\\ts[0-9]+, r[0-9]+ 4
 gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
vst1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2



I've committed a patch which is supposed to fix the regression.

[PATCH, i386]: Improve STV convert gain function when shifts are involved

[Uros Bizjak]

2017-04-11  Uros Bizjak  

* config/i386/i386.c (dimode_scalar_chain::compute_convert_gain):
Use shift_const cost parameter when calculating gain of STV shifts.

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

Committed to mainline SVN.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 246843)
+++ config/i386/i386.c  (working copy)
@@ -3407,7 +3407,7 @@ dimode_scalar_chain::compute_convert_gain ()
   else if (GET_CODE (src) == ASHIFT
   || GET_CODE (src) == LSHIFTRT)
{
- gain += ix86_cost->add;
+ gain += ix86_cost->shift_const;
  if (CONST_INT_P (XEXP (src, 0)))
gain -= vector_const_cost (XEXP (src, 0));
  if (CONST_INT_P (XEXP (src, 1))

[PATCH] Fix fold_binary_loc BIT_IOR_EXPR folding (PR sanitizer/80349)

[Jakub Jelinek]

Hi!

This is another case where we miss needed folding from argN or their
arguments to the expected expression type (type has to be compatible
with opN's type, but argN is after STRIP_NOPS).

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

2017-04-11  Jakub Jelinek  

PR sanitizer/80349
* fold-const.c (fold_binary_loc) : Convert arg0's
first argument to type.

* g++.dg/ubsan/pr80349.C: New test.

--- gcc/fold-const.c.jj 2017-04-10 22:27:00.0 +0200
+++ gcc/fold-const.c2017-04-11 20:07:02.459839450 +0200
@@ -9916,12 +9916,12 @@ fold_binary_loc (location_t loc,
}
 
  if (c3 != c1)
-   return fold_build2_loc (loc, BIT_IOR_EXPR, type,
-   fold_build2_loc (loc, BIT_AND_EXPR, type,
-TREE_OPERAND (arg0, 0),
-wide_int_to_tree (type,
-  c3)),
-   arg1);
+   {
+ tem = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));
+ tem = fold_build2_loc (loc, BIT_AND_EXPR, type, tem,
+wide_int_to_tree (type, c3));
+ return fold_build2_loc (loc, BIT_IOR_EXPR, type, tem, arg1);
+   }
}
 
   /* See if this can be simplified into a rotate first.  If that
--- gcc/testsuite/g++.dg/ubsan/pr80349.C.jj 2017-04-11 20:29:10.154344673 
+0200
+++ gcc/testsuite/g++.dg/ubsan/pr80349.C2017-04-11 20:28:38.0 
+0200
@@ -0,0 +1,11 @@
+// PR sanitizer/80349
+// { dg-do compile }
+// { dg-options "-fsanitize=undefined" }
+
+extern const long long int v;
+
+void
+foo ()
+{
+  (int)((v & 50 | 051UL) << 0) << 0;
+}

Jakub

C++ PATCH for c++/80294, ICE with constexpr and inheritance

[Jason Merrill]

Here, when we look at the value of an empty base, we would first make
sure that the complete object is constant.  But we were in the middle
of initializing one of the fields of the complete object, so the
corresponding CONSTRUCTOR value was NULL, leading to a crash when
trying to determine if it's constant.

There are two issues here:

1) We shouldn't crash.  We should treat a field under initialization
as non-constant.
2) We shouldn't require that the complete object be constant.  It's
fine to use the value of a fully constructed subobject while
initializing another member.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5d650f368849196d53af19decdfcc5217ca0301b
Author: Jason Merrill 
Date:   Sun Apr 9 00:49:10 2017 -0400

PR c++/80294 - ICE with constexpr and inheritance.

* constexpr.c (reduced_constant_expression_p):
A null constructor element is non-constant.
(cxx_eval_indirect_ref): Don't VERIFY_CONSTANT before
returning an empty base.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 3ca3560..9dde4a4 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1716,8 +1716,13 @@ reduced_constant_expression_p (tree t)
   /* And we need to handle PTRMEM_CST wrapped in a CONSTRUCTOR.  */
   tree elt; unsigned HOST_WIDE_INT idx;
   FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (t), idx, elt)
-   if (!reduced_constant_expression_p (elt))
- return false;
+   {
+ if (!elt)
+   /* We're in the middle of initializing this element.  */
+   return false;
+ if (!reduced_constant_expression_p (elt))
+   return false;
+   }
   return true;
 
 default:
@@ -3153,12 +3158,10 @@ cxx_eval_indirect_ref (const constexpr_ctx *ctx, tree t,
   if (*non_constant_p)
 return t;
 
-  /* If we're pulling out the value of an empty base, make sure
- that the whole object is constant and then return an empty
+  /* If we're pulling out the value of an empty base, just return an empty
  CONSTRUCTOR.  */
   if (empty_base && !lval)
 {
-  VERIFY_CONSTANT (r);
   r = build_constructor (TREE_TYPE (t), NULL);
   TREE_CONSTANT (r) = true;
 }
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-empty3.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-empty3.C
new file mode 100644
index 000..37e4a53
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-empty3.C
@@ -0,0 +1,14 @@
+// PR c++/80294
+// { dg-do compile { target c++14 } }
+// { dg-final { scan-assembler-not "static_init" } }
+
+struct A {
+  constexpr int f() { A a = *this; return 42; }
+};
+struct B: A
+{
+  int i;
+  constexpr B(): i(f()) {}
+};
+
+B b;

Re: [libcp1] handle anon aggregates linkage-named by typedefs

[Alexandre Oliva]

On Apr 10, 2017, Jeff Law  wrote:

> On 03/21/2017 05:32 PM, Alexandre Oliva wrote:
>> * libcp1plugin.cc (plugin_build_decl): Propagate typedef name to
>> anonymous aggregate target type.
> Can you put some kind of pointer in the code you copied from cp/decl.c
> so that there's some chance anyone changing that code would at least
> go look at the libcpplugin.cc copy and try to DTRT.

Well, if we're actually touching the g++ code, I'd much rather refactor
it a bit and export this chunk of code for libcc1 to use without
copying.  How's this instead?  (testing)


[libcp1] handle anon aggregates linkage-named by typedefs

Arrange for the first typedef to an anonymous type in the same context
to be used as the linkage name for the type.

for  gcc/cp/ChangeLog

* decl.c (name_unnamed_type): Split out of...
(grokdeclarator): ... this.
* decl.h (name_unnamed_type): Declare.

for  libcc1/ChangeLog

* libcp1plugin.cc (plugin_build_decl): Call name_unnamed_type.
---
 gcc/cp/decl.c  |   75 
 gcc/cp/decl.h  |1 +
 libcc1/libcp1plugin.cc |9 ++
 3 files changed, 54 insertions(+), 31 deletions(-)

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 516b93c..b29945c 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -9831,6 +9831,49 @@ mark_inline_variable (tree decl)
 }
 }
 
+
+/* Assign a typedef-given name to a class or enumeration type declared
+   as anonymous at first.  This was split out of grokdeclarator
+   because it is also used in libcc1.  */
+
+void
+name_unnamed_type (tree type, tree decl)
+{
+  gcc_assert (TYPE_UNNAMED_P (type));
+
+  /* Replace the anonymous name with the real name everywhere.  */
+  for (tree t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
+{
+  if (anon_aggrname_p (TYPE_IDENTIFIER (t)))
+   /* We do not rename the debug info representing the
+  unnamed tagged type because the standard says in
+  [dcl.typedef] that the naming applies only for
+  linkage purposes.  */
+   /*debug_hooks->set_name (t, decl);*/
+   TYPE_NAME (t) = decl;
+}
+
+  if (TYPE_LANG_SPECIFIC (type))
+TYPE_WAS_UNNAMED (type) = 1;
+
+  /* If this is a typedef within a template class, the nested
+ type is a (non-primary) template.  The name for the
+ template needs updating as well.  */
+  if (TYPE_LANG_SPECIFIC (type) && CLASSTYPE_TEMPLATE_INFO (type))
+DECL_NAME (CLASSTYPE_TI_TEMPLATE (type))
+  = TYPE_IDENTIFIER (type);
+
+  /* Adjust linkage now that we aren't unnamed anymore.  */
+  reset_type_linkage (type);
+
+  /* FIXME remangle member functions; member functions of a
+ type with external linkage have external linkage.  */
+
+  /* Check that our job is done, and that it would fail if we
+ attempted to do it again.  */
+  gcc_assert (!TYPE_UNNAMED_P (type));
+}
+
 /* Given declspecs and a declarator (abstract or otherwise), determine
the name and type of the object declared and construct a DECL node
for it.
@@ -11555,37 +11598,7 @@ grokdeclarator (const cp_declarator *declarator,
  && declspecs->type_definition_p
  && attributes_naming_typedef_ok (*attrlist)
  && cp_type_quals (type) == TYPE_UNQUALIFIED)
-   {
- tree t;
-
- /* Replace the anonymous name with the real name everywhere.  */
- for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
-   {
- if (anon_aggrname_p (TYPE_IDENTIFIER (t)))
-   /* We do not rename the debug info representing the
-  unnamed tagged type because the standard says in
-  [dcl.typedef] that the naming applies only for
-  linkage purposes.  */
-   /*debug_hooks->set_name (t, decl);*/
-   TYPE_NAME (t) = decl;
-   }
-
- if (TYPE_LANG_SPECIFIC (type))
-   TYPE_WAS_UNNAMED (type) = 1;
-
- /* If this is a typedef within a template class, the nested
-type is a (non-primary) template.  The name for the
-template needs updating as well.  */
- if (TYPE_LANG_SPECIFIC (type) && CLASSTYPE_TEMPLATE_INFO (type))
-   DECL_NAME (CLASSTYPE_TI_TEMPLATE (type))
- = TYPE_IDENTIFIER (type);
-
- /* Adjust linkage now that we aren't unnamed anymore.  */
- reset_type_linkage (type);
-
- /* FIXME remangle member functions; member functions of a
-type with external linkage have external linkage.  */
-   }
+   name_unnamed_type (type, decl);
 
   if (signed_p
  || (typedef_decl && C_TYPEDEF_EXPLICITLY_SIGNED (typedef_decl)))
diff --git a/gcc/cp/decl.h b/gcc/cp/decl.h
index 3e1d91f..d84d90c 100644
--- a/gcc/cp/decl.h
+++ b/gcc/cp/decl.h
@@ -35,6 +35,7 @@ enum decl_context
 extern tree grokdeclarator (const cp_declarator *,
cp_decl_specifier_seq *,
enum decl

[PATCH, rs6000] Fix PR80376 and PR80315

[Bill Schmidt]

Hi,

The previous patch for PR80376 produced a different sort of ICE, which wasn't
a terribly great solution.  I looked into Segher's suggestion based on code in
x86, but that wasn't appropriate here as the problem happens at a different
place.  The real secondary problem is that we produce a const0_rtx instead of
a mode-compatible CONST0_RTX, so the assignment of the built-in result to its
target rtx fails with an ICE.  I've gone through rs6000.c and fixed the places
where we do this in an obviously wrong manner.

This patch still fixes the missing vec_xxpermdi cases that were the primary
cause of the bug (this time with consistent whitespace), and corrects the
documentation to show that argument 3 must be a constant.  I also decided to
fix PR80315, which just had a silly pasto where we were checking the value
of the wrong argument, since this patch fixes one of the CONST0_RTX cases
right next to it.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
Is this ok for trunk?  Both bugs were reported against GCC 6.2, so I would
also like to backport the fixes to 6 and possibly 5.

Thanks,
Bill


2017-04-11  Bill Schmidt  

PR target/80376
PR target/80315
* config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
CONST0_RTX (mode) rather than const0_rtx where appropriate.
(rs6000_expand_binop_builtin): Likewise.
(rs6000_expand_ternop_builtin): Likewise; also add missing
vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
vshasigma built-ins.
* doc/extend.texi: Document that vec_xxpermdi's third argument
must be a constant.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 246804)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -14550,7 +14550,7 @@ rs6000_expand_unop_builtin (enum insn_code icode,
  || INTVAL (op0) < -16)
{
  error ("argument 1 must be a 5-bit signed literal");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
 
@@ -14653,7 +14653,7 @@ rs6000_expand_binop_builtin (enum insn_code icode,
  || TREE_INT_CST_LOW (arg1) & ~0x1f)
{
  error ("argument 2 must be a 5-bit unsigned literal");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
   else if (icode == CODE_FOR_dfptstsfi_eq_dd
@@ -15579,7 +15579,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode
  || TREE_INT_CST_LOW (arg2) & ~0xf)
{
  error ("argument 3 must be a 4-bit unsigned literal");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
   else if (icode == CODE_FOR_vsx_xxpermdi_v2df
@@ -15586,6 +15586,11 @@ rs6000_expand_ternop_builtin (enum insn_code icode
|| icode == CODE_FOR_vsx_xxpermdi_v2di
|| icode == CODE_FOR_vsx_xxpermdi_v2df_be
|| icode == CODE_FOR_vsx_xxpermdi_v2di_be
+   || icode == CODE_FOR_vsx_xxpermdi_v1ti
+   || icode == CODE_FOR_vsx_xxpermdi_v4sf
+   || icode == CODE_FOR_vsx_xxpermdi_v4si
+   || icode == CODE_FOR_vsx_xxpermdi_v8hi
+   || icode == CODE_FOR_vsx_xxpermdi_v16qi
|| icode == CODE_FOR_vsx_xxsldwi_v16qi
|| icode == CODE_FOR_vsx_xxsldwi_v8hi
|| icode == CODE_FOR_vsx_xxsldwi_v4si
@@ -15599,7 +15604,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode
  || TREE_INT_CST_LOW (arg2) & ~0x3)
{
  error ("argument 3 must be a 2-bit unsigned literal");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
   else if (icode == CODE_FOR_vsx_set_v2df
@@ -15619,7 +15624,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode
  || TREE_INT_CST_LOW (arg2) & ~0x1)
{
  error ("argument 3 must be a 1-bit unsigned literal");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
   else if (icode == CODE_FOR_dfp_ddedpd_dd
@@ -15631,7 +15636,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode
  || TREE_INT_CST_LOW (arg2) & ~0x3)
{
  error ("argument 1 must be 0 or 2");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
   else if (icode == CODE_FOR_dfp_denbcd_dd
@@ -15643,7 +15648,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode
  || TREE_INT_CST_LOW (arg0) & ~0x1)
{
  error ("argument 1 must be a 1-bit unsigned literal");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
   else if (icode == CODE_FOR_dfp_dscli_dd
@@ -15657,7 +15662,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode
  || TREE_INT_CST_LOW (arg1) & ~0x3f)
{
  error ("argument 2 must be a 6-bit unsigned literal");
- return const0_rtx;
+ return CONST0_RTX (tmode);
}
 }
   else if (icode == CODE_FOR_c

[PATCH], Fix PR 80098, Add better checking for disabling features

[Michael Meissner]

PR 80098 is an interaction between -mmodulo (ISA 3.0/power9 GPR modulo
instructions) and -mno-vsx where the -mmodulo option enables some of the ISA
3.0 vector features, even though -mno-vsx was specified.

To do this, I added a table for disabling other vector options when the major
vector options (-mvsx, -mpower8-vector, and -mpower9-vector) are disabled.

We could extend this if desired for other options (for example, -mno-popcntd
could disable -mmodulo and perhaps the vector options).

I built and tested the compiler on a little endian power8 Linux system and
there were no regressions.  Is it ok for the trunk?

[gcc]
2017-04-11  Michael Meissner  

PR target/80098
* config/rs6000/rs6000-cpus.def (OTHER_P9_VECTOR_MASKS): Define
masks of options that should be turned off if the VSX vector
options are turned off.
(OTHER_P8_VECTOR_MASKS): Likewise.
(OTHER_VSX_VECTOR_MASKS): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Call
rs6000_disable_incompatible_switches to validate no type switches
like -mvsx.
(rs6000_incompatible_switch): New function to disallow turning on
other vector options if -mno-vsx, -mno-power8-vector, or
-mno-power9-vector are specified.

[gcc/testsuite]
2017-04-11  Michael Meissner  

PR target/80098
* gcc.target/powerpc/pr80098-1.c: New test.
* gcc.target/powerpc/pr80098-2.c: Likewise.
* gcc.target/powerpc/pr80098-3.c: Likewise.
* gcc.target/powerpc/pr80098-4.c: Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-cpus.def
===
--- gcc/config/rs6000/rs6000-cpus.def   (revision 246826)
+++ gcc/config/rs6000/rs6000-cpus.def   (working copy)
@@ -84,6 +84,30 @@
 | OPTION_MASK_UPPER_REGS_SF\
 | OPTION_MASK_VSX_SMALL_INTEGER)
 
+/* Flags that need to be turned off if -mno-power9-vector.  */
+#define OTHER_P9_VECTOR_MASKS  (OPTION_MASK_FLOAT128_HW\
+| OPTION_MASK_P9_DFORM_SCALAR  \
+| OPTION_MASK_P9_DFORM_VECTOR  \
+| OPTION_MASK_P9_MINMAX)
+
+/* Flags that need to be turned off if -mno-power8-vector.  */
+#define OTHER_P8_VECTOR_MASKS  (OTHER_P9_VECTOR_MASKS  \
+| OPTION_MASK_P9_VECTOR\
+| OPTION_MASK_DIRECT_MOVE  \
+| OPTION_MASK_CRYPTO   \
+| OPTION_MASK_UPPER_REGS_SF)   \
+
+/* Flags that need to be turned off if -mno-vsx.  */
+#define OTHER_VSX_VECTOR_MASKS (OTHER_P8_VECTOR_MASKS  \
+| OPTION_MASK_EFFICIENT_UNALIGNED_VSX  \
+| OPTION_MASK_FLOAT128_KEYWORD \
+| OPTION_MASK_FLOAT128_TYPE\
+| OPTION_MASK_P8_VECTOR\
+| OPTION_MASK_UPPER_REGS_DI\
+| OPTION_MASK_UPPER_REGS_DF\
+| OPTION_MASK_VSX_SMALL_INTEGER\
+| OPTION_MASK_VSX_TIMODE)
+
 #define POWERPC_7400_MASK  (OPTION_MASK_PPC_GFXOPT | OPTION_MASK_ALTIVEC)
 
 /* Deal with ports that do not have -mstrict-align.  */
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 246826)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1335,6 +1335,7 @@ static void rs6000_print_isa_options (FI
  HOST_WIDE_INT);
 static void rs6000_print_builtin_options (FILE *, int, const char *,
  HOST_WIDE_INT);
+static HOST_WIDE_INT rs6000_disable_incompatible_switches (void);
 
 static enum rs6000_reg_type register_to_reg_type (rtx, bool *);
 static bool rs6000_secondary_reload_move (enum rs6000_reg_type,
@@ -3902,6 +3903,7 @@ rs6000_option_override_internal (bool gl
   const char *implicit_cpu = OPTION_TARGET_CPU_DEFAULT;
 
   HOST_WIDE_INT set_masks;
+  HOST_WIDE_INT ignore_masks;
   int cpu_index;
   int tune_index;
   struct cl_target_option *main_target_opt
@@ -3967,7 +3969,7 @@ rs6000_option_override_internal (bool gl
 #endif
 #ifdef OS_MISSING_ALTIVEC
   if (OS_MISSING_ALTIVEC)
-set_masks &= ~(OPTION_MASK_ALTIVEC | OPTION_MASK_VSX);
+set_masks &= ~NO_ALTIVEC_MASKS;
 #endif
 
   /* Don't override by the processor default if given explicitly.  */
@@ -4270,11 +4272,15 @@ rs6000_option_override_internal (

Re: [PATCH, rs6000] Fix PR80376 and PR80315

[Segher Boessenkool]

Hi!

On Tue, Apr 11, 2017 at 04:27:05PM -0500, Bill Schmidt wrote:
> The real secondary problem is that we produce a const0_rtx instead of
> a mode-compatible CONST0_RTX, so the assignment of the built-in result to its
> target rtx fails with an ICE.  I've gone through rs6000.c and fixed the places
> where we do this in an obviously wrong manner.

Let's hope there aren't any left.

> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
> Is this ok for trunk?  Both bugs were reported against GCC 6.2, so I would
> also like to backport the fixes to 6 and possibly 5.

Okay for all.  Thanks!


Segher


>   PR target/80376
>   PR target/80315
>   * config/rs6000/rs6000.c (rs6000_expand_unop_builtin): Return
>   CONST0_RTX (mode) rather than const0_rtx where appropriate.
>   (rs6000_expand_binop_builtin): Likewise.
>   (rs6000_expand_ternop_builtin): Likewise; also add missing
>   vsx_xxpermdi_* variants; also fix typo (arg1 => arg2) for
>   vshasigma built-ins.
>   * doc/extend.texi: Document that vec_xxpermdi's third argument
>   must be a constant.

[wwwdocs] Adjust 2015 ACM Award link

[Gerald Pfeifer]

Applied.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1047
diff -u -r1.1047 index.html
--- index.html  15 Mar 2017 14:31:25 -  1.1047
+++ index.html  11 Apr 2017 22:10:19 -
@@ -85,7 +85,7 @@
 [2016-06-03]
 
 
-http://www.acm.org/awards/2015-technical-awards";>2015 ACM 
Software System Award
+http://awards.acm.org/about/2015-technical-awards";>2015 ACM 
Software System Award
 [2016-04-29]
 
 

Re: [wwwdocs,C++] wg21.link's on projects/cxx-status.html

[Gerald Pfeifer]

I applied this now.

Gerald

On Sat, 1 Apr 2017, Gerald Pfeifer wrote:
> is there a particular reason you used uppercase for this one
> link, unlike the others?
> 
> Not a problem per se, just for the sake of consistency (also to
> minimize exception rules I maintain for my link checker ;-).
> 
> Any objections to the patch below?
> 
> Gerald
> 
> Index: projects/cxx-status.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
> retrieving revision 1.40
> diff -u -r1.40 cxx-status.html
> --- projects/cxx-status.html  16 Mar 2017 21:18:01 -  1.40
> +++ projects/cxx-status.html  1 Apr 2017 20:08:11 -
> @@ -294,7 +294,7 @@
>  
>  
>A byte type definition
> -  http://wg21.link/P0298R0";>P0298R0
> +  http://wg21.link/p0298r0";>P0298R0
>7
>
>  
> 

Re: [wwwdocs] Adjust to the new location of the C++ ABI

[Gerald Pfeifer]

On Thu, 30 Mar 2017, Gerald Pfeifer wrote:
> For gcc-4.0/ and faq.html I did adjust the link, for gcc-3.2/ I
> figured we can as well avoid it.

And here was another one...

Applied.

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.275
diff -u -r1.275 readings.html
--- readings.html   1 Apr 2017 20:02:50 -   1.275
+++ readings.html   11 Apr 2017 22:29:59 -
@@ -37,7 +37,7 @@
   by Joachim Nadler and Tim Josling
   t...@melbpc.org.au>.
 
-  http://mentorembedded.github.io/cxx-abi/";>
+  https://itanium-cxx-abi.github.io/cxx-abi/";>
   The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0 and
   above.
 

[libstdc++] Adjust to the new location of the C++ ABI

[Gerald Pfeifer]

On Thu, 30 Mar 2017, Gerald Pfeifer wrote:
> (Jonathan, I'm going to take care of the libstdc++/doc links as
> well in case you wonder.)

Done thusly.

Jonathan, do you think one of the three references in 
doc/xml/manual/abi.xml could be avoided?  That'll make it easier 
next time this document moves. :-}

(Also, if you could regenerate and upload the docs?)

Gerald

2017-04-12  Gerald Pfeifer  

* doc/xml/faq.xml: Update reference link to C++ ABI for Itanium.
* doc/xml/manual/abi.xml. Ditto (thrice).

Index: doc/xml/faq.xml
===
--- doc/xml/faq.xml (revision 246859)
+++ doc/xml/faq.xml (working copy)
@@ -1213,7 +1213,7 @@
 details than for C, and most CPU designers (for good reasons elaborated
 below) have not stepped up to publish C++ ABIs.  Such an ABI has been
 defined for the Itanium architecture (see
-http://www.w3.org/1999/xlink"; 
xlink:href="http://mentorembedded.github.io/cxx-abi/";>C++
+http://www.w3.org/1999/xlink"; 
xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/";>C++
 ABI for Itanium) and that is used by G++ and other compilers
 as the de facto standard ABI on many common architectures (including x86).
 G++ can also use the ARM architecture's EABI, for embedded
Index: doc/xml/manual/abi.xml
===
--- doc/xml/manual/abi.xml  (revision 246859)
+++ doc/xml/manual/abi.xml  (working copy)
@@ -42,7 +42,7 @@
   virtual functions, etc. These details are defined as the compiler
   Application Binary Interface, or ABI. The GNU C++ compiler uses an
   industry-standard C++ ABI starting with version 3. Details can be
-  found in the http://www.w3.org/1999/xlink"; 
xlink:href="http://mentorembedded.github.io/cxx-abi/abi.html";>ABI
+  found in the http://www.w3.org/1999/xlink"; 
xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/";>ABI
   specification.
 
 
@@ -757,7 +757,7 @@
 the way the compiler deals with this class in by-value return
 statements or parameters: instead of passing instances of this
 class in registers, the compiler will be forced to use memory. See the
-section on http://www.w3.org/1999/xlink"; 
xlink:href="http://mentorembedded.github.io/cxx-abi/abi.html#calls";>Function
+section on http://www.w3.org/1999/xlink"; 
xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/abi.html#calls";>Function
 Calling Conventions and APIs
  of the C++ ABI documentation for further details.
 
@@ -1115,7 +1115,7 @@
 
   
http://www.w3.org/1999/xlink";
- xlink:href="http://mentorembedded.github.io/cxx-abi/";>
+ xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/";>
  C++ ABI Summary

   

[wwwdocs,fortran] Update link to CHKSYS

[Gerald Pfeifer]

This one has been failing for quite a while, and I found
  http://flibs.sourceforge.net/chksys.html
as a potential replacement link.

Thoughts?

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.276
diff -u -r1.276 readings.html
--- readings.html   11 Apr 2017 22:30:59 -  1.276
+++ readings.html   11 Apr 2017 22:39:10 -
@@ -436,7 +436,7 @@
 possible to stress the compiler error handling.
   
   
-http://ftp.cac.psu.edu/pub/ger/fortran/chksys.htm";>Checking
+http://flibs.sourceforge.net/chksys.html";>Checking
 properties of the compiler and the run-time environment by
 Arjen Markus (source provided).
   

Re: [PATCH], Fix PR 80098, Add better checking for disabling features

[Segher Boessenkool]

Hi!

On Tue, Apr 11, 2017 at 05:32:41PM -0400, Michael Meissner wrote:
> PR 80098 is an interaction between -mmodulo (ISA 3.0/power9 GPR modulo
> instructions) and -mno-vsx where the -mmodulo option enables some of the ISA
> 3.0 vector features, even though -mno-vsx was specified.
> 
> To do this, I added a table for disabling other vector options when the major
> vector options (-mvsx, -mpower8-vector, and -mpower9-vector) are disabled.
> 
> We could extend this if desired for other options (for example, -mno-popcntd
> could disable -mmodulo and perhaps the vector options).

Or we could just remove -mmodulo etc.  What good do they do?  They make
testing infeasible: an exponential number of combinations to test.

> @@ -3967,7 +3969,7 @@ rs6000_option_override_internal (bool gl
>  #endif
>  #ifdef OS_MISSING_ALTIVEC
>if (OS_MISSING_ALTIVEC)
> -set_masks &= ~(OPTION_MASK_ALTIVEC | OPTION_MASK_VSX);
> +set_masks &= ~NO_ALTIVEC_MASKS;

NO_ALTIVEC_MASKS isn't defined anywhere.  Did you send the wrong patch?


Segher

libgo patch committed: Fix support for vendor directories

[Ian Lance Taylor]

Vendor directories are a concept supported by the go tool
(https://golang.org/cmd/go/#hdr-Vendor_Directories).  They have never
worked properly for gccgo, as has been reported as PR 77857 and
https://golang.org/issue/15628.  This patch by Lynn Boger fixes vendor
support for gccgo by adding appropriate -I options.  Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: libgo/go/cmd/go/build.go
===
--- libgo/go/cmd/go/build.go(revision 245745)
+++ libgo/go/cmd/go/build.go(working copy)
@@ -2398,14 +2398,6 @@ func (gcToolchain) gc(b *builder, p *Pac
}
}
 
-   for _, path := range p.Imports {
-   if i := strings.LastIndex(path, "/vendor/"); i >= 0 {
-   gcargs = append(gcargs, "-importmap", 
path[i+len("/vendor/"):]+"="+path)
-   } else if strings.HasPrefix(path, "vendor/") {
-   gcargs = append(gcargs, "-importmap", 
path[len("vendor/"):]+"="+path)
-   }
-   }
-
args := []interface{}{buildToolExec, tool("compile"), "-o", ofile, 
"-trimpath", b.work, buildGcflags, gcargs, "-D", p.localPrefix, importArgs}
if ofile == archive {
args = append(args, "-pack")
@@ -2706,6 +2698,55 @@ func (tools gccgoToolchain) gc(b *builde
if p.localPrefix != "" {
gcargs = append(gcargs, 
"-fgo-relative-import-path="+p.localPrefix)
}
+   savedirs := []string{}
+   for _, incdir := range importArgs {
+   if incdir != "-I" {
+   savedirs = append(savedirs, incdir)
+   }
+   }
+
+   for _, path := range p.Imports {
+   // If this is a new vendor path, add it to the list of 
importArgs
+   if i := strings.LastIndex(path, "/vendor"); i >= 0 {
+   for _, dir := range savedirs {
+   // Check if the vendor path is already included 
in dir
+   if strings.HasSuffix(dir, 
path[:i+len("/vendor")]) {
+   continue
+   }
+   // Make sure this vendor path is not already in 
the list for importArgs
+   vendorPath := dir + "/" + 
path[:i+len("/vendor")]
+   for _, imp := range importArgs {
+   if imp == "-I" {
+   continue
+   }
+   // This vendorPath is already in the 
list
+   if imp == vendorPath {
+   goto nextSuffixPath
+   }
+   }
+   // New vendorPath not yet in the importArgs 
list, so add it
+   importArgs = append(importArgs, "-I", 
vendorPath)
+   nextSuffixPath:
+   }
+   } else if strings.HasPrefix(path, "vendor/") {
+   for _, dir := range savedirs {
+   // Make sure this vendor path is not already in 
the list for importArgs
+   vendorPath := dir + "/" + path[len("/vendor"):]
+   for _, imp := range importArgs {
+   if imp == "-I" {
+   continue
+   }
+   if imp == vendorPath {
+   goto nextPrefixPath
+   }
+   }
+   // This vendor path is needed and not already 
in the list, so add it
+   importArgs = append(importArgs, "-I", 
vendorPath)
+   nextPrefixPath:
+   }
+   }
+   }
+
args := stringList(tools.compiler(), importArgs, "-c", gcargs, "-o", 
ofile, buildGccgoflags)
for _, f := range gofiles {
args = append(args, mkAbs(p.Dir, f))

Re: [PATCH] Fix fold_binary_loc BIT_IOR_EXPR folding (PR sanitizer/80349)

[Richard Biener]

On April 11, 2017 10:54:10 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>This is another case where we miss needed folding from argN or their
>arguments to the expected expression type (type has to be compatible
>with opN's type, but argN is after STRIP_NOPS).
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

>2017-04-11  Jakub Jelinek  
>
>   PR sanitizer/80349
>   * fold-const.c (fold_binary_loc) : Convert arg0's
>   first argument to type.
>
>   * g++.dg/ubsan/pr80349.C: New test.
>
>--- gcc/fold-const.c.jj2017-04-10 22:27:00.0 +0200
>+++ gcc/fold-const.c   2017-04-11 20:07:02.459839450 +0200
>@@ -9916,12 +9916,12 @@ fold_binary_loc (location_t loc,
>   }
> 
> if (c3 != c1)
>-  return fold_build2_loc (loc, BIT_IOR_EXPR, type,
>-  fold_build2_loc (loc, BIT_AND_EXPR, type,
>-   TREE_OPERAND (arg0, 0),
>-   wide_int_to_tree (type,
>- c3)),
>-  arg1);
>+  {
>+tem = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));
>+tem = fold_build2_loc (loc, BIT_AND_EXPR, type, tem,
>+   wide_int_to_tree (type, c3));
>+return fold_build2_loc (loc, BIT_IOR_EXPR, type, tem, arg1);
>+  }
>   }
> 
>   /* See if this can be simplified into a rotate first.  If that
>--- gcc/testsuite/g++.dg/ubsan/pr80349.C.jj2017-04-11
>20:29:10.154344673 +0200
>+++ gcc/testsuite/g++.dg/ubsan/pr80349.C   2017-04-11 20:28:38.0
>+0200
>@@ -0,0 +1,11 @@
>+// PR sanitizer/80349
>+// { dg-do compile }
>+// { dg-options "-fsanitize=undefined" }
>+
>+extern const long long int v;
>+
>+void
>+foo ()
>+{
>+  (int)((v & 50 | 051UL) << 0) << 0;
>+}
>
>   Jakub

Re: One more path to fix PR70478

[Christophe Lyon]

On 11 April 2017 at 21:43, Vladimir Makarov  wrote:
>
>
> On 04/11/2017 03:30 AM, Christophe Lyon wrote:
>>
>> Hi Vladimir,
>>
>> On 10 April 2017 at 17:05, Vladimir Makarov  wrote:
>>>
>>>This is the second try to fix
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
>>>
>>>The first try patch triggered a latent bug and broke one Fortran
>>> testcase
>>> on x86-64.
>>>
>>>The patch was successfully bootstrapped on x86-64 and tested on
>>> x86-64,
>>> ppc64, and aarch64.
>>>
>>>Committed as rev. 246808.
>>>
>>>
>> This patch causes regression on arm*hf configurations:
>>Executed from: gcc.target/arm/arm.exp
>>  gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
>> ldrh\\tr[0-9]+ 2
>>  gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
>> strh\\tr[0-9]+ 2
>>  gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
>> vld1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
>>  gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
>> vmov\\.f16\\tr[0-9]+, s[0-9]+ 4
>>  gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
>> vmov\\.f16\\ts[0-9]+, r[0-9]+ 4
>>  gcc.target/arm/armv8_2-fp16-move-1.c scan-assembler-times
>> vst1\\.16\\t{d[0-9]+\\[[0-9]+\\]}, \\[r[0-9]+\\] 2
>>
>>
> I've committed a patch which is supposed to fix the regression.
>

I confirm it's now OK. Thanks for the prompt fix!

Christophe