[PATCH 1/2] i386: Use scalar operand in floating point vec_dup patterns

[H.J. Lu]

Since vector registers are also used for scalar floating point values,
we can use scalar operand in floating point vec_dup patterns, which
enables combiner to generate

(set (reg:V8SF 84)
 (vec_duplicate:V8SF (mem/c:SF (symbol_ref:DI ("y")

For AVX512 broadcast instructions from integer register operand, we only
need to broadcast integer to integer vectors.

gcc/

PR target/87537
* config/i386/i386-builtin-types.def: Replace
CODE_FOR_avx2_vec_dupv4sf, CODE_FOR_avx2_vec_dupv8sf and
CODE_FOR_avx2_vec_dupv4df with CODE_FOR_vec_dupv4sf,
CODE_FOR_vec_dupv8sf and CODE_FOR_vec_dupv4df, respectively.
* config/i386/i386.c (expand_vec_perm_1): Replace
gen_avx512f_vec_dupv16sf_1, gen_avx2_vec_dupv8sf_1 and
gen_avx512f_vec_dupv8df_1 with gen_avx512f_vec_dupv16sf,
gen_vec_dupv8sf and gen_avx512f_vec_dupv8df, respectively.
Duplicate them from scalar operand.
* config/i386/i386.md (SF to DF splitter): Replace
gen_avx512f_vec_dupv16sf_1 with gen_avx512f_vec_dupv16sf.
* config/i386/sse.md (VF48_AVX512VL): New.
(avx2_vec_dup): Removed.
(avx2_vec_dupv8sf_1): Likewise.
(avx512f_vec_dup_1): Likewise.
(avx2_vec_dupv4df): Likewise.
(_vec_dup:V48_AVX512VL): Likewise.
(_vec_dup:VF48_AVX512VL): New.
(_vec_dup:VI48_AVX512VL): Likewise.
(_vec_dup_gpr): Replace
V48_AVX512VL with VI48_AVX512VL.
(*avx_vperm_broadcast_): Replace gen_avx2_vec_dupv8sf with
gen_vec_dupv8sf.

gcc/testsuite/

PR target/87537
* gcc.target/i386/avx2-vbroadcastss_ps256-1.c: Updated.
* gcc.target/i386/avx512vl-vbroadcast-3.c: Likewise.
---
 gcc/config/i386/i386-builtin.def  |  6 +-
 gcc/config/i386/i386.c| 28 ++-
 gcc/config/i386/i386.md   |  2 +-
 gcc/config/i386/sse.md| 82 ++-
 .../i386/avx2-vbroadcastss_ps256-1.c  |  3 +-
 .../gcc.target/i386/avx512vl-vbroadcast-3.c   |  5 +-
 6 files changed, 56 insertions(+), 70 deletions(-)

diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index dc4c70c7ea3..922f9ea2544 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -1194,9 +1194,9 @@ BDESC (OPTION_MASK_ISA_AVX2, 
CODE_FOR_avx2_interleave_lowv16hi, "__builtin_ia32_
 BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_interleave_lowv8si, 
"__builtin_ia32_punpckldq256", IX86_BUILTIN_PUNPCKLDQ256, UNKNOWN, (int) 
V8SI_FTYPE_V8SI_V8SI)
 BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_interleave_lowv4di, 
"__builtin_ia32_punpcklqdq256", IX86_BUILTIN_PUNPCKLQDQ256, UNKNOWN, (int) 
V4DI_FTYPE_V4DI_V4DI)
 BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_xorv4di3, "__builtin_ia32_pxor256", 
IX86_BUILTIN_PXOR256, UNKNOWN, (int) V4DI_FTYPE_V4DI_V4DI)
-BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_vec_dupv4sf, 
"__builtin_ia32_vbroadcastss_ps", IX86_BUILTIN_VBROADCASTSS_PS, UNKNOWN, (int) 
V4SF_FTYPE_V4SF)
-BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_vec_dupv8sf, 
"__builtin_ia32_vbroadcastss_ps256", IX86_BUILTIN_VBROADCASTSS_PS256, UNKNOWN, 
(int) V8SF_FTYPE_V4SF)
-BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_vec_dupv4df, 
"__builtin_ia32_vbroadcastsd_pd256", IX86_BUILTIN_VBROADCASTSD_PD256, UNKNOWN, 
(int) V4DF_FTYPE_V2DF)
+BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_vec_dupv4sf, 
"__builtin_ia32_vbroadcastss_ps", IX86_BUILTIN_VBROADCASTSS_PS, UNKNOWN, (int) 
V4SF_FTYPE_V4SF)
+BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_vec_dupv8sf, 
"__builtin_ia32_vbroadcastss_ps256", IX86_BUILTIN_VBROADCASTSS_PS256, UNKNOWN, 
(int) V8SF_FTYPE_V4SF)
+BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_vec_dupv4df, 
"__builtin_ia32_vbroadcastsd_pd256", IX86_BUILTIN_VBROADCASTSD_PD256, UNKNOWN, 
(int) V4DF_FTYPE_V2DF)
 BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_vbroadcasti128_v4di, 
"__builtin_ia32_vbroadcastsi256", IX86_BUILTIN_VBROADCASTSI256, UNKNOWN, (int) 
V4DI_FTYPE_V2DI)
 BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_pblenddv4si, 
"__builtin_ia32_pblendd128", IX86_BUILTIN_PBLENDD128, UNKNOWN, (int) 
V4SI_FTYPE_V4SI_V4SI_INT)
 BDESC (OPTION_MASK_ISA_AVX2, CODE_FOR_avx2_pblenddv8si, 
"__builtin_ia32_pblendd256", IX86_BUILTIN_PBLENDD256, UNKNOWN, (int) 
V8SI_FTYPE_V8SI_V8SI_INT)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3ab6b205eb6..efddcbdcc24 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -45980,6 +45980,7 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
{
  /* Use vpbroadcast{b,w,d}.  */
  rtx (*gen) (rtx, rtx) = NULL;
+ machine_mode scalar_mode = VOIDmode;
  switch (d->vmode)
{
case E_V64QImode:
@@ -46010,15 +46011,18 @@ expand_vec_perm_1 (struct expand_vec_perm_d *d)
  gen = gen_avx2_pbroadcastv8hi;
  break;
case E_V16SFmode:
+ scalar_mode = SFmode;
  if (TARGET_AVX512F)
-

Re: [C++ Patch] Remove quick fix for c++/85553

[Jakub Jelinek]

On Wed, Oct 17, 2018 at 07:20:53PM +0200, Paolo Carlini wrote:
> Hi,
> 
> as you probably remember, very close to the release of 8.1.0 we noticed that
> my fix for c++/70808 was causing c++/85553, which Jakub promptly fixed.
> However, we later found out that the real problem was a latent issue in
> convert, which I fixed in r259966. Thus, I think that in current trunk we
> can revert Jakub's quick fix, now redundant. Tested x86_64-linux.

Is there some desirable diagnostics you expect from the convert?
If not, build_int_cst is certainly cheaper.

> 2018-10-17  Paolo Carlini  
> 
>   * init.c (build_zero_init_1): Remove special casing for
>   NULLPTR_TYPE_P (type), introduced by r259728 and made
>   redundant by r259966.

> Index: init.c
> ===
> --- init.c(revision 265241)
> +++ init.c(working copy)
> @@ -180,10 +180,8 @@ build_zero_init_1 (tree type, tree nelts, bool sta
> items with static storage duration that are not otherwise
> initialized are initialized to zero.  */
>  ;
> -  else if (TYPE_PTR_OR_PTRMEM_P (type))
> +  else if (TYPE_PTR_OR_PTRMEM_P (type) || NULLPTR_TYPE_P (type))
>  init = fold (convert (type, nullptr_node));
> -  else if (NULLPTR_TYPE_P (type))
> -init = build_int_cst (type, 0);
>else if (SCALAR_TYPE_P (type))
>  init = fold (convert (type, integer_zero_node));
>else if (RECORD_OR_UNION_CODE_P (TREE_CODE (type)))


Jakub

[PATCH 2/2] Simplify subreg of vec_merge of vec_duplicate

[H.J. Lu]

We may simplify

  (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)

to X when mode of X is the same as of mode of subreg.

gcc/

PR target/87537
* simplify-rtx.c (simplify_subreg): Simplify subreg of vec_merge
of vec_duplicate.

gcc/testsuite/

PR target/87537
* gcc.target/i386/pr87537-1.c: New test.
---
 gcc/simplify-rtx.c| 11 +++
 gcc/testsuite/gcc.target/i386/pr87537-1.c | 12 
 2 files changed, 23 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr87537-1.c

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 9bc53866b9f..e2a0533b23d 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -6601,6 +6601,17 @@ simplify_subreg (machine_mode outermode, rtx op,
   return NULL_RTX;
 }
 
+  /* Return X for
+   (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
+   */
+  if (known_eq (byte, 0U)
+  && GET_CODE (op) == VEC_MERGE
+  && GET_CODE (XEXP (op, 0)) == VEC_DUPLICATE
+  && GET_MODE (XEXP (XEXP (op, 0), 0)) == outermode
+  && CONST_INT_P (XEXP (op, 2))
+  && INTVAL (XEXP (op, 2)) == 1)
+return XEXP (XEXP (op, 0), 0);
+
   /* A SUBREG resulting from a zero extension may fold to zero if
  it extracts higher bits that the ZERO_EXTEND's source bits.  */
   if (GET_CODE (op) == ZERO_EXTEND && SCALAR_INT_MODE_P (innermode))
diff --git a/gcc/testsuite/gcc.target/i386/pr87537-1.c 
b/gcc/testsuite/gcc.target/i386/pr87537-1.c
new file mode 100644
index 000..df849b032e7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr87537-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-mavx2 -O2" } */
+/* { dg-final { scan-assembler-times "vbroadcastss\[ 
\\t\]+\[^\{\n\]*%xmm\[0-9\]" 1 } } */
+/* { dg-final { scan-assembler-not "vmovss" } } */
+
+#include 
+
+__m128
+foo (float *x)
+{
+  return _mm_broadcastss_ps(_mm_load_ss(x));
+}
-- 
2.17.2

[C++ Patch] Remove quick fix for c++/85553

[Paolo Carlini]

Hi,

as you probably remember, very close to the release of 8.1.0 we noticed 
that my fix for c++/70808 was causing c++/85553, which Jakub promptly 
fixed. However, we later found out that the real problem was a latent 
issue in convert, which I fixed in r259966. Thus, I think that in 
current trunk we can revert Jakub's quick fix, now redundant. Tested 
x86_64-linux.


Thanks! Paolo.

//

2018-10-17  Paolo Carlini  

* init.c (build_zero_init_1): Remove special casing for
NULLPTR_TYPE_P (type), introduced by r259728 and made
redundant by r259966.
Index: init.c
===
--- init.c  (revision 265241)
+++ init.c  (working copy)
@@ -180,10 +180,8 @@ build_zero_init_1 (tree type, tree nelts, bool sta
items with static storage duration that are not otherwise
initialized are initialized to zero.  */
 ;
-  else if (TYPE_PTR_OR_PTRMEM_P (type))
+  else if (TYPE_PTR_OR_PTRMEM_P (type) || NULLPTR_TYPE_P (type))
 init = fold (convert (type, nullptr_node));
-  else if (NULLPTR_TYPE_P (type))
-init = build_int_cst (type, 0);
   else if (SCALAR_TYPE_P (type))
 init = fold (convert (type, integer_zero_node));
   else if (RECORD_OR_UNION_CODE_P (TREE_CODE (type)))

Fix PR middle-end/87623

[Eric Botcazou]

The compiler generates wrong code on the attached testcase using the 
scalar_storage_order attribute when optimization is enabled because it
respectively coaslesces the LHSes and the RHSes of the two consecutive 
comparisons without checking that both sides have same scalar storage order 
(but it does check that the two LHSes and the two RHSes respectively do).

The fix is trivial since the infrastructure is already present so I have 
applied it on all active branches as obvious after testing on x86-64/Linux.


2018-10-17  Eric Botcazou  

PR middle-end/87623
* fold-const.c (fold_truth_andor_1): If the right side is not constant,
bail out if both sides do not have the same storage order.


2018-10-17  Eric Botcazou  

* gcc.c-torture/execute/pr87623.c: New test.

-- 
Eric Botcazou/* PR middle-end/87623 */
/* Testcase by George Thopas  */

struct be {
unsigned short pad[1];
unsigned char  a;
unsigned char  b;
} __attribute__((scalar_storage_order("big-endian")));

typedef struct be t_be;

struct le {
unsigned short pad[3];
unsigned char  a;
unsigned char  b;
};

typedef struct le t_le;

int a_or_b_different(t_be *x,t_le *y)
{
   return (x->a != y->a) || (x->b != y->b);
}

int main (void)
{
   t_be x = { .a=1, .b=2  };
   t_le y = { .a=1, .b=2  };
  
   if (a_or_b_different(,))
   __builtin_abort ();

   return 0;
}
Index: fold-const.c
===
--- fold-const.c	(revision 265139)
+++ fold-const.c	(working copy)
@@ -6009,12 +6009,13 @@ fold_truth_andor_1 (location_t loc, enum
 }
 
   /* If the right sides are not constant, do the same for it.  Also,
- disallow this optimization if a size or signedness mismatch occurs
- between the left and right sides.  */
+ disallow this optimization if a size, signedness or storage order
+ mismatch occurs between the left and right sides.  */
   if (l_const == 0)
 {
   if (ll_bitsize != lr_bitsize || rl_bitsize != rr_bitsize
 	  || ll_unsignedp != lr_unsignedp || rl_unsignedp != rr_unsignedp
+	  || ll_reversep != lr_reversep
 	  /* Make sure the two fields on the right
 	 correspond to the left without being swapped.  */
 	  || ll_bitpos - rl_bitpos != lr_bitpos - rr_bitpos)

Re: [PATCH 2/2] Simplify subreg of vec_merge of vec_duplicate

[Richard Sandiford]

"H.J. Lu"  writes:
> We may simplify
>
>   (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
>
> to X when mode of X is the same as of mode of subreg.
>
> gcc/
>
>   PR target/87537
>   * simplify-rtx.c (simplify_subreg): Simplify subreg of vec_merge
>   of vec_duplicate.
>
> gcc/testsuite/
>
>   PR target/87537
>   * gcc.target/i386/pr87537-1.c: New test.
> ---
>  gcc/simplify-rtx.c| 11 +++
>  gcc/testsuite/gcc.target/i386/pr87537-1.c | 12 
>  2 files changed, 23 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr87537-1.c
>
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index 9bc53866b9f..e2a0533b23d 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -6601,6 +6601,17 @@ simplify_subreg (machine_mode outermode, rtx op,
>return NULL_RTX;
>  }
>  
> +  /* Return X for
> + (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
> +   */
> +  if (known_eq (byte, 0U)
> +  && GET_CODE (op) == VEC_MERGE
> +  && GET_CODE (XEXP (op, 0)) == VEC_DUPLICATE
> +  && GET_MODE (XEXP (XEXP (op, 0), 0)) == outermode
> +  && CONST_INT_P (XEXP (op, 2))
> +  && INTVAL (XEXP (op, 2)) == 1)
> +return XEXP (XEXP (op, 0), 0);

Would be good to handle the more general case of:

  unsigned int idx;
  if (constant_multiple_p (byte, GET_MODE_SIZE (outermode), )
  ...
  && (INTVAL (XEXP (op, 2)) & (HOST_WIDE_INT_1U << idx)) != 0)

(untested!)  Please also add some selftests to test_vector_ops.

Thanks,
Richard

Re: [C++ Patch, obvious] PR 84705 ("[6/7/8/9 Regression] internal compiler error: in add_stmt, at cp/semantics.c:390")

[Jason Merrill]

OK.
On Tue, Oct 16, 2018 at 5:16 PM Paolo Carlini  wrote:
>
> Hi,
>
> On 16/10/18 22:49, Jason Merrill wrote:
> > On Tue, Oct 16, 2018 at 2:39 PM Paolo Carlini  
> > wrote:
> >> the main issue is already fixed in trunk - we don't ICE anymore - but I
> >> noticed that for ill-formed code like:
> >>
> >>   int i = static_cast(i);
> >>
> >> we emit a duplicate diagnostic about the incomplete type d, easy to
> >> avoid by returning error_mark_node from
> >> perform_direct_initialization_if_possible when build_special_member_call
> >> returns it. I think this latter tweak qualifies as obvious, per a
> >> comment made by Jason a while ago...
> > Yes, but in this case it might be better to handle it in
> > build_cplus_new, to also cover other uses of that function.
>
> Ok... Then, I'm finishing testing the below. Thanks!
>
> Paolo.
>
> 
>

[PATCH v2] lra: fix spill_hard_reg_in_range clobber check

[Ilya Leoshkevich]

Boostrapped and regtested on x86_64-redhat-linux.

Changes since v1:

* Added the missing INSN_P () check.
* Rewrote the commit message.

FROM..TO range might contain NOTE_INSN_DELETED insns, for which the
corresponding entries in lra_insn_recog_data[] are NULLs.  Example from
the problematic code from PR87596:

(note 148 154 68 7 NOTE_INSN_DELETED)

lra_insn_recog_data[] is used directly only when the insn in question
is taken from insn_bitmap, which is not the case here.  In other
situations lra_get_insn_recog_data () guarded by INSN_P () or other
stricter predicate are used.  So we need to do this here as well.

A tiny detail worth noting: I put the INSN_P () check before the
insn_bitmap check, because I believe that insn_bitmap can contain only
real insns anyway.

gcc/ChangeLog:

2018-10-16  Ilya Leoshkevich  

PR rtl-optimization/87596
* lra-constraints.c (spill_hard_reg_in_range): Use INSN_P () +
lra_get_insn_recog_data () instead of lra_insn_recog_data[]
for instructions in FROM..TO range.

gcc/testsuite/ChangeLog:

2018-10-16  Ilya Leoshkevich  

PR rtl-optimization/87596
* gcc.target/i386/pr87596.c: New test.
---
 gcc/lra-constraints.c   |  9 ++---
 gcc/testsuite/gcc.target/i386/pr87596.c | 16 
 2 files changed, 22 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr87596.c

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 774d1ff3aaa..3cbe0465a87 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -5696,12 +5696,15 @@ spill_hard_reg_in_range (int regno, enum reg_class 
rclass, rtx_insn *from, rtx_i
continue;
   for (insn = from; insn != NEXT_INSN (to); insn = NEXT_INSN (insn))
{
- lra_insn_recog_data_t id = lra_insn_recog_data[uid = INSN_UID (insn)];
- struct lra_static_insn_data *static_id = id->insn_static_data;
+ struct lra_static_insn_data *static_id;
  struct lra_insn_reg *reg;
 
- if (bitmap_bit_p (_reg_info[hard_regno].insn_bitmap, uid))
+ if (!INSN_P (insn))
+ continue;
+ if (bitmap_bit_p (_reg_info[hard_regno].insn_bitmap,
+   INSN_UID (insn)))
break;
+ static_id = lra_get_insn_recog_data (insn)->insn_static_data;
  for (reg = static_id->hard_regs; reg != NULL; reg = reg->next)
if (reg->regno == hard_regno)
  break;
diff --git a/gcc/testsuite/gcc.target/i386/pr87596.c 
b/gcc/testsuite/gcc.target/i386/pr87596.c
new file mode 100644
index 000..764708b694a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr87596.c
@@ -0,0 +1,16 @@
+/* LRA corner case which triggered a segfault.  */
+/* Reduced testcase by Arseny Solokha.  */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O1 -fschedule-insns -ftrapv -funroll-all-loops 
-fno-tree-dominator-opts -fno-tree-loop-im" } */
+
+void
+wh (__int128 *ku)
+{
+  unsigned int *dp;
+
+  while (*ku < 1)
+{
+  *dp <<= 32;  /* { dg-warning "left shift count >= width of type" } */
+  ++*ku;
+}
+}
-- 
2.19.0

Re: [PATCH] __debug::list use C++11 direct initialization

[François Dumont]

I've just reverted the controversial changes.

2018-10-18  François Dumont  

    Partial revert.
    2018-10-08  François Dumont  

    * include/debug/list (list<>::cbegin()): Use C++11 direct
    initialization.
    (list<>::cend()): Likewise.
    (list<>::erase(const_iterator, const_iterator)): Ensure consistent
    iterator comparisons.
    (list<>::splice(const_iterator, list&&, const_iterator,
    const_iterator)): Likewise.

    Partial revert.
    2018-10-15  François Dumont  

    * include/debug/vector (vector<>::cbegin()): Use C++11 direct
    initialization.
    (vector<>::cend()): Likewise.
    (vector<>::insert(const_iterator, const _Tp&)): Use consistent
    iterator comparison.
    (vector<>::erase(const_iterator)): Likewise.
    (vector<>::erase(const_iterator, const_iterator)): Likewise.

François

On 10/17/2018 06:10 PM, Jonathan Wakely wrote:

On 17/10/18 17:03 +0100, Jonathan Wakely wrote:

On 09/10/18 07:11 +0200, François Dumont wrote:
Here is the communication for my yesterday's patch which I thought 
svn had failed to commit (I had to interrupt it).


Similarly to what I've done for associative containers here is a 
cleanup of the std::__debug::list implementation leveraging more on 
C++11 direct initialization.


I also made sure we use consistent comparison between 
iterator/const_iterator in erase and emplace methods.


2018-10-08  François Dumont 

    * include/debug/list (list<>::cbegin()): Use C++11 direct
    initialization.
    (list<>::cend()): Likewise.
    (list<>::emplace<>(const_iterator, _Args&&...)): Likewise.
    (list<>::insert(const_iterator, initializer_list<>)): Likewise.
    (list<>::insert(const_iterator, size_type, const _Tp&)): Likewise.
    (list<>::erase(const_iterator, const_iterator)): Ensure consistent
    iterator comparisons.
    (list<>::splice(const_iterator, list&&, const_iterator,
    const_iterator)): Likewise.

Tested under Linux x86_64 Debug mode and committed.

François



diff --git a/libstdc++-v3/include/debug/list 
b/libstdc++-v3/include/debug/list

index 8add1d596e0..879e1177497 100644
--- a/libstdc++-v3/include/debug/list
+++ b/libstdc++-v3/include/debug/list
@@ -521,15 +521,17 @@ namespace __debug
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 151. can't currently clear() empty container
__glibcxx_check_erase_range(__first, __last);
-    for (_Base_const_iterator __victim = __first.base();
+    for (__decltype(__first.base()) __victim = __first.base();


This change causes the regression.

I think the problem is that the decltype is a reference, so every time
the loop does ++__victim it changes the iterator stored in __first.



This would work:

   typedef typename __decltype(__first)::iterator_type _Base_iter;
for (_Base_iter __victim = __first.base();
 __victim != __last.base(); ++__victim)


Or simply:

#if __cplusplus >= 201103L
   typedef _Base_const_iterator _Base_iter;
#else
   typedef _Base_iterator _Base_iter;
#endif
for (_Base_iter __victim = __first.base();
 __victim != __last.base(); ++__victim)


Or just restore the original code which worked fine!

.



diff --git a/libstdc++-v3/include/debug/list b/libstdc++-v3/include/debug/list
index 879e1177497..aab146d058b 100644
--- a/libstdc++-v3/include/debug/list
+++ b/libstdc++-v3/include/debug/list
@@ -244,11 +244,11 @@ namespace __debug
 #if __cplusplus >= 201103L
   const_iterator
   cbegin() const noexcept
-  { return { _Base::begin(), this }; }
+  { return const_iterator(_Base::begin(), this); }
 
   const_iterator
   cend() const noexcept
-  { return { _Base::end(), this }; }
+  { return const_iterator(_Base::end(), this); }
 
   const_reverse_iterator
   crbegin() const noexcept
@@ -521,14 +521,13 @@ namespace __debug
 	// _GLIBCXX_RESOLVE_LIB_DEFECTS
 	// 151. can't currently clear() empty container
 	__glibcxx_check_erase_range(__first, __last);
-	for (__decltype(__first.base()) __victim = __first.base();
+	for (_Base_const_iterator __victim = __first.base();
 	 __victim != __last.base(); ++__victim)
 	  {
-	_GLIBCXX_DEBUG_VERIFY(
-		__victim != __first._M_get_sequence()->_M_base().end(),
-		_M_message(__gnu_debug::__msg_valid_range)
-		._M_iterator(__first, "position")
-		._M_iterator(__last, "last"));
+	_GLIBCXX_DEBUG_VERIFY(__victim != _Base::end(),
+  _M_message(__gnu_debug::__msg_valid_range)
+  ._M_iterator(__first, "position")
+  ._M_iterator(__last, "last"));
 	this->_M_invalidate_if(_Equal(__victim));
 	  }
 
@@ -622,14 +621,13 @@ namespace __debug
 	// We used to perform the splice_alloc check:  not anymore, redundant
 	// after implementing the relevant bits of N1599.
 
-	for (__decltype(__first.base()) __tmp = __first.base();
+	for (_Base_const_iterator __tmp = __first.base();
 	 __tmp != __last.base(); ++__tmp)
 	  {
-	_GLIBCXX_DEBUG_VERIFY(
-		__tmp != __first._M_get_sequence()->_M_base().end(),
-		_M_message(__gnu_debug::__msg_valid_range)
-		

[Patch, Fortan] PR 87632 - fix select type ICE

[Tobias Burnus]

Due to using the wrong variable, gfortran will segfault – as ref is 
always NULL.


Build and regtested on x86-64-gnu-linux.

Committed as obvious in Rev. 265248.

Tobias


	PR fortran/87632
	* resolve.c (resolve_select_type): Use correct variable.

	PR fortran/87632
	* gfortran.dg/select_type_47.f90: New.


diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 7c0381698cb..7ec9e969c71 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8914,7 +8914,7 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
   if (ref2)
 	{
 	  if (code->expr1->symtree->n.sym->attr.untyped)
-	code->expr1->symtree->n.sym->ts = ref->u.c.component->ts;
+	code->expr1->symtree->n.sym->ts = ref2->u.c.component->ts;
 	  selector_type = CLASS_DATA (ref2->u.c.component)->ts.u.derived;
 	}
   else
diff --git a/gcc/testsuite/gfortran.dg/select_type_47.f90 b/gcc/testsuite/gfortran.dg/select_type_47.f90
new file mode 100644
index 000..c7a750e35ac
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/select_type_47.f90
@@ -0,0 +1,59 @@
+! { dg-do compile }
+!
+! PR fortran/87632
+!
+! Contributed by Jürgen Reuter
+!
+module m
+type t
+  integer :: i
+end type t
+type t2
+  type(t) :: phs_config
+end type t2
+end module m
+
+module m2
+use m
+implicit none
+type t3
+end type t3
+
+type process_t
+  private
+  type(t2), allocatable :: component(:)
+contains
+  procedure :: get_phs_config => process_get_phs_config
+end type process_t
+
+contains
+  subroutine process_extract_resonance_history_set &
+   (process, include_trivial, i_component)
+class(process_t), intent(in), target :: process
+logical, intent(in), optional :: include_trivial
+integer, intent(in), optional :: i_component
+integer :: i
+i = 1;  if (present (i_component))  i = i_component
+select type (phs_config => process%get_phs_config (i))
+class is (t)
+   call foo()
+class default
+   call bar()
+end select
+  end subroutine process_extract_resonance_history_set
+
+  function process_get_phs_config (process, i_component) result (phs_config)
+class(t), pointer :: phs_config
+class(process_t), intent(in), target :: process
+integer, intent(in) :: i_component
+if (allocated (process%component)) then
+   phs_config => process%component(i_component)%phs_config
+else
+   phs_config => null ()
+end if
+  end function process_get_phs_config
+end module m2
+
+program main
+  use m2
+end program main

Re: [PATCH 2/2] Simplify subreg of vec_merge of vec_duplicate

[H.J. Lu]

On 10/17/18, Richard Sandiford  wrote:
> "H.J. Lu"  writes:
>> We may simplify
>>
>>   (subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
>>
>> to X when mode of X is the same as of mode of subreg.
>>
>> gcc/
>>
>>  PR target/87537
>>  * simplify-rtx.c (simplify_subreg): Simplify subreg of vec_merge
>>  of vec_duplicate.
>>
>> gcc/testsuite/
>>
>>  PR target/87537
>>  * gcc.target/i386/pr87537-1.c: New test.
>> ---
>>  gcc/simplify-rtx.c| 11 +++
>>  gcc/testsuite/gcc.target/i386/pr87537-1.c | 12 
>>  2 files changed, 23 insertions(+)
>>  create mode 100644 gcc/testsuite/gcc.target/i386/pr87537-1.c
>>
>> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
>> index 9bc53866b9f..e2a0533b23d 100644
>> --- a/gcc/simplify-rtx.c
>> +++ b/gcc/simplify-rtx.c
>> @@ -6601,6 +6601,17 @@ simplify_subreg (machine_mode outermode, rtx op,
>>return NULL_RTX;
>>  }
>>
>> +  /* Return X for
>> +(subreg (vec_merge (vec_duplicate X) (vector) (const_int 1)) 0)
>> +   */
>> +  if (known_eq (byte, 0U)
>> +  && GET_CODE (op) == VEC_MERGE
>> +  && GET_CODE (XEXP (op, 0)) == VEC_DUPLICATE
>> +  && GET_MODE (XEXP (XEXP (op, 0), 0)) == outermode
>> +  && CONST_INT_P (XEXP (op, 2))
>> +  && INTVAL (XEXP (op, 2)) == 1)
>> +return XEXP (XEXP (op, 0), 0);
>
> Would be good to handle the more general case of:
>
>   unsigned int idx;
>   if (constant_multiple_p (byte, GET_MODE_SIZE (outermode), )
>   ...
>   && (INTVAL (XEXP (op, 2)) & (HOST_WIDE_INT_1U << idx)) != 0)
>
> (untested!)  Please also add some selftests to test_vector_ops.
>

Like this?  OK for trunk?

Thanks.

-- 
H.J.
From 11baf753696ebf080270b445df701c716f786b76 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Wed, 10 Oct 2018 13:42:21 -0700
Subject: [PATCH] Simplify subreg of vec_merge of vec_duplicate

We can simplify

  (subreg (vec_merge (vec_duplicate X)
		 (vector)
		 (const_int ((1 << N) | M)))
	  (N * sizeof (X)))

to X when mode of X is the same as of mode of subreg.

gcc/

	PR target/87537
	* simplify-rtx.c (simplify_subreg): Simplify subreg of vec_merge
	of vec_duplicate.
	(test_vector_ops_duplicate): Add test for a scalar subreg of a
	VEC_MERGE of a VEC_DUPLICATE.

gcc/testsuite/

	PR target/87537
	* gcc.target/i386/pr87537-1.c: New test.
---
 gcc/simplify-rtx.c| 29 ++-
 gcc/testsuite/gcc.target/i386/pr87537-1.c | 12 ++
 2 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr87537-1.c

diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 9bc53866b9f..b0cf3bbb2a9 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -6601,6 +6601,21 @@ simplify_subreg (machine_mode outermode, rtx op,
   return NULL_RTX;
 }
 
+  /* Return X for
+	(subreg (vec_merge (vec_duplicate X)
+			   (vector)
+			   (const_int ((1 << N) | M)))
+		(N * sizeof (X)))
+   */
+  unsigned int idx;
+  if (constant_multiple_p (byte, GET_MODE_SIZE (outermode), )
+  && GET_CODE (op) == VEC_MERGE
+  && GET_CODE (XEXP (op, 0)) == VEC_DUPLICATE
+  && GET_MODE (XEXP (XEXP (op, 0), 0)) == outermode
+  && CONST_INT_P (XEXP (op, 2))
+  && (UINTVAL (XEXP (op, 2)) & (HOST_WIDE_INT_1U << idx)) != 0)
+return XEXP (XEXP (op, 0), 0);
+
   /* A SUBREG resulting from a zero extension may fold to zero if
  it extracts higher bits that the ZERO_EXTEND's source bits.  */
   if (GET_CODE (op) == ZERO_EXTEND && SCALAR_INT_MODE_P (innermode))
@@ -6831,15 +6846,27 @@ test_vector_ops_duplicate (machine_mode mode, rtx scalar_reg)
 		 simplify_binary_operation (VEC_SELECT, inner_mode,
 		duplicate, zero_par));
 
-  /* And again with the final element.  */
   unsigned HOST_WIDE_INT const_nunits;
   if (nunits.is_constant (_nunits))
 {
+  /* And again with the final element.  */
   rtx last_index = gen_int_mode (const_nunits - 1, word_mode);
   rtx last_par = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (1, last_index));
   ASSERT_RTX_PTR_EQ (scalar_reg,
 			 simplify_binary_operation (VEC_SELECT, inner_mode,
 		duplicate, last_par));
+
+  /* Test a scalar subreg of a VEC_MERGE of a VEC_DUPLICATE.  */
+  rtx vector_reg = make_test_reg (mode);
+  for (unsigned HOST_WIDE_INT i = 0; i < const_nunits; i++)
+	{
+	  rtx mask = GEN_INT ((HOST_WIDE_INT_1U << i) | (i + 1));
+	  rtx vm = gen_rtx_VEC_MERGE (mode, duplicate, vector_reg, mask);
+	  poly_uint64 offset = i * GET_MODE_SIZE (inner_mode);
+	  ASSERT_RTX_EQ (scalar_reg,
+			 simplify_gen_subreg (inner_mode, vm,
+	  mode, offset));
+	}
 }
 
   /* Test a scalar subreg of a VEC_DUPLICATE.  */
diff --git a/gcc/testsuite/gcc.target/i386/pr87537-1.c b/gcc/testsuite/gcc.target/i386/pr87537-1.c
new file mode 100644
index 000..df849b032e7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr87537-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { 

Add -std=c2x, -std=gnu2x, -Wc11-c2x-compat, C2X _Static_assert support

[Joseph Myers]

Now new features are starting to be added to a C2X draft (in the C2x
branch of the C standard git repository, no public WG14 document yet),
it's time to add -std=c2x and associated options to GCC for use in
enabling C2X features.

This patch adds the expected set of options: -std=c2x, -std=gnu2x,
-Wc11-c2x-compat.  A first C2X feature is added (the only one so far
in the repository that's obviously relevant to GCC): support (as in
C++) for the string constant to be omitted in _Static_assert.  This
feature is duly also supported as an extension in earlier standard
modes (diagnosed with -pedantic, unless -Wno-c11-c2x-compat is given,
or with -Wc11-c2x-compat even in C2X mode).

Bootstrapped with no regressions on x86_64-pc-linux-gnu.  Applied to 
mainline.

gcc/
2018-10-17  Joseph Myers  

* doc/cpp.texi (__STDC_VERSION__): Document C2X handling.
* doc/invoke.texi (-std=c2x, -std=gnu2x): Document new options.
* doc/standards.texi (C Language): Document C2X.
* dwarf2out.c (highest_c_language), config/rl78/rl78.c
(rl78_option_override): Handle "GNU C2X" language name.

gcc/c/
2018-10-17  Joseph Myers  

* c-errors.c (pedwarn_c11): New function.
* c-parser.c (disable_extension_diagnostics): Save
warn_c11_c2x_compat and set it to 0.
(restore_extension_diagnostics): Restore warn_c11_c2x_compat.
(c_parser_static_assert_declaration_no_semi): Handle
_Static_assert without string constant.
* c-tree.h (pedwarn_c11): New prototype.

gcc/c-family/
2018-10-17  Joseph Myers  

* c-common.c (flag_isoc2x): New variable.
* c-common.h (clk_c): Update comment to reference C2X.
(flag_isoc99, flag_isoc11): Update comments to reference future
standard versions in general.
(flag_isoc2x): Declare.
* c-opts.c (set_std_c2x): New function.
(c_common_handle_option): Handle -std=c2x and -std=gnu2x.
(set_std_c89, set_std_c99, set_std_c11, set_std_c17): Set
flag_isoc2x to 0.
* c.opt (Wc11-c2x-compat, std=c2x, std=gnu2x): New options.

gcc/testsuite/
2018-10-17  Joseph Myers  

* gcc.dg/c11-static-assert-7.c, gcc.dg/c11-static-assert-8.c,
gcc.dg/c11-static-assert-9.c, gcc.dg/c2x-static-assert-1.c,
gcc.dg/c2x-static-assert-2.c, gcc.dg/c99-static-assert-2.c,
gcc.dg/gnu2x-static-assert-1.c: New tests.
* gcc.dg/missing-symbol-3.c: Update expected fix-it text.

libcpp/
2018-10-17  Joseph Myers  

* include/cpplib.h (enum c_lang): Add CLK_GNUC2X and CLK_STDC2X.
* init.c (lang_defaults): Add GNUC2X and STDC2X entries.
(cpp_init_builtins): Define __STDC_VERSION__ to 202000L for C2X.

Index: gcc/c/c-errors.c
===
--- gcc/c/c-errors.c(revision 265250)
+++ gcc/c/c-errors.c(working copy)
@@ -25,6 +25,45 @@ along with GCC; see the file COPYING3.  If not see
 #include "c-tree.h"
 #include "opts.h"
 
+/* Issue an ISO C11 pedantic warning MSGID if -pedantic outside C2X mode,
+   otherwise issue warning MSGID if -Wc11-c2X-compat is specified.
+   This function is supposed to be used for matters that are allowed in
+   ISO C2X but not supported in ISO C11, thus we explicitly don't pedwarn
+   when C2X is specified.  */
+
+bool
+pedwarn_c11 (location_t location, int opt, const char *gmsgid, ...)
+{
+  diagnostic_info diagnostic;
+  va_list ap;
+  bool warned = false;
+  rich_location richloc (line_table, location);
+
+  va_start (ap, gmsgid);
+  /* If desired, issue the C11/C2X compat warning, which is more specific
+ than -pedantic.  */
+  if (warn_c11_c2x_compat > 0)
+{
+  diagnostic_set_info (, gmsgid, , ,
+  (pedantic && !flag_isoc2x)
+  ? DK_PEDWARN : DK_WARNING);
+  diagnostic.option_index = OPT_Wc11_c2x_compat;
+  warned = diagnostic_report_diagnostic (global_dc, );
+}
+  /* -Wno-c11-c2x-compat suppresses even the pedwarns.  */
+  else if (warn_c11_c2x_compat == 0)
+;
+  /* For -pedantic outside C2X, issue a pedwarn.  */
+  else if (pedantic && !flag_isoc2x)
+{
+  diagnostic_set_info (, gmsgid, , , DK_PEDWARN);
+  diagnostic.option_index = opt;
+  warned = diagnostic_report_diagnostic (global_dc, );
+}
+  va_end (ap);
+  return warned;
+}
+
 /* Issue an ISO C99 pedantic warning MSGID if -pedantic outside C11 mode,
otherwise issue warning MSGID if -Wc99-c11-compat is specified.
This function is supposed to be used for matters that are allowed in
Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c(revision 265250)
+++ gcc/c/c-parser.c(working copy)
@@ -1327,6 +1327,9 @@ disable_extension_diagnostics (void)
 /* Similarly for warn_c99_c11_compat.  */
 | ((warn_c99_c11_compat == 1) << 9)
 | ((warn_c99_c11_compat == -1) << 10)
+/* 

Re: C++: is there a good way to check for a valid no-op conversion?

[Martin Sebor]

On 10/16/2018 02:06 PM, David Malcolm wrote:

I've been extending -fopt-info to cover inlining, and I added a %S
format code to dump_printf which accepts a symtab_node *.

Unfortunately, -Wformat doesn't like the fact that I'm passing in a
subclass pointer (cgraph_node *), e.g.:

ipa-inline.c: In function ‘unsigned int early_inliner(function*)’:
ipa-inline.c:2769:21: error: format ‘%S’ expects argument of type 
‘symtab_node*’,
but argument 3 has type ‘cgraph_node*’ [-Werror=format=]
2769 |"Flattening %S\n", node);
  |~^ 
  | | |
  | | cgraph_node*
  | symtab_node*

I could fix this by changing my format converter so that explicitly
takes a cgraph_node *, but I wondered if it would be better to instead
teach -Wformat to accept non-virtual subclass pointers, so that %S can
handle symtab_node * and its two subclasses.


It would have helped in the gcall* vs gimple* case as well.  It
would be nice to teach -Wformat about these conversions in general.
(on a somewhat related note, other than pedantic conformance, I
don't think there is value in -Wformat complaining about %p with
non-void* object pointer arguments either).

Martin



Does this sound sane, and is there a conversion function I can call for
this case?  cp_convert_to_pointer seemed the closest match.

Thanks
Dave

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

[Giuliano Augusto Faulin Belinassi]

Oh, please note that the error that I'm talking about is the
comparison with the result obtained before and after the
simplification. It is possible that the result obtained after the
simplification be more precise when compared to an arbitrary precise
value (example, a 30 digits precise approximation). Well, I will try
check that.

But yes, with regard to compatibility this may be a problem.
On Wed, Oct 17, 2018 at 6:42 PM Jeff Law  wrote:
>
> On 10/17/18 3:25 PM, Giuliano Augusto Faulin Belinassi wrote:
> >> Hmm, do we have problems as we get close to -1 or 1 where the outputs of
> >> the two forms might diverge?
> >
> > Well, I did some minor testing with that with input x around nextafter(1, 
> > -1);
> > There are a minor imprecision when comparing directly with
> > sinh(atanh(x)) and cosh(atanh(x)).
> >   * On 32-bits floats, for such x the error is about 10^-4
> >   * On 64-bits floats, for such x the error is about 10^-7
> >   * On 80-bits floats, for such x the error is about 10^-9
> >
> > here are the code that I used for the test: https://pastebin.com/JzYZyigQ
> >
> > I can create a testcase based on this if needed :-)
> My gut instinct is those errors are too significant in practice.
>
> It also just occurred to me that we may have problems as X approaches X
> from either direction.
>
> Clearly when x^2 is indistinguishable from 0 or 1, then the result has
> to be +-0 or +-1.  But I'm not sure if figuring out where those points
> are is sufficient to avoid the imprecisions noted above.  This is *well*
> outside my areas of expertise.
>
> jeff

[C++ PATCH] Allow __ prefix+suffix on C++11 attribute namespaces (PR c++/86288)

[Jakub Jelinek]

Hi!

As mentioned in the PR, for use in headers for the same reason like we
support __aligned__ form next to aligned (user defining such a macro) this
patch allows to mangle the scope the same way.

In addition to that, it fixes an ICE, where because we didn't canonicalize
the attribute name in [[using gnu : __aligned__(4)]] we'd ICE on some of the
GNU attributes.

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

Is a partial backport (just add
  attr_id = canonicalize_attr_name (attr_id);
in the else if (attr_ns) case plus the non-__gnu__ lines from the testcase)
ok for 7/8 release branches where it ICEs?

2018-10-18  Jakub Jelinek  

PR c++/86288
* parser.c (cp_parser_std_attribute): Canonicalize attr_ns, and when
:: is not present and attr_ns non-NULL, canonicalize also attr_id.
(cp_parser_attribute_spec): Fix comment typo.

* g++.dg/cpp0x/gen-attrs-66.C: New test.

--- gcc/cp/parser.c.jj  2018-10-15 18:05:42.562236914 +0200
+++ gcc/cp/parser.c 2018-10-17 14:45:25.205543993 +0200
@@ -25327,14 +25327,19 @@ cp_parser_std_attribute (cp_parser *pars
  return error_mark_node;
}
 
+  attr_ns = canonicalize_attr_name (attr_ns);
   attr_id = canonicalize_attr_name (attr_id);
   attribute = build_tree_list (build_tree_list (attr_ns, attr_id),
   NULL_TREE);
   token = cp_lexer_peek_token (parser->lexer);
 }
   else if (attr_ns)
-attribute = build_tree_list (build_tree_list (attr_ns, attr_id),
-NULL_TREE);
+{
+  attr_ns = canonicalize_attr_name (attr_ns);
+  attr_id = canonicalize_attr_name (attr_id);
+  attribute = build_tree_list (build_tree_list (attr_ns, attr_id),
+  NULL_TREE);
+}
   else
 {
   attr_id = canonicalize_attr_name (attr_id);
@@ -25526,7 +25531,7 @@ cp_parser_std_attribute_spec (cp_parser
  || !cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE))
cp_parser_skip_to_end_of_statement (parser);
   else
-   /* Warn about parsing c++11 attribute in non-c++1 mode, only
+   /* Warn about parsing c++11 attribute in non-c++11 mode, only
   when we are sure that we have actually parsed them.  */
maybe_warn_cpp0x (CPP0X_ATTRIBUTES);
 }
--- gcc/testsuite/g++.dg/cpp0x/gen-attrs-66.C.jj2018-10-17 
14:47:15.493686357 +0200
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-66.C   2018-10-17 15:00:30.450240982 
+0200
@@ -0,0 +1,12 @@
+// PR c++/86288
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wattributes" }
+
+int a [[gnu::aligned(alignof(int))]];
+int b [[gnu::__aligned__(alignof(int))]];
+int c [[__gnu__::aligned(alignof(int))]];
+int d [[__gnu__::__aligned__(alignof(int))]];
+int e [[using gnu : aligned(alignof(int))]];   // { dg-warning 
"attribute using prefix only available" "" { target c++14_down } }
+int f [[using gnu : __aligned__(alignof(int))]];   // { dg-warning 
"attribute using prefix only available" "" { target c++14_down } }
+int g [[using __gnu__ : aligned(alignof(int))]];   // { dg-warning 
"attribute using prefix only available" "" { target c++14_down } }
+int h [[using __gnu__ : __aligned__(alignof(int))]];   // { dg-warning 
"attribute using prefix only available" "" { target c++14_down } }

Jakub

Re: [PATCH] add udivhi3, umodhi3 functions to libgcc

[Paul Koning]

This is a revision of a patch I proposed a while back, to add udivhi3 and 
umodhi3 functions to libgcc since some platforms (like pdp11) need it.  The 
code is adopted from that of udivsi3.

In earlier discussion it was pointed out that internal functions need to start 
with __.  The code I had copied does not do that, so I corrected mine and also 
changed the existing code to conform to the rules.

Ok for trunk?

paul

ChangeLog:

2018-10-17  Paul Koning  

* udivmodsi4.c (__udivmodsi4): Rename to conform to coding
standard.
* udivmod.c: Update references to __udivmodsi4.
* udivhi3.c: New file.
* udivmodhi4.c: New file.
* config/pdp11/t-pdp11 (LIB2ADD): Add the new files.

Index: config/pdp11/t-pdp11
===
--- config/pdp11/t-pdp11(revision 265151)
+++ config/pdp11/t-pdp11(working copy)
@@ -1,5 +1,7 @@
 LIB2ADD = $(srcdir)/udivmod.c \
  $(srcdir)/udivmodsi4.c \
+ $(srcdir)/udivhi3.c \
+ $(srcdir)/udivmodhi4.c \
  $(srcdir)/memcmp.c \
  $(srcdir)/memcpy.c \
  $(srcdir)/memmove.c \
Index: udivhi3.c
===
--- udivhi3.c   (nonexistent)
+++ udivhi3.c   (working copy)
@@ -0,0 +1,38 @@
+/* Copyright (C) 2000-2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+extern unsigned short __udivmodhi4(unsigned short num, unsigned short den,
+  int 
modwanted);
+
+unsigned short
+__udivhi3 (unsigned short a, unsigned short b)
+{
+  return __udivmodhi4 (a, b, 0);
+}
+
+unsigned short
+__umodhi3 (unsigned short a, unsigned short b)
+{
+  return __udivmodhi4 (a, b, 1);
+}
+
Index: udivmod.c
===
--- udivmod.c   (revision 265151)
+++ udivmod.c   (working copy)
@@ -21,17 +21,18 @@ a copy of the GCC Runtime Library Exception along
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
-long udivmodsi4 ();
+extern unsigned long __udivmodsi4(unsigned long num, unsigned long den,
+ int 
modwanted);
 
 long
 __udivsi3 (long a, long b)
 {
-  return udivmodsi4 (a, b, 0);
+  return __udivmodsi4 (a, b, 0);
 }
 
 long
 __umodsi3 (long a, long b)
 {
-  return udivmodsi4 (a, b, 1);
+  return __udivmodsi4 (a, b, 1);
 }
 
Index: udivmodhi4.c
===
--- udivmodhi4.c(nonexistent)
+++ udivmodhi4.c(working copy)
@@ -0,0 +1,47 @@
+/* Copyright (C) 2000-2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+unsigned short
+__udivmodhi4(unsigned short num, unsigned short den, int modwanted)
+{
+  unsigned short bit = 1;
+  unsigned short res = 0;
+
+  while (den < num && bit && !(den & (1L<<31)))
+{
+  den <<=1;
+  bit <<=1;
+}
+  while (bit)
+{
+  if (num >= den)
+   {
+ num -= den;
+ res |= bit;
+   }
+  bit >>=1;
+  den >>=1;
+}
+  if (modwanted) return 

PATCH to enable testing C++17 by default

[Marek Polacek]

As discussed in  it
seems to be a high time we turned on testing C++17 by default.

The only interesting part is at the very end, otherwise most of the changes is
just using { target c++17 } instead of explicit dg-options.  Removing
dg-options has the effect that DEFAULT_CXXFLAGS comes in play, so I've removed
a bunch of stray semicolons to fix -Wpedantic errors.

I wonder if we also want to enable 2a, but the overhead could be too much.  Or
use 2a instead of 17?

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

2018-10-17  Marek Polacek  

* g++.dg/*.C: Use target c++17 instead of explicit dg-options.
* lib/g++-dg.exp: Don't test C++11 by default.  Add C++17 to
the list of default stds to test.

diff --git gcc/testsuite/g++.dg/concepts/alias1.C 
gcc/testsuite/g++.dg/concepts/alias1.C
index 1b643cdd1c9..279a4787576 100644
--- gcc/testsuite/g++.dg/concepts/alias1.C
+++ gcc/testsuite/g++.dg/concepts/alias1.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template
   concept bool C() { return __is_class(T); }
diff --git gcc/testsuite/g++.dg/concepts/alias2.C 
gcc/testsuite/g++.dg/concepts/alias2.C
index 2de2aa4da94..06ffb1af529 100644
--- gcc/testsuite/g++.dg/concepts/alias2.C
+++ gcc/testsuite/g++.dg/concepts/alias2.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template
   concept bool C() { return __is_class(T); }
diff --git gcc/testsuite/g++.dg/concepts/alias3.C 
gcc/testsuite/g++.dg/concepts/alias3.C
index 6e1c39ce174..2901c041881 100644
--- gcc/testsuite/g++.dg/concepts/alias3.C
+++ gcc/testsuite/g++.dg/concepts/alias3.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template
   concept bool C() { return __is_class(T); }
diff --git gcc/testsuite/g++.dg/concepts/alias4.C 
gcc/testsuite/g++.dg/concepts/alias4.C
index e7d93d5875f..2c9f5defeb0 100644
--- gcc/testsuite/g++.dg/concepts/alias4.C
+++ gcc/testsuite/g++.dg/concepts/alias4.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template
   concept bool C() { return __is_class(T); }
diff --git gcc/testsuite/g++.dg/concepts/auto1.C 
gcc/testsuite/g++.dg/concepts/auto1.C
index 0c6fa465fa6..2682940cedd 100644
--- gcc/testsuite/g++.dg/concepts/auto1.C
+++ gcc/testsuite/g++.dg/concepts/auto1.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template  class A { };
 
diff --git gcc/testsuite/g++.dg/concepts/auto3.C 
gcc/testsuite/g++.dg/concepts/auto3.C
index 7b80fe314b8..abfb2019125 100644
--- gcc/testsuite/g++.dg/concepts/auto3.C
+++ gcc/testsuite/g++.dg/concepts/auto3.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template  class tuple {};
 
diff --git gcc/testsuite/g++.dg/concepts/auto4.C 
gcc/testsuite/g++.dg/concepts/auto4.C
index e80341ec038..4eb2ae8f7d5 100644
--- gcc/testsuite/g++.dg/concepts/auto4.C
+++ gcc/testsuite/g++.dg/concepts/auto4.C
@@ -1,5 +1,6 @@
 // PR c++/85006
-// { dg-additional-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-additional-options "-fconcepts" }
 
 template struct A {};
 
diff --git gcc/testsuite/g++.dg/concepts/class-deduction1.C 
gcc/testsuite/g++.dg/concepts/class-deduction1.C
index 476830d9252..936dd6826f0 100644
--- gcc/testsuite/g++.dg/concepts/class-deduction1.C
+++ gcc/testsuite/g++.dg/concepts/class-deduction1.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template 
 concept bool Isint = __is_same_as(T,int);
diff --git gcc/testsuite/g++.dg/concepts/class-deduction2.C 
gcc/testsuite/g++.dg/concepts/class-deduction2.C
index 286e59a5039..e0718d1d0cf 100644
--- gcc/testsuite/g++.dg/concepts/class-deduction2.C
+++ gcc/testsuite/g++.dg/concepts/class-deduction2.C
@@ -1,5 +1,6 @@
 // PR c++/85706
-// { dg-additional-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-additional-options "-fconcepts" }
 
 template struct S {
   S(T);
diff --git gcc/testsuite/g++.dg/concepts/class.C 
gcc/testsuite/g++.dg/concepts/class.C
index 1c5242f8089..dc5523e2407 100644
--- gcc/testsuite/g++.dg/concepts/class.C
+++ gcc/testsuite/g++.dg/concepts/class.C
@@ -1,4 +1,5 @@
-// { dg-options "-std=c++17 -fconcepts" }
+// { dg-do compile { target c++17 } }
+// { dg-options "-fconcepts" }
 
 template
   concept bool Class() { return __is_class(T); }
diff --git gcc/testsuite/g++.dg/concepts/class1.C 
gcc/testsuite/g++.dg/concepts/class1.C
index 94a5d23a873..a738e6e82cd 100644
--- 

Re: Update manual references for C17 having been published

[Jakub Jelinek]

On Wed, Oct 17, 2018 at 09:33:44PM +, Joseph Myers wrote:
> This patch makes references in the manual to C17 reflect it having
> been published in July 2018.  (For the reasons it took so long to get
> to ballot and publication, see the WG14 convenor's report to the last
> SC22 plenary - SC22 N5297 - where it references "A troubling new trend
> where ISO CS has begun enforcing undocumented rules that are approved
> neither by the TMB nor by the WG 14 editors, leading to a decrease in
> the usefulness of standards documents.".)
> 
> Tested with "make info html pdf".  Applied to mainline.
> 
> 2018-10-17  Joseph Myers  
> 
>   * doc/invoke.texi (-std=c17), doc/standards.texi (C Language):
>   Document C17 as published in 2018.

What about c-family/c.opt ?
std=c17
C ObjC
Conform to the ISO 2017 C standard (expected to be published in 2018).

std=c18
C ObjC Alias(std=c17)
Conform to the ISO 2017 C standard (expected to be published in 2018).

std=iso9899:2017
C ObjC Alias(std=c17)
Conform to the ISO 2017 C standard (expected to be published in 2018).

std=iso9899:2018
C ObjC Alias(std=c17)
Conform to the ISO 2017 C standard (expected to be published in 2018).

Shouldn't that be adjusted too?

Jakub

Re: [Patch, Fortan] PR 87632 - fix select type ICE

[Paul Richard Thomas]

Hi Tobias,

Thanks for taking care of that so quickly. Juergen is proving to be a
loyal friend to gfortran by coming back to us so quickly on
regressions and reducing testcases. He deserves a good service.

Cheers

Paul

On Wed, 17 Oct 2018 at 20:59, Tobias Burnus  wrote:
>
> Due to using the wrong variable, gfortran will segfault – as ref is
> always NULL.
>
> Build and regtested on x86-64-gnu-linux.
>
> Committed as obvious in Rev. 265248.
>
> Tobias
>


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: PATCH to enable testing C++17 by default

[Jeff Law]

On 10/17/18 1:31 PM, Marek Polacek wrote:
> As discussed in  it
> seems to be a high time we turned on testing C++17 by default.
> 
> The only interesting part is at the very end, otherwise most of the changes is
> just using { target c++17 } instead of explicit dg-options.  Removing
> dg-options has the effect that DEFAULT_CXXFLAGS comes in play, so I've removed
> a bunch of stray semicolons to fix -Wpedantic errors.
> 
> I wonder if we also want to enable 2a, but the overhead could be too much.  Or
> use 2a instead of 17?
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2018-10-17  Marek Polacek  
> 
>   * g++.dg/*.C: Use target c++17 instead of explicit dg-options.
>   * lib/g++-dg.exp: Don't test C++11 by default.  Add C++17 to
>   the list of default stds to test.Given this follows Jason's 
> recommendations from the thread, OK for the
trunk.

I'll leave it up to Jason to decide when to add 2a and whether or not to
drop something at that time.

jeff

Re: [PATCH v5 01/10] Initial TI PRU GCC port

[Richard Sandiford]

Hi Dimitar,

Thanks for the updates, looks good.  Just a few minor things:

Dimitar Dimitrov  writes:
> +(define_predicate "pru_muldst_operand"
> +  (match_code "subreg,reg")
> +{
> +  if (register_operand (op, mode))
> +{
> +  int regno;
> +
> +  if (REG_P (op))
> + regno = REGNO (op);
> +  else if (GET_CODE (op) == SUBREG && REG_P (SUBREG_REG (op)))
> + regno = REGNO (SUBREG_REG (op));
> +  else
> + return 0;
> +
> +
> +  return REGNO_REG_CLASS (regno) == MULDST_REGS
> +  || regno >= FIRST_PSEUDO_REGISTER;
> +}
> +  return 0;
> +})
> +
> +(define_predicate "pru_mulsrc0_operand"
> +  (match_code "subreg,reg")
> +{
> +  if (register_operand (op, mode))
> +{
> +  int regno;
> +
> +  if (REG_P (op))
> + regno = REGNO (op);
> +  else if (GET_CODE (op) == SUBREG && REG_P (SUBREG_REG (op)))
> + regno = REGNO (SUBREG_REG (op));
> +  else
> + return 0;
> +
> +
> +  return REGNO_REG_CLASS (regno) == MULSRC0_REG
> +  || regno >= FIRST_PSEUDO_REGISTER;
> +}
> +  return 0;
> +})
> +
> +(define_predicate "pru_mulsrc1_operand"
> +  (match_code "subreg,reg")
> +{
> +  if (register_operand (op, mode))
> +{
> +  int regno;
> +
> +  if (REG_P (op))
> + regno = REGNO (op);
> +  else if (GET_CODE (op) == SUBREG && REG_P (SUBREG_REG (op)))
> + regno = REGNO (SUBREG_REG (op));
> +  else
> + return 0;
> +
> +
> +  return REGNO_REG_CLASS (regno) == MULSRC1_REG
> +  || regno >= FIRST_PSEUDO_REGISTER;
> +}
> +  return 0;
> +})

Some doubled empty lines here.

> +; Note: "JUMP_INSNs and CALL_INSNs are not allowed to have any output
> +; reloads;".  Hence this insn must be prepared for a counter that is
> +; not a register.
> +(define_insn "doloop_end_internal"
> +  [(set (pc)
> + (if_then_else (ne (match_operand:HISI 0 "nonimmediate_operand" "+r,*m")
> +   (const_int 1))
> +   (label_ref (match_operand 1 "" ""))
> +   (pc)))
> +   (set (match_dup 0)
> + (plus:HISI (match_dup 0)
> +  (const_int -1)))
> +   (unspec [(match_operand 2 "const_int_operand" "")] UNSPECV_LOOP_END)
> +   (clobber (match_scratch:HISI 3 "=X,"))]
> +  ""
> +{
> +  gcc_unreachable ();
> +}
> +  ;; Worst case length:
> +  ;;
> +  ;;   lbbo op3_reg, op3_ptr   4'
> +  ;;   sub , 14
> +  ;;   qbeq .+8, , 0  4
> +  ;;   jmp4
> +  ;;   sbbo op3_reg, op3_ptr   4
> +  [(set (attr "length")
> +  (if_then_else
> + (and (ge (minus (pc) (match_dup 1)) (const_int 0))
> +  (le (minus (pc) (match_dup 1)) (const_int 1020)))
> + (cond [(eq_attr "alternative" "0") (const_int 4)
> +(eq_attr "alternative" "0") (const_int 12)]
> +(const_int 4))
> + (cond [(eq_attr "alternative" "0") (const_int 12)
> +(eq_attr "alternative" "0") (const_int 20)]
> +(const_int 4])

The second (eq_attr "alternative" "0") lines in each (cond ...)
won't be used, since the first match wins.

> +mno-relax
> +Target Report RejectNegative
> +Make GCC pass --no-relax command-line option to the linker instead of
> +the --relax option.

A couple of missing "the"s:

  Make GCC pass the --no-relax command-line option to the linker instead
  of the --relax option

> +Link with a minimum runtime environment, with no support for static
> +initializers and constructors.  Using this option can significantly reduce
> +the size of the final ELF binary.  Beware that compiler could still generate

Sorry, this was my fault, should be:

  s/that compiler/that the compiler/

> +@item -mno-relax
> +@opindex mno-relax
> +Make GCC pass @option{--no-relax} command-line option to the linker
> +instead of the @option{--relax} option.

Missing "the" before "@option{--no-relax}"

OK with those changes once the port is accepted.  (No need to repost,
just fix up locally and commit the fixed version when the time comes.)

Jeff, could you ask the SC about accepting the port, if that hasn't
already been decided?  Dimitar, I assume you'd be OK with being the
maintainer?

Thanks,
Richard

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

[Giuliano Augusto Faulin Belinassi]

> Hmm, do we have problems as we get close to -1 or 1 where the outputs of
> the two forms might diverge?

Well, I did some minor testing with that with input x around nextafter(1, -1);
There are a minor imprecision when comparing directly with
sinh(atanh(x)) and cosh(atanh(x)).
  * On 32-bits floats, for such x the error is about 10^-4
  * On 64-bits floats, for such x the error is about 10^-7
  * On 80-bits floats, for such x the error is about 10^-9

here are the code that I used for the test: https://pastebin.com/JzYZyigQ

I can create a testcase based on this if needed :-)

Update manual references for C17 having been published

[Joseph Myers]

This patch makes references in the manual to C17 reflect it having
been published in July 2018.  (For the reasons it took so long to get
to ballot and publication, see the WG14 convenor's report to the last
SC22 plenary - SC22 N5297 - where it references "A troubling new trend
where ISO CS has begun enforcing undocumented rules that are approved
neither by the TMB nor by the WG 14 editors, leading to a decrease in
the usefulness of standards documents.".)

Tested with "make info html pdf".  Applied to mainline.

2018-10-17  Joseph Myers  

* doc/invoke.texi (-std=c17), doc/standards.texi (C Language):
Document C17 as published in 2018.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 265248)
+++ gcc/doc/invoke.texi (working copy)
@@ -1927,8 +1927,8 @@
 @itemx c18
 @itemx iso9899:2017
 @itemx iso9899:2018
-ISO C17, the 2017 revision of the ISO C standard (expected to be
-published in 2018).  This standard is
+ISO C17, the 2017 revision of the ISO C standard
+(published in 2018).  This standard is
 same as C11 except for corrections of defects (all of which are also
 applied with @option{-std=c11}) and a new value of
 @code{__STDC_VERSION__}, and so is supported to the same extent as C11.
Index: gcc/doc/standards.texi
===
--- gcc/doc/standards.texi  (revision 265248)
+++ gcc/doc/standards.texi  (working copy)
@@ -102,7 +102,8 @@
 standard version were referred to as @dfn{C1X}.)
 GCC has substantially complete support
 for this standard, enabled with @option{-std=c11} or
-@option{-std=iso9899:2011}.  A version with corrections integrated is
+@option{-std=iso9899:2011}.  A version with corrections integrated was
+prepared in 2017 and published in 2018 as ISO/IEC 9899:2018; it is
 known as @dfn{C17} and is supported with @option{-std=c17} or
 @option{-std=iso9899:2017}; the corrections are also applied with
 @option{-std=c11}, and the only difference between the options is the

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

Re: [C++ Patch] Remove quick fix for c++/85553

[Paolo Carlini]

Hi Jakub,

On 17/10/18 19:42, Jakub Jelinek wrote:

On Wed, Oct 17, 2018 at 07:20:53PM +0200, Paolo Carlini wrote:

Hi,

as you probably remember, very close to the release of 8.1.0 we noticed that
my fix for c++/70808 was causing c++/85553, which Jakub promptly fixed.
However, we later found out that the real problem was a latent issue in
convert, which I fixed in r259966. Thus, I think that in current trunk we
can revert Jakub's quick fix, now redundant. Tested x86_64-linux.

Is there some desirable diagnostics you expect from the convert?
If not, build_int_cst is certainly cheaper.


No, no diagnostics. But I'm still a bit nervous about the various way we 
handle those zero-initializations for pointer-ish types. Which is, if 
you wish, what fooled me in the first place when I simply assumed that 
convert was able to cope with the easy nullptr_node case. Say we do 
something like the below, can you see something wrong with it? Only 
lightly tested so far but appears to work fine at least on x86_64...


Thanks, Paolo.

///

Index: init.c
===
--- init.c  (revision 265241)
+++ init.c  (working copy)
@@ -180,10 +180,10 @@ build_zero_init_1 (tree type, tree nelts, bool sta
items with static storage duration that are not otherwise
initialized are initialized to zero.  */
 ;
-  else if (TYPE_PTR_OR_PTRMEM_P (type))
+  else if (TYPE_PTR_P (type) || NULLPTR_TYPE_P (type))
+init = build_int_cst (type, 0);
+  else if (TYPE_PTRMEM_P (type))
 init = fold (convert (type, nullptr_node));
-  else if (NULLPTR_TYPE_P (type))
-init = build_int_cst (type, 0);
   else if (SCALAR_TYPE_P (type))
 init = fold (convert (type, integer_zero_node));
   else if (RECORD_OR_UNION_CODE_P (TREE_CODE (type)))

Re: [Patch, fortran] PR58618 - Wrong code with character substring and ASSOCIATE

[Tobias Burnus]

Hi Paul,

Paul Richard Thomas wrote:

This problem concerned associate targets being substrings. It turns
out that they are returned as pointer types (with a different cast for
unity based substrings ***sigh***) and so can be assigned directly to
the associate name. The patch quite simply removed the condition that
such targets be allocatable, pointer or dummy.
I noticed in the course of working up the testcase that
 character (:), pointer :: ptr => NULL()
 character (6), target :: tgt = 'lmnopq'
 ptr => tgt
 print *, len (ptr), ptr
end
ICEs on the NULL initialization of the pointer but works fine if this
is removed. Has this already been posted as a PR?



I leave it to Dominique to search for a PR; otherwise, I believe the 
attach patch fixes the issue. – It just needs someone to package it with 
a test case, regtest and commit it.




Bootstrapped and regtested on FC28/x86_64 - OK for trunk?


OK – thanks for the fix.

Tobias


2018-10-17  Paul Thomas  

 PR fortran/58618
 * trans-stmt.c (trans_associate_var): All strings that return
 as pointer types can be assigned directly to the associate
 name so remove 'attr' and the condition that uses it.

2018-10-17  Paul Thomas  

 PR fortran/58618
 * gfortran.dg/associate_45.f90 : New test.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index b0c12e5fc38..88f9f570725 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1762,7 +1762,8 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   gfc_finish_var_decl (length, sym);
   if (!sym->attr.associate_var
 	  && TREE_CODE (length) == VAR_DECL
-	  && sym->value && sym->value->ts.u.cl->length)
+	  && sym->value && sym->value->expr_type != EXPR_NULL
+	  && sym->value->ts.u.cl->length)
 	{
 	  gfc_expr *len = sym->value->ts.u.cl->length;
 	  DECL_INITIAL (length) = gfc_conv_initializer (len, >ts,
@@ -1772,7 +1773,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
 		DECL_INITIAL (length));
 	}
   else
-	gcc_assert (!sym->value);
+	gcc_assert (!sym->value || sym->value->expr_type == EXPR_NULL);
 }
 
   gfc_finish_var_decl (decl, sym);

Re: Update manual references for C17 having been published

[Joseph Myers]

Updates to c.opt now committed as well.

2018-10-17  Joseph Myers  

* c.opt (std=c17, std=c18, std=gnu17, std=gnu18, std=iso9899:2017)
(std=iso9899:2018): Document C17 as published in 2018.

Index: c-family/c.opt
===
--- c-family/c.opt  (revision 265249)
+++ c-family/c.opt  (working copy)
@@ -1992,11 +1992,11 @@
 
 std=c17
 C ObjC
-Conform to the ISO 2017 C standard (expected to be published in 2018).
+Conform to the ISO 2017 C standard (published in 2018).
 
 std=c18
 C ObjC Alias(std=c17)
-Conform to the ISO 2017 C standard (expected to be published in 2018).
+Conform to the ISO 2017 C standard (published in 2018).
 
 std=c89
 C ObjC Alias(std=c90)
@@ -2062,11 +2062,11 @@
 
 std=gnu17
 C ObjC
-Conform to the ISO 2017 C standard (expected to be published in 2018) with GNU 
extensions.
+Conform to the ISO 2017 C standard (published in 2018) with GNU extensions.
 
 std=gnu18
 C ObjC Alias(std=gnu17)
-Conform to the ISO 2017 C standard (expected to be published in 2018) with GNU 
extensions.
+Conform to the ISO 2017 C standard (published in 2018) with GNU extensions.
 
 std=gnu89
 C ObjC Alias(std=gnu90)
@@ -2106,11 +2106,11 @@
 
 std=iso9899:2017
 C ObjC Alias(std=c17)
-Conform to the ISO 2017 C standard (expected to be published in 2018).
+Conform to the ISO 2017 C standard (published in 2018).
 
 std=iso9899:2018
 C ObjC Alias(std=c17)
-Conform to the ISO 2017 C standard (expected to be published in 2018).
+Conform to the ISO 2017 C standard (published in 2018).
 
 traditional
 Driver

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

Re: [PATCH] Add sinh(tanh(x)) and cosh(tanh(x)) rules

[Jeff Law]

On 10/17/18 3:25 PM, Giuliano Augusto Faulin Belinassi wrote:
>> Hmm, do we have problems as we get close to -1 or 1 where the outputs of
>> the two forms might diverge?
> 
> Well, I did some minor testing with that with input x around nextafter(1, -1);
> There are a minor imprecision when comparing directly with
> sinh(atanh(x)) and cosh(atanh(x)).
>   * On 32-bits floats, for such x the error is about 10^-4
>   * On 64-bits floats, for such x the error is about 10^-7
>   * On 80-bits floats, for such x the error is about 10^-9
> 
> here are the code that I used for the test: https://pastebin.com/JzYZyigQ
> 
> I can create a testcase based on this if needed :-)
My gut instinct is those errors are too significant in practice.

It also just occurred to me that we may have problems as X approaches X
from either direction.

Clearly when x^2 is indistinguishable from 0 or 1, then the result has
to be +-0 or +-1.  But I'm not sure if figuring out where those points
are is sufficient to avoid the imprecisions noted above.  This is *well*
outside my areas of expertise.

jeff

Re: [PATCH] Make strlen range computations more conservative

[Jeff Law]

On 10/12/18 9:34 PM, Bernd Edlinger wrote:
> On 10/12/18 16:55, Jeff Law wrote:
>> On 9/15/18 2:43 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> this is an update on my strlen range patch (V7).  Again re-based and
>>> retested to current trunk.
>>>
>>> I am aware that Martin wants to re-factor the interface of get_range_strlen
>>> and have no objections against, but I'd suggest that to be a follow-up 
>>> patch.
>>>
>>> I might suggest to rename one of the two get_range_strlen functions at the
>>> same time as it is rather confusing to have to count the parameters in order
>>> to tell which function is meant.
>>>
>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>> Is it OK for trunk?
>>>
>>>
>>> Thanks
>>> Bernd.
>>>
>>>
>>> changelog-range-strlen-v7.txt
>>>
>>> gcc:
>>> 2018-08-26  Bernd Edlinger  
>>>
>>> * gimple-fold.c (looks_like_a_char_array_without_typecast_p): New
>>> helper function for strlen range estimations.
>>> (get_range_strlen): Use looks_like_a_char_array_without_typecast_p
>>> for warnings, but use GIMPLE semantics otherwise.
>>> * tree-ssa-strlen.c (maybe_set_strlen_range): Use GIMPLE semantics.
>>> (get_min_string_length): Avoid not NUL terminated string literals.
>> The introduction of looks_like_a_char_array_without_typecast_p is
>> probably a good thing.  Too  much code is already implemented inline
>> within get_range_strlen.
>>
>> It looks like you added handling of ARRAY_RANGE_REF.  I don't know how
>> often they come up in practice, but handling it seems like a reasonable
>> extension to what we're doing.  Bonus points if it's triggering with any
>> kind of consistency.
>>
> 
> I did only want to be consistent with get_inner_reference here,
> but did not have encountered these, probably only an Ada thing?
Trying to be consistent with get_inner_reference is fine :-)  GCC
supports case ranges as an extension for C/C++.  No clue if they're
natively supported by Ada or any other langauge.



> 
>> I actually prefer Martin's unification of type/fuzzy into a single
>> enumeration to describe the desired behavior.  Doing it with two args
>> where some values are mutually exclusive is just asking for trouble.
>> Though I like that you called out the values that are mutually exclusive.
>>
>> I definitely want to look at how your patch and Martin's differ on the
>> handling of flexible array members -- clearly we must avoid setting a
>> range in that case.  I'm surprised this didn't trigger a failure in the
>> testsuite though.  Martin's work in this space did.
>>
>> The bugfix in get_min_string_length looks like it probably stands on its
>> own.
>>
>> I'm still evaluating the two approaches...
>>
> 
> One thing I should mention is, that there is still one place where 
> opportunistic
> range info influence conde gen.  I mean at least with my patch.
ACK.   That's soemthing Martin's patch does address.  AT least it's
supposed to.
> 
> That is the return value from sprintf is using the range info from the
> warning, and uses that to set the range info of the result.
> In try_substitute_return_value, which uses the range info that was
> from the warnings and feeds that into set_range_info.
Right.  In Martin's work we have enough range info to distinguish
between the range info for warnings and the true range info and only use
the latter in the call to set_range_info.


jeff

Re: [v3 PATCH] PR libstdc++/87619

[Jonathan Wakely]

On 16/10/18 22:59 +0300, Ville Voutilainen wrote:

Simple, short, and sweet, just a thinko.

2018-10-16  Ville Voutilainen  

   PR libstdc++/87619
   * include/std/variant (__select_index): Fix an off-by-one.
   * testsuite/20_util/variant/87619.cc: New.



diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 2d86a70..55b6440 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -362,7 +362,7 @@ namespace __variant

  template 
  using __select_index =
-typename __select_int::_Select_int_base::type::value_type;

diff --git a/libstdc++-v3/testsuite/20_util/variant/87619.cc 
b/libstdc++-v3/testsuite/20_util/variant/87619.cc
new file mode 100644
index 000..a8db6b8
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/variant/87619.cc
@@ -0,0 +1,46 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17" }
+// { dg-do compile { target c++17 } }
+
+#include 
+#include 
+
+
+template
+struct S {
+};
+
+template 
+void f_impl(std::index_sequence)
+{
+   using V = std::variant...>;
+   static_assert(sizeof(V) == 2);


It might be worth also calling f<256>() and doing:

template 
void f_impl(std::index_sequence is)
{
 using V = std::variant...>;

 // For a variant of 255 alternatives the valid indices are [0,254]
 // and index 255 means valueless-by-exception, so fits in one byte.
 if constexpr (std::variant_size_v <= 255)
   static_assert(sizeof(V) == 2)
 else
   static_assert(sizeof(V) > 2)
}

Just to check we don't introduce an off-by-one error in the *other*
direction in future. What do you think?

To be really portable we would use numeric_limits::max()
but we don't need to worry about non-8-bit char in our implementation.


+}
+
+template 
+void f()
+{
+   f_impl(std::make_index_sequence{});
+}
+
+int main()
+{
+   f<254>();
+   f<255>();
+}

Re: [v3, testsuite] Introduce dg-add-options net_ts

[Rainer Orth]

Hi Jonathan,

>>Btw., one may want to do similarly for the Filesystem TS tests,
>>introducing dg-add-options fs_ts (or filesystem_ts) instead of repeating
>>dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" over and over again.
>
> I tried to add this:
>
> diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
> b/libstdc++-v3/testsuite/lib/dg-options.exp
> index f73ce06..fae0b0d 100644
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -254,6 +254,9 @@ proc add_options_for_net_ts { flags } {
> if { [istarget *-*-solaris2*] } {
>return "$flags -lsocket -lnsl"
> }
> +if { [istarget *-*-aix*] } {
> +   return "$flags -pthread"
> +}
> return $flags
> }
>
> But it doesn't work. It seems to be ignored, as the test log shows:
>
> extra_tool_flags are:
>  -Wl,-bmaxdata:0x2000
>
> That suggests I need to add:
>
> { dg-additional-options "-pthread" { target *-*-aix* } }
>
> Which is a shame, given that we have your new net_ts that should work.

indeed.  After some investigation, it seems libstd++.exp
(libstdc++_init) is misusing DEFAULT_CFLAGS here: the third arg to
dg-runtest ($DEFAULT_CXXFLAGS $PCH_CXXFLAGS in
libstdc++.dg/conformance.exp) is documented like this in DejaGnu's
dg.exp:

# DEFAULT_EXTRA_OPTIONS is a set of options to pass if the testcase
# doesn't specify any (with dg-option).

The two settings of DEFAULT_CXXFLAGS in libstdc++.exp don't seem to fall
in that category at all, and most likely don't need overriding in
individual testcases.  Unfortunately, their semantics/need isn't
documented in the file and I didn't try to dig that up.

However, the proper way to handle this seems to use ALWAYS_CXXFLAGS
instead, appending to it along the lines of what libitm.exp
(libitm_init) does for ALWAYS_CFLAGS for a couple of targets.

Rainer

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

Re: [PATCH] lra: fix spill_hard_reg_in_range clobber check

[Ilya Leoshkevich]

> Am 16.10.2018 um 19:35 schrieb Jeff Law :
> 
> On 10/16/18 10:10 AM, Ilya Leoshkevich wrote:
>> 
>> So I plan to keep using lra_get_insn_recog_data (), but with an extra
>> INSN_P () check.
> Seems reasonable.   Though note that INSN_P will accept DEBUG_INSNs.
> That may be OK -- those routines have some code for handling
> DEBUG_INSNs, but I didn't audit those paths carefully.
The logic for handling DEBUG_INSNs in lra_set_insn_recog_data () is
fairly short, so they seem to be fully supported:

  if (DEBUG_INSN_P (insn))
{
  data->dup_loc = NULL;
  data->arg_hard_regs = NULL;
  data->preferred_alternatives = ALL_ALTERNATIVES;
  if (DEBUG_BIND_INSN_P (insn))
{
  data->insn_static_data = _bind_static_data;
  data->operand_loc = XNEWVEC (rtx *, 1);
  data->operand_loc[0] = _VAR_LOCATION_LOC (insn);
}
  else if (DEBUG_MARKER_INSN_P (insn))
{
  data->insn_static_data = _marker_static_data;
  data->operand_loc = NULL;
}
  return data;
}

I browsed a random RTL dump and found that some DEBUG_INSNs may refer to
hard regs:

(debug_insn (var_location:SI dz (reg/v:SI 0)))

So I guess I have to use INSN_P ().  I will push the v2 once regtest is
finished.

Re: [v3 PATCH] PR libstdc++/87619

[Ville Voutilainen]

On Wed, 17 Oct 2018 at 12:07, Jonathan Wakely  wrote:
> It might be worth also calling f<256>() and doing:
>
> template 
> void f_impl(std::index_sequence is)
> {
>   using V = std::variant...>;
>
>   // For a variant of 255 alternatives the valid indices are [0,254]
>   // and index 255 means valueless-by-exception, so fits in one byte.
>   if constexpr (std::variant_size_v <= 255)
> static_assert(sizeof(V) == 2)
>   else
> static_assert(sizeof(V) > 2)
> }
>
> Just to check we don't introduce an off-by-one error in the *other*
> direction in future. What do you think?

Agreed. I'll patch that in.

> To be really portable we would use numeric_limits::max()
> but we don't need to worry about non-8-bit char in our implementation.

I can change that as well so that we don't need to re-think it every time.

Re: VRP: undefined shifting calculation should not need sign bit

[Aldy Hernandez]

On 9/13/18 3:33 AM, Richard Sandiford wrote:

Aldy Hernandez  writes:

On 09/12/2018 12:57 PM, Richard Sandiford wrote:

Aldy Hernandez  writes:

diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index 589fdea4df6..e9ee418e5b2 100644
--- a/gcc/wide-int-range.h
+++ b/gcc/wide-int-range.h
@@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int , wide_int 
,
   /* Return TRUE if shifting by range [MIN, MAX] is undefined behavior.  */
   
   inline bool

-wide_int_range_shift_undefined_p (signop sign, unsigned prec,
+wide_int_range_shift_undefined_p (unsigned prec,
  const wide_int , const wide_int )
   {
 /* ?? Note: The original comment said this only applied to
@@ -142,7 +142,7 @@ wide_int_range_shift_undefined_p (signop sign, unsigned 
prec,
behavior from the shift operation.  We cannot even trust
SHIFT_COUNT_TRUNCATED at this stage, because that applies to rtl
shifts, and the operation at the tree level may be widened.  */
-  return wi::lt_p (min, 0, sign) || wi::ge_p (max, prec, sign);
+  return wi::sign_mask (min) || wi::ge_p (max, prec, UNSIGNED);


I don't think this is a good idea.  Logically the comparison should
be done relative to the TYPE_SIGN of the type, so I think the original
code was correct.


The operation to calculate undefinedness must be done with the type of
the RHS, as opposed to the type of the entire operation.  This can be
confusing, as most operations use the same type for all operands as well
as for the type of the entire operation.  For example, AFAICT, the
following is valid gimple:

UINT64 = UINT64 << INT32

The original code was doing this (correctly), but since it was confusing
to remember which type to pass, I rewrote the above function to not need
the sign of the RHS.  This came about because in my ranger work, I
passed the wrong type which took forever to find ;-).  My patch avoids
further confusion.

Am I missing a subtle incorrectness in my approach?


The problem is with things like UINT256 << UINT8 vs. UINT256 << INT8.
A range of [128, 131] on the UINT8 would be represented using the same
wide_ints as a range of [-128, -125] on the INT8, but the former is
well-defined while the latter isn't.  Only the TYPE_SIGN tells you
which applies.

The original code got this right, but the new code effectively assumes
all shift amounts are signed, and so would treat UINT8 like INT8.

OK, so no current target actually supports UINT256 AFAIK, so it might
be academic.  But the original point of wide-int.h was to support such
wide types, so they could become a thing in future.

Thanks,
Richard



As promised.  Here is the reversal of the bits you suggested.

I think this is an obvious patch, but would appreciate a sanity peek.

Aldy
commit 38a335af9aa5d72778fbacba247ab2219672da7b
Author: Aldy Hernandez 
Date:   Wed Oct 17 11:25:21 2018 +0200

* wide-int-range.h (wide_int_range_shift_undefined_p): Adjust to
use sign as argument.
* tree-vrp.c (extract_range_from_binary_expr_1): Pass sign to
wide_int_range_shift_undefined_p.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index cbc2ea2f26b..c519613bb28 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -1521,7 +1521,8 @@ extract_range_from_binary_expr_1 (value_range *vr,
 	   || code == LSHIFT_EXPR)
 {
   if (range_int_cst_p ()
-	  && !wide_int_range_shift_undefined_p (prec,
+	  && !wide_int_range_shift_undefined_p (TYPE_SIGN (TREE_TYPE (vr1.min)),
+		prec,
 		wi::to_wide (vr1.min),
 		wi::to_wide (vr1.max)))
 	{
diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index e9ee418e5b2..589fdea4df6 100644
--- a/gcc/wide-int-range.h
+++ b/gcc/wide-int-range.h
@@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int , wide_int ,
 /* Return TRUE if shifting by range [MIN, MAX] is undefined behavior.  */
 
 inline bool
-wide_int_range_shift_undefined_p (unsigned prec,
+wide_int_range_shift_undefined_p (signop sign, unsigned prec,
   const wide_int , const wide_int )
 {
   /* ?? Note: The original comment said this only applied to
@@ -142,7 +142,7 @@ wide_int_range_shift_undefined_p (unsigned prec,
  behavior from the shift operation.  We cannot even trust
  SHIFT_COUNT_TRUNCATED at this stage, because that applies to rtl
  shifts, and the operation at the tree level may be widened.  */
-  return wi::sign_mask (min) || wi::ge_p (max, prec, UNSIGNED);
+  return wi::lt_p (min, 0, sign) || wi::ge_p (max, prec, sign);
 }
 
 /* Calculate MIN/MAX_EXPR of two ranges and store the result in [MIN, MAX].  */

Re: VRP: rewrite the division code (to handle corner cases including 0)

[Aldy Hernandez]

On 8/23/18 8:51 AM, Richard Biener wrote:

On Tue, Aug 21, 2018 at 7:35 PM Aldy Hernandez  wrote:




On 08/21/2018 05:46 AM, Richard Biener wrote:

On Wed, Aug 15, 2018 at 3:33 AM Aldy Hernandez  wrote:



Yeah, nice work.  Few comments:

+  TYPE_OVERFLOW_UNDEFINED (expr_type),
+  TYPE_OVERFLOW_WRAPS (expr_type),

we no longer have the third state !UNDEFINED && !WRAPS so I suggest
to eliminate one for the other (just pass TYPE_OVERFLOW_UNDEFINED).


I'm confused.  Then what shall I pass to
wide_int_range_multiplicative_op within wide_int_range_div?  Are you
expecting to pass overflow_undefined to both the overflow_undefined and
overflow_wraps arguments in multiplicative_op?  Or are you saying I
should get rid of overflow_wraps in both wide_int_range_div and
wide_int_range_multiplicative_op (plus all other users of
w_i_r_multiplicative_op)?


Yes, overflow_wraps == !overflow_undefined (well, OK, not exactly - there's
also TYPE_OVERFLOW_TRAPS, but not for pointers).

Let's sort this out as a followup.  It somewhat felt odd / inconsistent.

I think the wide-int routines want to know whether the operation may
overflow or not and if it may then it simply assumes wrapping behavior.
When overflow is undefined or if it traps the overflow isn't observed
in the result ...


As promised, here is a patch merging the TYPE_OVERFLOW_UNDEFINED and 
TYPE_OVERFLOW_WRAPS flags in the wide_int_range* routines.


OK pending tests?

Aldy
commit dca640a3b3a018e42a852006ccaf09da3b0acaff
Author: Aldy Hernandez 
Date:   Wed Oct 17 11:46:57 2018 +0200

* tree-vrp.c (extract_range_from_multiplicative_op): Remove
overflow wraps argument.
(extract_range_from_binary_expr_1): Do not pass overflow wraps to
wide_int_range_multiplicative_op.
* wide-int-range.cc (wide_int_range_mult_wrapping): Remove
overflow wraps argument.
(wide_int_range_multiplicative_op): Same.
(wide_int_range_lshift): Same.
(wide_int_range_div): Same.
* wide-int-range.h (wide_int_range_multiplicative_op): Same.
(wide_int_range_lshift): Same.
(wide_int_range_div): Same.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4768b9635f8..6cfaac1690d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,18 @@
+2018-10-17  Aldy Hernandez  
+
+* tree-vrp.c (extract_range_from_multiplicative_op): Remove
+	overflow wraps argument.
+(extract_range_from_binary_expr_1): Do not pass overflow wraps to
+	wide_int_range_multiplicative_op.
+* wide-int-range.cc (wide_int_range_mult_wrapping): Remove
+	overflow wraps argument.
+(wide_int_range_multiplicative_op): Same.
+(wide_int_range_lshift): Same.
+(wide_int_range_div): Same.
+* wide-int-range.h (wide_int_range_multiplicative_op): Same.
+(wide_int_range_lshift): Same.
+(wide_int_range_div): Same.
+
 2018-10-17  Aldy Hernandez  
 
 	* wide-int-range.h (wide_int_range_shift_undefined_p): Adjust to
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index c519613bb28..0a42da7005e 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -1003,13 +1003,12 @@ extract_range_from_multiplicative_op (value_range *vr,
   wide_int vr1_lb = wi::to_wide (vr1->min);
   wide_int vr1_ub = wi::to_wide (vr1->max);
   bool overflow_undefined = TYPE_OVERFLOW_UNDEFINED (type);
-  bool overflow_wraps = TYPE_OVERFLOW_WRAPS (type);
   unsigned prec = TYPE_PRECISION (type);
 
   if (wide_int_range_multiplicative_op (res_lb, res_ub,
-	 code, TYPE_SIGN (type), prec,
-	 vr0_lb, vr0_ub, vr1_lb, vr1_ub,
-	 overflow_undefined, overflow_wraps))
+	code, TYPE_SIGN (type), prec,
+	vr0_lb, vr0_ub, vr1_lb, vr1_ub,
+	overflow_undefined))
 set_and_canonicalize_value_range (vr, VR_RANGE,
   wide_int_to_tree (type, res_lb),
   wide_int_to_tree (type, res_ub), NULL);
@@ -1549,8 +1548,7 @@ extract_range_from_binary_expr_1 (value_range *vr,
 	 wi::to_wide (vr0.max),
 	 wi::to_wide (vr1.min),
 	 wi::to_wide (vr1.max),
-	 TYPE_OVERFLOW_UNDEFINED (expr_type),
-	 TYPE_OVERFLOW_WRAPS (expr_type)))
+	 TYPE_OVERFLOW_UNDEFINED (expr_type)))
 		{
 		  min = wide_int_to_tree (expr_type, res_lb);
 		  max = wide_int_to_tree (expr_type, res_ub);
@@ -1595,7 +1593,6 @@ extract_range_from_binary_expr_1 (value_range *vr,
 			   dividend_min, dividend_max,
 			   divisor_min, divisor_max,
 			   TYPE_OVERFLOW_UNDEFINED (expr_type),
-			   TYPE_OVERFLOW_WRAPS (expr_type),
 			   extra_range_p, extra_min, extra_max))
 	{
 	  set_value_range_to_varying (vr);
diff --git a/gcc/wide-int-range.cc b/gcc/wide-int-range.cc
index a85fe9f9ad7..8978b5aecfd 100644
--- a/gcc/wide-int-range.cc
+++ b/gcc/wide-int-range.cc
@@ -268,7 +268,7 @@ wide_int_range_mult_wrapping (wide_int _lb,
 
Return TRUE if we were able to perform the operation.
 
-   NOTE: If code 

[Patch, Fortran] PR87625 - fix reallocate on assign with polymophic arrays

[Tobias Burnus]

for some reasons, the two calls to gfc_is_reallocatable_lhs(expr1) differ, the 
first
one is a simple "var" + full-array reference while the second one is
"var->_data" + full-array reference.

Neither was handled and, hence, using
  var = [ t(11), t(12) ]
didn't do any memory allocation; the program then simply segfaulted on 
assignment.

Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index ea4cf8cd1b8..47fec131c78 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9616,9 +9616,15 @@ gfc_is_reallocatable_lhs (gfc_expr *expr)
   if (sym->ts.type == BT_CLASS
   && !sym->attr.associate_var
   && CLASS_DATA (sym)->attr.allocatable
-  && expr->ref && expr->ref->type == REF_COMPONENT
-  && strcmp (expr->ref->u.c.component->name, "_data") == 0
-  && expr->ref->next == NULL)
+  && expr->ref
+  && ((expr->ref->type == REF_ARRAY && expr->ref->u.ar.type == AR_FULL
+	   && expr->ref->next == NULL)
+	  || (expr->ref->type == REF_COMPONENT
+	  && strcmp (expr->ref->u.c.component->name, "_data") == 0
+	  && (expr->ref->next == NULL
+		  || (expr->ref->next->type == REF_ARRAY
+		  && expr->ref->next->u.ar.type == AR_FULL
+		  && expr->ref->next->next == NULL)
 return true;
 
   /* An allocatable variable.  */
diff --git a/gcc/testsuite/gfortran.dg/realloc_on_assign_31.f90 b/gcc/testsuite/gfortran.dg/realloc_on_assign_31.f90
new file mode 100644
index 000..55096d179ba
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/realloc_on_assign_31.f90
@@ -0,0 +1,31 @@
+! { dg-do run }
+!
+! PR fortran/87625
+!
+! Ensure that "var" gets allocated.
+!
+! Contributed by Tobias Burnus
+!
+program test
+   implicit none
+   type t
+ integer :: i
+   end type t
+   class(t), allocatable :: var(:)
+   call poly_init()
+   print *, var(:)%i
+   if (lbound(var, 1) /= 1 .and. ubound(var, 1) /= 2) call abort()
+   if (var(1)%i /= 11 .or. var(2)%i /= 12) call abort()
+   call poly_init2()
+   !print *, var(:)%i
+   if (lbound(var, 1) /= 1 .and. ubound(var, 1) /= 3) call abort()
+   if (var(1)%i /= 11 .or. var(2)%i /= 12 .or. var(3)%i /= 13) call abort()
+contains
+   subroutine poly_init()
+ !allocate(var(2))
+ var = [t :: t(11), t(12)]
+   end subroutine poly_init
+   subroutine poly_init2()
+ var = [t :: t(11), t(12), t(13)]
+   end subroutine poly_init2
+ end program test

GCC 9.0 Status Report (2018-10-17), Stage 3 starts Nov. 12th

[Richard Biener]

Status
==

GCC trunk is open for general development (Stage 1) until the end
of Nov 11th after which it will transition to bugfixing mode (Stage 3)
which in turn will end Jan 6th after which only regression and
documentation fixes will be possible.

This means you have an additional three weeks to push feature
changes for GCC 9.

Note bugs have not yet been prioritized thoroughly so there's no
meaningful Quality Data yet.


Previous Report
===

https://gcc.gnu.org/ml/gcc/2018-04/msg00156.html

Re: VRP: undefined shifting calculation should not need sign bit

[Richard Sandiford]

Aldy Hernandez  writes:
> On 9/13/18 3:33 AM, Richard Sandiford wrote:
>> Aldy Hernandez  writes:
>>> On 09/12/2018 12:57 PM, Richard Sandiford wrote:
 Aldy Hernandez  writes:
> diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
> index 589fdea4df6..e9ee418e5b2 100644
> --- a/gcc/wide-int-range.h
> +++ b/gcc/wide-int-range.h
> @@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int , 
> wide_int ,
>/* Return TRUE if shifting by range [MIN, MAX] is undefined behavior.  
> */
>
>inline bool
> -wide_int_range_shift_undefined_p (signop sign, unsigned prec,
> +wide_int_range_shift_undefined_p (unsigned prec,
> const wide_int , const wide_int 
> )
>{
>  /* ?? Note: The original comment said this only applied to
> @@ -142,7 +142,7 @@ wide_int_range_shift_undefined_p (signop sign, 
> unsigned prec,
> behavior from the shift operation.  We cannot even trust
> SHIFT_COUNT_TRUNCATED at this stage, because that applies to rtl
> shifts, and the operation at the tree level may be widened.  */
> -  return wi::lt_p (min, 0, sign) || wi::ge_p (max, prec, sign);
> +  return wi::sign_mask (min) || wi::ge_p (max, prec, UNSIGNED);

 I don't think this is a good idea.  Logically the comparison should
 be done relative to the TYPE_SIGN of the type, so I think the original
 code was correct.
>>>
>>> The operation to calculate undefinedness must be done with the type of
>>> the RHS, as opposed to the type of the entire operation.  This can be
>>> confusing, as most operations use the same type for all operands as well
>>> as for the type of the entire operation.  For example, AFAICT, the
>>> following is valid gimple:
>>>
>>> UINT64 = UINT64 << INT32
>>>
>>> The original code was doing this (correctly), but since it was confusing
>>> to remember which type to pass, I rewrote the above function to not need
>>> the sign of the RHS.  This came about because in my ranger work, I
>>> passed the wrong type which took forever to find ;-).  My patch avoids
>>> further confusion.
>>>
>>> Am I missing a subtle incorrectness in my approach?
>> 
>> The problem is with things like UINT256 << UINT8 vs. UINT256 << INT8.
>> A range of [128, 131] on the UINT8 would be represented using the same
>> wide_ints as a range of [-128, -125] on the INT8, but the former is
>> well-defined while the latter isn't.  Only the TYPE_SIGN tells you
>> which applies.
>> 
>> The original code got this right, but the new code effectively assumes
>> all shift amounts are signed, and so would treat UINT8 like INT8.
>> 
>> OK, so no current target actually supports UINT256 AFAIK, so it might
>> be academic.  But the original point of wide-int.h was to support such
>> wide types, so they could become a thing in future.
>> 
>> Thanks,
>> Richard
>> 
>
> As promised.  Here is the reversal of the bits you suggested.

Thanks!

> I think this is an obvious patch, but would appreciate a sanity peek.
>
> Aldy
>
> commit 38a335af9aa5d72778fbacba247ab2219672da7b
> Author: Aldy Hernandez 
> Date:   Wed Oct 17 11:25:21 2018 +0200
>
> * wide-int-range.h (wide_int_range_shift_undefined_p): Adjust to
> use sign as argument.
> * tree-vrp.c (extract_range_from_binary_expr_1): Pass sign to
> wide_int_range_shift_undefined_p.
>
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index cbc2ea2f26b..c519613bb28 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -1521,7 +1521,8 @@ extract_range_from_binary_expr_1 (value_range *vr,
>  || code == LSHIFT_EXPR)
>  {
>if (range_int_cst_p ()
> -   && !wide_int_range_shift_undefined_p (prec,
> +   && !wide_int_range_shift_undefined_p (TYPE_SIGN (TREE_TYPE (vr1.min)),
> + prec,
>   wi::to_wide (vr1.min),
>   wi::to_wide (vr1.max)))
>   {
> diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
> index e9ee418e5b2..589fdea4df6 100644
> --- a/gcc/wide-int-range.h
> +++ b/gcc/wide-int-range.h
> @@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int , wide_int 
> ,
>  /* Return TRUE if shifting by range [MIN, MAX] is undefined behavior.  */
>  
>  inline bool
> -wide_int_range_shift_undefined_p (unsigned prec,
> +wide_int_range_shift_undefined_p (signop sign, unsigned prec,
> const wide_int , const wide_int )

Need to add SIGN back to the comment, maybe something like:

  /* Return TRUE if shifting by range [MIN, MAX] is undefined behavior,
 interpreting MIN and MAX according to SIGN.  */

(or whatever you think's best).

OK otherwise, thanks.

Richard

[Patch, fortran] PR58618 - Wrong code with character substring and ASSOCIATE

[Paul Richard Thomas]

This problem concerned associate targets being substrings. It turns
out that they are returned as pointer types (with a different cast for
unity based substrings ***sigh***) and so can be assigned directly to
the associate name. The patch quite simply removed the condition that
such targets be allocatable, pointer or dummy.

I noticed in the course of working up the testcase that
character (:), pointer :: ptr => NULL()
character (6), target :: tgt = 'lmnopq'
ptr => tgt
print *, len (ptr), ptr
end
ICEs on the NULL initialization of the pointer but works fine if this
is removed. Has this already been posted as a PR?

Bootstrapped and regtested on FC28/x86_64 - OK for trunk?

Paul

2018-10-17  Paul Thomas  

PR fortran/58618
* trans-stmt.c (trans_associate_var): All strings that return
as pointer types can be assigned directly to the associate
name so remove 'attr' and the condition that uses it.

2018-10-17  Paul Thomas  

PR fortran/58618
* gfortran.dg/associate_45.f90 : New test.
Index: gcc/fortran/trans-stmt.c
===
*** gcc/fortran/trans-stmt.c	(revision 265231)
--- gcc/fortran/trans-stmt.c	(working copy)
*** trans_associate_var (gfc_symbol *sym, gf
*** 1656,1662 
bool need_len_assign;
bool whole_array = true;
gfc_ref *ref;
-   symbol_attribute attr;
  
gcc_assert (sym->assoc);
e = sym->assoc->target;
--- 1656,1661 
*** trans_associate_var (gfc_symbol *sym, gf
*** 1916,1924 
  	}
  	}
  
-   attr = gfc_expr_attr (e);
if (sym->ts.type == BT_CHARACTER && e->ts.type == BT_CHARACTER
- 	  && (attr.allocatable || attr.pointer || attr.dummy)
  	  && POINTER_TYPE_P (TREE_TYPE (se.expr)))
  	{
  	  /* These are pointer types already.  */
--- 1915,1921 
*** trans_associate_var (gfc_symbol *sym, gf
*** 1926,1933 
  	}
else
  	{
!   tmp = TREE_TYPE (sym->backend_decl);
!   tmp = gfc_build_addr_expr (tmp, se.expr);
  	}
  
gfc_add_modify (, sym->backend_decl, tmp);
--- 1923,1930 
  	}
else
  	{
! 	  tmp = TREE_TYPE (sym->backend_decl);
! 	  tmp = gfc_build_addr_expr (tmp, se.expr);
  	}
  
gfc_add_modify (, sym->backend_decl, tmp);
Index: gcc/testsuite/gfortran.dg/associate_45.f90
===
*** gcc/testsuite/gfortran.dg/associate_45.f90	(nonexistent)
--- gcc/testsuite/gfortran.dg/associate_45.f90	(working copy)
***
*** 0 
--- 1,38 
+ ! { dg-do run }
+ !
+ ! Test the fix for PR58618 by checking that substring associate targets
+ ! work correctly.
+ !
+ ! Contributed by Vladimir Fuka  
+ !
+ character(5) :: s(2) = ['abcde','fghij']
+ character (6), pointer :: ptr => NULL()
+ character (6), target :: tgt = 'lmnopq'
+ 
+ associate (x=>s(2)(3:4))
+   if (x .ne. 'hi') stop 1
+   x = 'uv'
+ end associate
+ if (any (s .ne. ['abcde','fguvj'])) stop 2
+ 
+ ! Unity based substrings are cast differently.  */
+ associate (x=>s(1)(1:4))
+   if (x .ne. 'abcd') stop 3
+   x(2:3) = 'wx'
+ end associate
+ if (any (s .ne. ['awxde','fguvj'])) stop 4
+ 
+ ! Make sure that possible misidentifications do not occur.
+ ptr => tgt
+ associate (x=>ptr)
+   if (x .ne. 'lmnopq') stop 5
+   x(2:3) = 'wx'
+ end associate
+ if (tgt .ne. 'lwxopq') stop 6
+ 
+ associate (x=>ptr(5:6))
+   if (x .ne. 'pq') stop 7
+   x = 'wx'
+ end associate
+ if (tgt .ne. 'lwxowx') stop 8
+   end

Re: [patch] new API for value_range

[Richard Biener]

On Thu, Oct 11, 2018 at 8:25 PM Aldy Hernandez  wrote:
>
>
>
> On 10/11/18 5:47 AM, Richard Biener wrote:
> > On Thu, Oct 11, 2018 at 10:19 AM Aldy Hernandez  wrote:
> >>
> >> Hi Richard.  Thanks for reviewing.
> >>
> >> On 10/10/18 6:27 AM, Richard Biener wrote:
> >>> On Tue, Oct 9, 2018 at 6:23 PM Aldy Hernandez  wrote:
> 
>  I'm assuming the silence on the RFC means nobody is viscerally opposed
>  to it, so here goes the actual implementation ;-).
> 
>    FWI: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00157.html
> 
>  My aim is no change to the current functionality, but there are some
>  things that changed slightly (with no appreciable change in
>  bootstrapability or tests).
> 
>  1.  Primarily, we were building value_ranges by modifying them in-flight
>  with no regards to the validity of the resulting range.  By enforcing
>  the API, I noticed we periodically built VR_VARYING / VR_UNDEFINED, but
>  left the equivalence bits uncleared.  This comment in the original
>  header file indicates that this is invalid behavior:
> 
>   /* Set of SSA names whose value ranges are equivalent to this one.
>  This set is only valid when TYPE is VR_RANGE or VR_ANTI_RANGE.  
>  */
> 
>  The API now enforces this upon construction.
> 
>  2. I also saw us setting min/max when VARYING or UNDEFINED was set.
>  This is invalid.  Although these values were being ignored, the API now
>  enforces this.
> 
>  3. I saw one case in set_value_range_with_overflow() were we were
>  building an invalid range with swapped ranges, where we were silently
>  depending on somebody further up the call chain to swap them for us.
>  I've fixed this at creation.
> 
>  4. There is one assert in ipcp_vr_lattice which I hope to remove, but
>  left as proof that the original VR_UNDEFINED set was not necessary, as
>  it is now done by default on an empty constructor:
> 
>  -  void init () { m_vr.type = VR_UNDEFINED; }
>  +  void init () { gcc_assert (m_vr.undefined_p ()); }
> 
>  One last note.  The file tree-vrp.c already has a cripple API of sorts
>  in the form of functions (set_value_range_to_varying, etc).  I have
>  tried to keep those functions available, by calling the API under the
>  covers, but would be okay in removing them altogether as a follow-up.
> 
>  Please refer to the RFC wrt the min/max/vrtype accessors, as well as the
>  new tree type field.
> 
>  I am quoting the class declaration below to make it easy to review at a
>  high level.
> 
>  Tested on x86-64 Linux.  All languages, including Ada and Go.
> 
>  OK for trunk?
> >>>
> >>> Reviewing in patch order.
> >>>
>  Aldy
> 
>  class GTY((for_user)) value_range
>  {
>  public:
>   value_range ();
>   value_range (tree type);
>   value_range (value_range_type, tree type, tree, tree, bitmap = 
>  NULL);
>   bool operator== (const value_range &) const;
>   bool operator!= (const value_range &) const;
>   void intersect (const value_range *);
>   void union_ (const value_range *);
> >>>
> >>> with trailing underscore?  seriously?
> >>
> >> Hey!  You complained about Union() last year, at which point the
> >> consensus was that trailing underscores would be ok for symbol names
> >> that clashed with keywords.
> >
> > ;)
> >
> > I also thought about union_into / union_with.  As opposed to a hypothetical
> >
> >value_range union (const value_range& a, const value_range& b)
> >
> > function.
> >
> >> And yes, it was also discussed whether we should overload | and ^ for
> >> union and intersection, but was denied for readability and what have yous.
> >>
> >>>
>   /* Like operator== but ignore equivalence bitmap.  */
>   bool ignore_equivs_equal_p (const value_range &) const;
>   /* Like a operator= but update equivalence bitmap efficiently.  */
>   void copy_with_equiv_update (const value_range *);
> 
>   /* Types of value ranges.  */
>   bool undefined_p () const;
>   bool varying_p () const;
>   bool symbolic_p () const;
>   bool numeric_p () const;
>   void set_undefined (tree = NULL);
>   void set_varying (tree = NULL);
> >>>
> >>> I'd appreciate comments on those predicates, esp. as you
> >>> replace positive tests by negative ones like in
> >>
> >> Done.
> >>
> >>>
> >>>  /* If we found any usable VR, set the VR to ssa_name and create a
> >>> PUSH old value in the stack with the old VR.  */
> >>> -  if (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE)
> >>> +  if (!vr.undefined_p () && !vr.varying_p ())
> >>>{
> >>>
> >>> I'd also spell numeric_p as constant_p or drop it alltogether
> >>> since !symbolic_p should imply it given varying_p and 

Re: VRP: rewrite the division code (to handle corner cases including 0)

[Richard Biener]

On Wed, Oct 17, 2018 at 12:20 PM Aldy Hernandez  wrote:
>
>
>
> On 8/23/18 8:51 AM, Richard Biener wrote:
> > On Tue, Aug 21, 2018 at 7:35 PM Aldy Hernandez  wrote:
> >>
> >>
> >>
> >> On 08/21/2018 05:46 AM, Richard Biener wrote:
> >>> On Wed, Aug 15, 2018 at 3:33 AM Aldy Hernandez  wrote:
>
> >>> Yeah, nice work.  Few comments:
> >>>
> >>> +  TYPE_OVERFLOW_UNDEFINED (expr_type),
> >>> +  TYPE_OVERFLOW_WRAPS (expr_type),
> >>>
> >>> we no longer have the third state !UNDEFINED && !WRAPS so I suggest
> >>> to eliminate one for the other (just pass TYPE_OVERFLOW_UNDEFINED).
> >>
> >> I'm confused.  Then what shall I pass to
> >> wide_int_range_multiplicative_op within wide_int_range_div?  Are you
> >> expecting to pass overflow_undefined to both the overflow_undefined and
> >> overflow_wraps arguments in multiplicative_op?  Or are you saying I
> >> should get rid of overflow_wraps in both wide_int_range_div and
> >> wide_int_range_multiplicative_op (plus all other users of
> >> w_i_r_multiplicative_op)?
> >
> > Yes, overflow_wraps == !overflow_undefined (well, OK, not exactly - there's
> > also TYPE_OVERFLOW_TRAPS, but not for pointers).
> >
> > Let's sort this out as a followup.  It somewhat felt odd / inconsistent.
> >
> > I think the wide-int routines want to know whether the operation may
> > overflow or not and if it may then it simply assumes wrapping behavior.
> > When overflow is undefined or if it traps the overflow isn't observed
> > in the result ...
>
> As promised, here is a patch merging the TYPE_OVERFLOW_UNDEFINED and
> TYPE_OVERFLOW_WRAPS flags in the wide_int_range* routines.
>
> OK pending tests?

OK.

Richard.

> Aldy

[gomp5] Disallow zero sized task reductions for C

[Jakub Jelinek]

Hi!

For the way we implement task reductions, making it work with zero sized
aggregates is impossible and those aren't really useful anyway.
The patch also disallows reductions on variable sized structures for the
same reason, but when trying to add test coverage for that I've discovered
we don't handle them properly even in the privatization clauses, so ++todo
for later.

Committed to gomp-5_0-branch.

2018-10-17  Jakub Jelinek  

* c-parser.c (c_finish_taskloop_clauses): New function.
(c_parser_omp_taskloop): Use it.
* c-typeck.c (c_finish_omp_clauses): Call save_expr for whole array
reduction sizes.  Diagnose reductions with zero sized elements or
variable length structures.

* semantics.c (finish_omp_reduction_clause): Call save_expr for
whole array reduction sizes.

* gcc.dg/gomp/reduction-2.c: New test.

--- gcc/c/c-parser.c.jj 2018-08-02 14:14:40.138818877 +0200
+++ gcc/c/c-parser.c2018-10-17 11:49:04.527491213 +0200
@@ -18823,6 +18823,41 @@ c_parser_omp_requires (c_parser *parser)
 error_at (loc, "% requires at least one clause");
 }
 
+/* Helper function for c_parser_omp_taskloop.
+   Disallow zero sized or potentially zero sized task reductions.  */
+
+static tree
+c_finish_taskloop_clauses (tree clauses)
+{
+  tree *pc = 
+  for (tree c = clauses; c; c = *pc)
+{
+  bool remove = false;
+  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_REDUCTION)
+   {
+ tree type = strip_array_types (TREE_TYPE (OMP_CLAUSE_DECL (c)));
+ if (integer_zerop (TYPE_SIZE_UNIT (type)))
+   {
+ error_at (OMP_CLAUSE_LOCATION (c),
+   "zero sized type %qT in % clause", type);
+ remove = true;
+   }
+ else if (TREE_CODE (TYPE_SIZE_UNIT (type)) != INTEGER_CST)
+   {
+ error_at (OMP_CLAUSE_LOCATION (c),
+   "variable sized type %qT in % clause",
+   type);
+ remove = true;
+   }
+   }
+  if (remove)
+   *pc = OMP_CLAUSE_CHAIN (c);
+  else
+   pc = _CLAUSE_CHAIN (c);
+}
+  return clauses;
+}
+
 /* OpenMP 4.5:
#pragma omp taskloop taskloop-clause[optseq] new-line
  for-loop
@@ -18880,6 +18915,8 @@ c_parser_omp_taskloop (location_t loc, c
  TREE_TYPE (ret) = void_type_node;
  OMP_FOR_BODY (ret) = block;
  OMP_FOR_CLAUSES (ret) = cclauses[C_OMP_CLAUSE_SPLIT_TASKLOOP];
+ OMP_FOR_CLAUSES (ret)
+   = c_finish_taskloop_clauses (OMP_FOR_CLAUSES (ret));
  SET_EXPR_LOCATION (ret, loc);
  add_stmt (ret);
  return ret;
@@ -18898,6 +18935,7 @@ c_parser_omp_taskloop (location_t loc, c
   clauses = cclauses[C_OMP_CLAUSE_SPLIT_TASKLOOP];
 }
 
+  clauses = c_finish_taskloop_clauses (clauses);
   block = c_begin_compound_stmt (true);
   ret = c_parser_omp_for_loop (loc, parser, OMP_TASKLOOP, clauses, NULL, if_p);
   block = c_end_compound_stmt (loc, block, true);
--- gcc/c/c-typeck.c.jj 2018-10-16 15:19:10.702681542 +0200
+++ gcc/c/c-typeck.c2018-10-17 11:17:22.339930169 +0200
@@ -13343,6 +13343,7 @@ c_finish_omp_clauses (tree clauses, enum
  break;
}
  size = size_binop (MINUS_EXPR, size, size_one_node);
+ size = save_expr (size);
  tree index_type = build_index_type (size);
  tree atype = build_array_type (type, index_type);
  tree ptype = build_pointer_type (type);
@@ -13358,6 +13359,28 @@ c_finish_omp_clauses (tree clauses, enum
  remove = true;
  break;
}
+ if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_REDUCTION
+ || OMP_CLAUSE_REDUCTION_TASK (c))
+   {
+ /* Disallow zero sized or potentially zero sized task
+reductions.  */
+ if (integer_zerop (TYPE_SIZE_UNIT (type)))
+   {
+ error_at (OMP_CLAUSE_LOCATION (c),
+   "zero sized type %qT in %qs clause", type,
+   omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
+ remove = true;
+ break;
+   }
+ else if (TREE_CODE (TYPE_SIZE_UNIT (type)) != INTEGER_CST)
+   {
+ error_at (OMP_CLAUSE_LOCATION (c),
+   "variable sized type %qT in %qs clause", type,
+   omp_clause_code_name[OMP_CLAUSE_CODE (c)]);
+ remove = true;
+ break;
+   }
+   }
  if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) == NULL_TREE
  && (FLOAT_TYPE_P (type)
  || TREE_CODE (type) == COMPLEX_TYPE))
--- gcc/cp/semantics.c.jj   2018-10-16 15:29:14.154644851 +0200
+++ gcc/cp/semantics.c  2018-10-17 10:59:59.558752697 +0200
@@ -5567,6 +5567,7 @@ finish_omp_reduction_clause (tree c, boo
  return true;
}

[PATCH] S/390: Allow immediates in loc expander

[Robin Dapp]

Hi,

this allows immediates in the load-on-condition expander on z13 or later.

Regtested on z14.

Regards
 Robin

--

gcc/ChangeLog:

2018-10-17  Robin Dapp  

* config/s390/predicates.md:
Allow immediate operand in loc_operand for z13.
* config/s390/s390.md: Use loc_operand instead of nonimmediate_operand.
diff --git a/gcc/config/s390/predicates.md b/gcc/config/s390/predicates.md
index 98a824e77b7..b4e7724c265 100644
--- a/gcc/config/s390/predicates.md
+++ b/gcc/config/s390/predicates.md
@@ -216,8 +216,9 @@
 
 (define_predicate "loc_operand"
   (ior (match_operand 0 "nonimmediate_operand")
-  (and (match_code "const_int")
-	   (match_test "INTVAL (op) <= 32767 && INTVAL (op) >= -32768"
+  (and (match_test "TARGET_Z13")
+   (and (match_code "const_int")
+	(match_test "INTVAL (op) <= 32767 && INTVAL (op) >= -32768")
 
 (define_predicate "reload_const_wide_int_operand"
   (and (match_code "const_wide_int")
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 3bd18acb456..70a619f06f5 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -6583,7 +6583,7 @@
   [(set (match_operand:GPR 0 "nonimmediate_operand" "")
 	(if_then_else:GPR (match_operand 1 "comparison_operator" "")
 			  (match_operand:GPR 2 "nonimmediate_operand" "")
-			  (match_operand:GPR 3 "nonimmediate_operand" "")))]
+			  (match_operand:GPR 3 "loc_operand" "")))]
   "TARGET_Z196"
 {
   /* Emit the comparison insn in case we do not already have a comparison result.  */

Re: [v3 PATCH] PR libstdc++/87619

[Ville Voutilainen]

On Wed, 17 Oct 2018 at 12:20, Ville Voutilainen
 wrote:
>
> On Wed, 17 Oct 2018 at 12:07, Jonathan Wakely  wrote:
> > It might be worth also calling f<256>() and doing:
> >
> > template 
> > void f_impl(std::index_sequence is)
> > {
> >   using V = std::variant...>;
> >
> >   // For a variant of 255 alternatives the valid indices are [0,254]
> >   // and index 255 means valueless-by-exception, so fits in one byte.
> >   if constexpr (std::variant_size_v <= 255)
> > static_assert(sizeof(V) == 2)
> >   else
> > static_assert(sizeof(V) > 2)
> > }
> >
> > Just to check we don't introduce an off-by-one error in the *other*
> > direction in future. What do you think?
>
> Agreed. I'll patch that in.
>
> > To be really portable we would use numeric_limits::max()
> > but we don't need to worry about non-8-bit char in our implementation.
>
> I can change that as well so that we don't need to re-think it every time.

Here.
diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index 2d86a70..55b6440 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -362,7 +362,7 @@ namespace __variant
 
   template 
   using __select_index =
-typename __select_int::_Select_int_base::type::value_type;
 
diff --git a/libstdc++-v3/testsuite/20_util/variant/87619.cc b/libstdc++-v3/testsuite/20_util/variant/87619.cc
new file mode 100644
index 000..e6f48fe
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/variant/87619.cc
@@ -0,0 +1,53 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17" }
+// { dg-do compile { target c++17 } }
+
+#include 
+#include 
+#include 
+
+template
+struct S {
+};
+
+template 
+void f_impl(std::index_sequence)
+{
+	using V = std::variant...>;
+	// For a variant of 255 alternatives the valid indices are [0,254]
+	// and index 255 means valueless-by-exception, so fits in one byte.
+	if constexpr (std::variant_size_v <=
+		  std::numeric_limits::max())
+	  static_assert(sizeof(V) == 2);
+	else
+	  static_assert(sizeof(V) > 2);
+}
+
+template 
+void f()
+{
+	f_impl(std::make_index_sequence{});
+}
+
+int main()
+{
+	f::max() - 1>();
+	f::max()>();
+	f::max() + 1>();
+}

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Richard Sandiford]

[ Sorry that there were so many typos in my last reply, will try to do better
  this time... ]

Joseph Myers  writes:
> On Tue, 16 Oct 2018, Richard Sandiford wrote:
>> The patches therefore add a new "__sizeless_struct" keyword to denote
>> structures that are sizeless rather than sized.  Unlike normal
>> structures, these structures can have members of sizeless type in
>> addition to members of sized type.  On the other hand, they have all
>> the same limitations as other sizeless types (described in earlier
>> sections).
>
> I don't see anything here disallowing offsetof on such structures.

I didn't think this needed to be done explicitly since:

offsetof(type, member-designator)

which expands to an integer constant expression that has type size_t,
the value of which is the offset in bytes, to the structure
member (designated by member-designator), from the beginning of its
structure (designated by type). The type and member designator shall be
such that given

static type t;

then the expression &(t.member-designator) evaluates to an address
constant. (If the specified member is a bit-field, the behavior is
undefined.)

implicitly rejects sizeless types on the basis that "static type t;"
would be invalid.  I think that's the same way that it rejects
incomplete structure types.

But yeah, it looks like I forgot to handle this in GCC. :-(

> On Tue, 16 Oct 2018, Richard Sandiford wrote:
>> > as Joseph pointed out, there are some related discussions
>> > on the WG14 reflector. How a about moving the discussion
>> > there?
>> 
>> The idea was to get a feel for what would be acceptable to GCC
>> maintainers.  When Arm presented an extension of P0214 to support SVE
>> at the last C++ committee meeting, using this sizeless type extension
>> as a possible way of providing the underlying vector types, the feeling
>> seemed to be that it wouldn't be considered unless it had already been
>> proven in compilers.
>
> But as shown in the related discussions, there are other possible features 
> that might also involve non-VLA types whose size is not a compile-time 
> constant.  And so it's necessary to work with the people interested in 
> those features in order to clarify what the underlying concepts ought to 
> look like to support different such features.

Could you give pointers to the specific proposals/papers you mean?

>> I think it is for some people though.  If the vectors don't decay to
>> pointers, they're more akin to a VLA wrapped in a structure rather than
>> a stand-alone VLA.  There is a GNU extension for that, e.g.:
>> 
>>   int
>>   f (int n)
>>   {
>> struct s {
>>   int x[n];
>> } foo;
>> return sizeof (foo.x);
>>   }
>> 
>> But even though clang supports VLAs (of course), it rejects the
>> above with:
>> 
>>   error: fields must have a constant size: 'variable length array in 
>> structure' extension will never be supported
>> 
>> This gives a strong impression that wrapping a VLA type like this
>> is a bridge too far for some :-)  The message makes it clear that's
>> a case of "don't even bother asking".
>
> What are the clang concerns about VLAs in structs that are the reason for 
> not supporting them?

The user manual says:

-  clang does not support the gcc extension that allows variable-length
   arrays in structures. This is for a few reasons: one, it is tricky to
   implement, two, the extension is completely undocumented, and three,
   the extension appears to be rarely used. Note that clang *does*
   support flexible array members (arrays with a zero or unspecified
   size at the end of a structure).

So I guess defining it would remove the second objection.

> How do the sizeless structs with sizeless members in your proposal
> avoid those concerns about the definition of VLAs in structs?

The key difference is that the size, offset and layout don't have to be
known to the frontend and available during semantic analysis (unlike for
VLAs in structs).  In the clang implementation of sizeless types those
details only start to matter when translating clang ASTs into LLVM IR.
(With GCC it's a bit different, since TYPE_SIZE is set as soon as the
type definition is complete, even though for SVE TYPE_SIZE should only
matter in the mid and backend.)

>> The problem isn't so much that the size is only known at runtime,
>> but that the size isn't necessarily invariant, and the size of an
>> object doesn't carry the size information with it.
>> 
>> This means you can't tell what size a given object is, even at runtime.
>
> How then is e.g. passing a pointer to such a struct (containing such 
> unknown-size members) to another function supposed to work?  Or is there 
> something in your proposed standard text edits that would disallow passing 
> such a pointer, or disallow using "->" with it to access members?

The idea here...

>> All you can tell is what size the object would be if you created it
>> from scratch.  E.g.:
>> 
>>   

Re: [patch][RFC] bitmaps as lists *or* trees

[Richard Biener]

On Thu, Mar 7, 2013 at 9:18 PM Steven Bosscher  wrote:
>
> > Attached is a version that passes bootstrap on
> > x86_64-unknown-linux-gnu. and with a ChangeLog.
>
> Hello,
>
> Testing with some bitmap view changes revealed a few bugs:
>
> - Listifying a tree was broken, the prev pointer was never set. Oops!
> - As a result of the above, clearing bitmaps was broken, the whole
> bitmap would be leaked instead of released.
> - Likewise, changing view from tree to list would only retain
> head->first and lose the rest of the set...
> - bitmap_last_set_bit has to search from the root, as head->current
> may be in the left branch of another node.

I have updated the patch to trunk and fixed another bug (the patch applied
OK to gcc 4.8 where the same bug exists - not sure what you developed it
ontop of).  We have a premature optimization in bitmap_find_bit:

@@ -506,7 +858,9 @@ bitmap_find_bit (bitmap head, unsigned i
   if (head->current == NULL
   || head->indx == indx)
 return head->current;
-  if (head->current == head->first
+  /* ???  Premature optimization?  */
+  if (!head->tree_form
+  && head->current == head->first
   && head->first->next == NULL)
 return NULL;

the reginfo.c use-case seems to be gone so I put the use in the SSA
propagator instead where it is supposed to help PR63155.

Meanwhile bitmap_head->descriptor_id is dead so I made tree_form a bool.

Richard.

> Ciao!
> Steven


tree-bitmap
Description: Binary data

Re: [PATCH] v2: Run selftests for C++ as well as C

[David Malcolm]

On Tue, 2018-10-16 at 14:26 -0600, Jeff Law wrote:
> On 10/13/18 7:12 AM, David Malcolm wrote:
> > On Fri, 2018-10-12 at 14:17 -0400, David Malcolm wrote:
> > > On Fri, 2018-10-12 at 14:45 -0400, David Malcolm wrote:
> > > > [re this thread "ToT build failure?":
> > > >   https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ]
> > > > 
> > > > On Thu, 2017-07-06 at 20:58 +0200, Jakub Jelinek wrote:
> > > > > On Thu, Jul 06, 2017 at 01:45:42PM -0400, David Malcolm
> > > > > wrote:
> > > > > > Given that the previous status quo of the selftests was to
> > > > > > require
> > > > > > the
> > > > > > C frontend, I committed the attached patch (as r250036),
> > > > > > under
> > > > > > the
> > > > > > "obvious" rule, retaining the ability to optionally run the
> > > > > > selftests
> > > > > > within the C++ frontend.
> > > > > 
> > > > > You should do something similar for how we make check etc.:
> > > > > CHECK_TARGETS = @check_languages@
> > > > > 
> > > > > check: $(CHECK_TARGETS)
> > > > > 
> > > > > and then each Make-lang.in defining its check- goal.
> > > > > So similarly to that s-selftest-c++ should be in cp/Make-
> > > > > lang.in
> > > > > and based on the configured languages should include the s-
> > > > > selftest-
> > > > > 
> > > > > dependencies.
> > > > > 
> > > > >   Jakub
> > > > 
> > > > Thanks.
> > > > 
> > > > I attemped the above, but it required each Make-lang.in to
> > > > define
> > > > a check- goal, but there are only two that make sense to
> > > > run
> > > > (those that set LANG_HOOKS_RUN_LANG_SELFTESTS: C and C++).
> > > > 
> > > > Rather than add one to every Make-lang.in, I borrowing the
> > > > "append"
> > > > approach used by "lang_checks", so that only the Make-lang.in
> > > > files
> > > > that opt-in to having selftests need to do anything, appending
> > > > their s-selftest- to lang_selftests.
> > > > 
> > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > > > I manually verified that the self-tests were run 6 times: C and
> > > > C++,
> > > > for each of the three stages (each run taking well under a
> > > > second).
> > > > 
> > > > OK for trunk?
> > > 
> > > Sorry; I failed to properly check the case Steve ran into back in
> > > July,
> > > and my patch doesn't handle it (all of the Make-lang.in files are
> > > included, regardless of configuration, via LANG_MAKEFRAGS).
> > > 
> > > I'm working on an updated patch.
> > > 
> > > Dave
> > 
> > Here's an updated version; sorry for the earlier noise.
> > 
> > This one follows the approach you suggested, adding a
> > SELFTEST_TARGETS
> > built from a configure-supplied selftest_languages.  Each Make-
> > lang.in
> > defines a selftest-LANG, which becomes a dependency of "selftest".
> > Almost all of the selftest-LANG are empty, apart from those for c
> > and c++.
> > 
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> > As before, I manually verified that the self-tests were run 6
> > times: c and
> > c++, for each of the three stages (each run taking well under a
> > second).
> > This time I also verified that it builds successfully without c++
> > (via:
> > "--enable-languages=c --disable-bootstrap"), for which it just ran
> > the
> > c selftests.
> > 
> > OK for trunk?
> > 
> > gcc/ChangeLog:
> > * Makefile.in (SELFTEST_TARGETS): New.
> > (selftest) Change from s-selftest-c to $(SELFTEST_TARGETS).
> > (C_SELFTEST_FLAGS, C_SELFTEST_DEPS, s-selftest-c, selftest-c-
> > gdb)
> > (selftest-gdb, selftest-c-valgrind, selftest-valgrind): Move to
> > c/Make-lang.in.
> > (CPP_SELFTEST_FLAGS, CPP_SELFTEST_DEPS, s-selftest-c++)
> > (selftest-c++-gdb, selftest-c++-valgrind): Move to
> > cp/Make-lang.in.
> > * configure: Regenerate.
> > * configure.ac (selftest_languages): New.
> > 
> > gcc/brig/ChangeLog:
> > * Make-lang.in (selftest-brig): New.
> > 
> > gcc/c/ChangeLog:
> > * Make-lang.in (selftest-c): New.
> > (C_SELFTEST_FLAGS, C_SELFTEST_DEPS, s-selftest-c, selftest-c-
> > gdb)
> > (selftest-gdb, selftest-c-valgrind, selftest-valgrind): Move
> > here
> > from gcc/Makefile.in.
> > 
> > gcc/cp/ChangeLog:
> > * Make-lang.in (selftest-c++): New.
> > (CPP_SELFTEST_FLAGS, CPP_SELFTEST_DEPS, s-selftest-c++)
> > (selftest-c++-gdb, selftest-c++-valgrind): Move here from
> > gcc/Makefile.in.
> > 
> > gcc/fortran/ChangeLog:
> > * Make-lang.in (selftest-fortran): New.
> > 
> > gcc/go/ChangeLog:
> > * Make-lang.in (selftest-go): New.
> > 
> > gcc/jit/ChangeLog:
> > * Make-lang.in (selftest-jit): New.
> > 
> > gcc/lto/ChangeLog:
> > * Make-lang.in (selftest-lto): New.
> > 
> > gcc/objc/ChangeLog:
> > * Make-lang.in (selftest-objc): New.
> > 
> > gcc/objcp/ChangeLog:
> > * Make-lang.in (selftest-obj-c++): New.
> > ---
> 
> OK.
> jeff

Thanks; I've committed this to trunk as r265240.

Iain: a heads-up re D: I think you'll need to add an empty 
  selftest-d: 
makefile target to the D frontend's 

Re: VRP: undefined shifting calculation should not need sign bit

[Aldy Hernandez]

On 10/17/18 6:52 AM, Richard Sandiford wrote:

Aldy Hernandez  writes:

On 9/13/18 3:33 AM, Richard Sandiford wrote:

Aldy Hernandez  writes:

On 09/12/2018 12:57 PM, Richard Sandiford wrote:

Aldy Hernandez  writes:

diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index 589fdea4df6..e9ee418e5b2 100644
--- a/gcc/wide-int-range.h
+++ b/gcc/wide-int-range.h
@@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int , wide_int 
,
/* Return TRUE if shifting by range [MIN, MAX] is undefined behavior.  */

inline bool

-wide_int_range_shift_undefined_p (signop sign, unsigned prec,
+wide_int_range_shift_undefined_p (unsigned prec,
  const wide_int , const wide_int )
{
  /* ?? Note: The original comment said this only applied to
@@ -142,7 +142,7 @@ wide_int_range_shift_undefined_p (signop sign, unsigned 
prec,
 behavior from the shift operation.  We cannot even trust
 SHIFT_COUNT_TRUNCATED at this stage, because that applies to rtl
 shifts, and the operation at the tree level may be widened.  */
-  return wi::lt_p (min, 0, sign) || wi::ge_p (max, prec, sign);
+  return wi::sign_mask (min) || wi::ge_p (max, prec, UNSIGNED);


I don't think this is a good idea.  Logically the comparison should
be done relative to the TYPE_SIGN of the type, so I think the original
code was correct.


The operation to calculate undefinedness must be done with the type of
the RHS, as opposed to the type of the entire operation.  This can be
confusing, as most operations use the same type for all operands as well
as for the type of the entire operation.  For example, AFAICT, the
following is valid gimple:

UINT64 = UINT64 << INT32

The original code was doing this (correctly), but since it was confusing
to remember which type to pass, I rewrote the above function to not need
the sign of the RHS.  This came about because in my ranger work, I
passed the wrong type which took forever to find ;-).  My patch avoids
further confusion.

Am I missing a subtle incorrectness in my approach?


The problem is with things like UINT256 << UINT8 vs. UINT256 << INT8.
A range of [128, 131] on the UINT8 would be represented using the same
wide_ints as a range of [-128, -125] on the INT8, but the former is
well-defined while the latter isn't.  Only the TYPE_SIGN tells you
which applies.

The original code got this right, but the new code effectively assumes
all shift amounts are signed, and so would treat UINT8 like INT8.

OK, so no current target actually supports UINT256 AFAIK, so it might
be academic.  But the original point of wide-int.h was to support such
wide types, so they could become a thing in future.

Thanks,
Richard



As promised.  Here is the reversal of the bits you suggested.


Thanks!


I think this is an obvious patch, but would appreciate a sanity peek.

Aldy

commit 38a335af9aa5d72778fbacba247ab2219672da7b
Author: Aldy Hernandez 
Date:   Wed Oct 17 11:25:21 2018 +0200

 * wide-int-range.h (wide_int_range_shift_undefined_p): Adjust to
 use sign as argument.
 * tree-vrp.c (extract_range_from_binary_expr_1): Pass sign to
 wide_int_range_shift_undefined_p.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index cbc2ea2f26b..c519613bb28 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -1521,7 +1521,8 @@ extract_range_from_binary_expr_1 (value_range *vr,
   || code == LSHIFT_EXPR)
  {
if (range_int_cst_p ()
- && !wide_int_range_shift_undefined_p (prec,
+ && !wide_int_range_shift_undefined_p (TYPE_SIGN (TREE_TYPE (vr1.min)),
+   prec,
wi::to_wide (vr1.min),
wi::to_wide (vr1.max)))
{
diff --git a/gcc/wide-int-range.h b/gcc/wide-int-range.h
index e9ee418e5b2..589fdea4df6 100644
--- a/gcc/wide-int-range.h
+++ b/gcc/wide-int-range.h
@@ -131,7 +131,7 @@ extern bool wide_int_range_div (wide_int , wide_int 
,
  /* Return TRUE if shifting by range [MIN, MAX] is undefined behavior.  */
  
  inline bool

-wide_int_range_shift_undefined_p (unsigned prec,
+wide_int_range_shift_undefined_p (signop sign, unsigned prec,
  const wide_int , const wide_int )


Need to add SIGN back to the comment, maybe something like:

   /* Return TRUE if shifting by range [MIN, MAX] is undefined behavior,
  interpreting MIN and MAX according to SIGN.  */

(or whatever you think's best).


Done.

Committed.

Thanks.
Aldy

Re: [v3 PATCH] PR libstdc++/87619

[Jonathan Wakely]

On 17/10/18 15:06 +0300, Ville Voutilainen wrote:

On Wed, 17 Oct 2018 at 12:20, Ville Voutilainen
 wrote:


On Wed, 17 Oct 2018 at 12:07, Jonathan Wakely  wrote:
> It might be worth also calling f<256>() and doing:
>
> template 
> void f_impl(std::index_sequence is)
> {
>   using V = std::variant...>;
>
>   // For a variant of 255 alternatives the valid indices are [0,254]
>   // and index 255 means valueless-by-exception, so fits in one byte.
>   if constexpr (std::variant_size_v <= 255)
> static_assert(sizeof(V) == 2)
>   else
> static_assert(sizeof(V) > 2)
> }
>
> Just to check we don't introduce an off-by-one error in the *other*
> direction in future. What do you think?

Agreed. I'll patch that in.

> To be really portable we would use numeric_limits::max()
> but we don't need to worry about non-8-bit char in our implementation.

I can change that as well so that we don't need to re-think it every time.


Here.


Great, thanks for the changes - OK for trunk.

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Uecker, Martin]

Am Mittwoch, den 17.10.2018, 13:30 +0100 schrieb Richard Sandiford:
> [ Sorry that there were so many typos in my last reply, will try to
> do better
>   this time... ]

...
> I think the key difference between sizeless types and full C99-style
> VLAs is that the size and layout of sizeless types never matters for
> semantic analysis.  Rather than the sizes of types becoming variable
> (and the offsets of members becoming variable, and constexprs
> becoming
> variable-sized, etc.), we simply don't make those concepts available
> for sizeless types.
> 
> So nothing at the language level becomes variable that was constant
> before.
> All that happens is that some things become invalid for sizeless
> types
> that would be valid for sized ones.
> 
> The idea was really for the language to provide a framework for
> implementations to define implementation-specific types with
> implementation-specific rules while disturbing the language itself
> as little as possible.

I guess this makes it much easier for C++, but also much less useful.
Surely, the processor knows the size when it computes using these
types, so one could make it available using 'sizeof'. If a value
of the type is stores in addressable memory (on the stack), can't
we also store the size so that it is available for other threads? 
Just making it undefined to access a variable with the wong size
for the current thread seems rather fragile to me. 

Best,
Martin

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Joseph Myers]

On Wed, 17 Oct 2018, Richard Sandiford wrote:

> > But as shown in the related discussions, there are other possible features 
> > that might also involve non-VLA types whose size is not a compile-time 
> > constant.  And so it's necessary to work with the people interested in 
> > those features in order to clarify what the underlying concepts ought to 
> > look like to support different such features.
> 
> Could you give pointers to the specific proposals/papers you mean?

They're generally reflector discussions rather than written up as papers, 
exploring the space of problems and solutions in various areas (including 
bignums and runtime introspection of types).  I think the first message in 
those discussions is number 15529 
 and then relevant 
discussions continue for much of the next 200 messages or so.

> ...and here is that any size changes come only from changes in the
> implementation-defined built-in sizeless types.  The user can't define

But then I think you still need to define in the standard edits something 
of what the type-compatibility rules are.

> > Can these types be passed to variadic functions and named in va_arg?  
> > Again, I don't see anything to say they can't.
> 
> Yes, this is allowed (and covered by the tests FWIW).

How does that work with not knowing the size even at runtime?

At least, this seems like another place where there would be special type 
compatibility considerations that need to be applied between caller and 
callee.

> Except for bit-fields *and sizeless structures*, objects are
> composed of contiguous sequences of one or more bytes, the number,
> order, and encoding of which are either explicitly specified or
> implementation-defined.
> 
> TBH the possibility of a discontiguous representation was an early idea
> that we've never actually used so far, so if that's a problem, we could
> probably drop it.  It just seemed to be a natural extension of the
> principle that the layout is completely implementation-defined.

If you have discontiguous representations, I don't see how "->" on 
structure pointers (or indeed unary "*") is supposed to work; disallowing 
discontiguous representations would seem to fit a lot more naturally with 
the C object model.

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

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Richard Sandiford]

"Uecker, Martin"  writes:
> Am Mittwoch, den 17.10.2018, 13:30 +0100 schrieb Richard Sandiford:
>> [ Sorry that there were so many typos in my last reply, will try to
>> do better
>>   this time... ]
>
> ...
>> I think the key difference between sizeless types and full C99-style
>> VLAs is that the size and layout of sizeless types never matters for
>> semantic analysis.  Rather than the sizes of types becoming variable
>> (and the offsets of members becoming variable, and constexprs
>> becoming
>> variable-sized, etc.), we simply don't make those concepts available
>> for sizeless types.
>> 
>> So nothing at the language level becomes variable that was constant
>> before.
>> All that happens is that some things become invalid for sizeless
>> types
>> that would be valid for sized ones.
>> 

>> The idea was really for the language to provide a framework for
>> implementations to define implementation-specific types with
>> implementation-specific rules while disturbing the language itself
>> as little as possible.
>
> I guess this makes it much easier for C++, but also much less useful.

Yeah, can't deny that if you look at it as a general-purpose extension.
But that's not really what this is supposed to be.  It's fairly special
purpose: there has to be some underlying variable-length/sizeless
built-in type that you want to provide via a library.

What the extension allows is enough to support the intended use case,
and it does that with no enforced overhead.

The examples with one thread accessing a vector from a different thread
aren't interesting in practice; any sharing or caching should happen via
normal arrays or malloced memory instead.  These corner cases are just
something that needs to be addressed once you allow pointers to things.

> Surely, the processor knows the size when it computes using these
> types, so one could make it available using 'sizeof'.

The argument's similar here: we don't really need sizeof to be available
for vector use because the library provides easy ways of getting
vector-length-based constants.  Usually what you want to know is
"how many elements of type X are there?", with bytes just being one
of the available element sizes.

And of course, making sizeof variable would be a can of worms in C++...
(The rejected ARB proposal didn't try to do that.)

> If a value of the type is stores in addressable memory (on the stack),
> can't we also store the size so that it is available for other threads? 

But the problem is that once the size becomes a part of the object,
it becomes difficult to get rid of it again for the intended use case.
E.g. say a vector is passed on the stack due to running out of registers.
Does the caller provide both the size and the contents, or just the
contents?  In the latter case it would be the callee's reponsibility
to "fill in" the missing size, but at what point should it compute the
size?  In the former case, would a callee-copies ABI require the callee
to copy the contents with the size given in the argument or the value
that the callee would use if it were creating an object from scratch?

These aren't insurmountable problems.  They just seem like an unnecessary
complication when the only reason for doing them is to support sizeof,
which isn't something that the use case needs.

Also, storing the size with the object would make the size field
*become* part of the size of the object, so sizeof (vector) would give
you something bigger than the size of the vector itself.  It would also
open up oddities like:

  sizeof (x) != sizeof (typeof (x))

being false in some cases.  I.e. even if sizeof (x) correctly reported
the size that an object x actually has, it isn't necessarily the size
that a new object of that type would have, so users would have to be
very careful about what they ask.  I think both these things would just
open the door to more confusion.

> Just making it undefined to access a variable with the wong size for the
> current thread seems rather fragile to me.

In many ways it seems similar to memory management.  It's the
programmer's responsibility to ensure that they don't access vectors
with the "wrong" size in the same way that it's their responsibility
not to dereference freed memory or access beyond the amount of memory
allocated.

And as I mentioned above, noone should be doing that anyway :-)
These types shouldn't live longer than a vector loop, with that loop
potentially calling functions that are easily identified as "vector
functions".

Thanks,
Richard

Re: [00/10][RFC] Splitting the C and C++ concept of "complete type"

[Joseph Myers]

On Wed, 17 Oct 2018, Richard Sandiford wrote:

> Yeah, can't deny that if you look at it as a general-purpose extension.
> But that's not really what this is supposed to be.  It's fairly special
> purpose: there has to be some underlying variable-length/sizeless
> built-in type that you want to provide via a library.
> 
> What the extension allows is enough to support the intended use case,
> and it does that with no enforced overhead.

Part of my point is that there are various *other* possible cases of 
non-VLA-variable-size-type people have suggested in WG14 reflector 
discussions - so any set of concepts for such types ought to take into 
account more than just the SVE use case (even if other use cases need 
further concepts added on top of the ones needed for SVE).

> > Surely, the processor knows the size when it computes using these
> > types, so one could make it available using 'sizeof'.
> 
> The argument's similar here: we don't really need sizeof to be available
> for vector use because the library provides easy ways of getting
> vector-length-based constants.  Usually what you want to know is
> "how many elements of type X are there?", with bytes just being one
> of the available element sizes.

But if having sizeof available makes for a more natural language feature 
(one where a few places referencing VLAs need to change to reference a 
more general class of variable-size types, and a few constraints on VLAs 
and variably modified types need to be relaxed to allow what you want with 
these types), that may be a case for doing so, even if sizeof won't 
generally be used.

If the processor in fact knows the size, do you actually need to include 
it in the object to be able to provide it when sizeof is called?  (With 
undefined behavior still present if passing the object from a thread with 
one value of sizeof for that type to a thread with a different value of 
sizeof for that type, of course - the rule on VLA type compatibility would 
still need to be extended to apply to sizes of these types, and those they 
contain, recursively.)

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

RE: [PATCH 3/6] [ARC] Add BI/BIH instruction support.

[Claudiu Zissulescu]

Hi,

> 
> This removes the compact-casesi as an option for earlier ARC, right?
> Was there a reason why that had to be done?
> 

The compact-casesi was only designed for ARCv1 types of CPUs. Unfortunately, it 
was error prone leading to all kinds of runtime and compile time errors. Fixing 
it will nullify most of the advantages of using this format. Hence, I've remove 
it, leaving the standard implementation for all CPUS. 
The BI/BIH are two new instructions for ARCv2, and they should be friendly with 
the cache, but I couldn't prove that, hence they are guarded by an option.

Please let me know if you want to have compact-casesi back in the compiler.

Thanks,
Claudiu

Re: [patch] new API for value_range

[Aldy Hernandez]

On 10/17/18 6:50 AM, Richard Biener wrote:

On Thu, Oct 11, 2018 at 8:25 PM Aldy Hernandez  wrote:




On 10/11/18 5:47 AM, Richard Biener wrote:

On Thu, Oct 11, 2018 at 10:19 AM Aldy Hernandez  wrote:


Hi Richard.  Thanks for reviewing.

On 10/10/18 6:27 AM, Richard Biener wrote:

On Tue, Oct 9, 2018 at 6:23 PM Aldy Hernandez  wrote:


I'm assuming the silence on the RFC means nobody is viscerally opposed
to it, so here goes the actual implementation ;-).

   FWI: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00157.html

My aim is no change to the current functionality, but there are some
things that changed slightly (with no appreciable change in
bootstrapability or tests).

1.  Primarily, we were building value_ranges by modifying them in-flight
with no regards to the validity of the resulting range.  By enforcing
the API, I noticed we periodically built VR_VARYING / VR_UNDEFINED, but
left the equivalence bits uncleared.  This comment in the original
header file indicates that this is invalid behavior:

  /* Set of SSA names whose value ranges are equivalent to this one.
 This set is only valid when TYPE is VR_RANGE or VR_ANTI_RANGE.  */

The API now enforces this upon construction.

2. I also saw us setting min/max when VARYING or UNDEFINED was set.
This is invalid.  Although these values were being ignored, the API now
enforces this.

3. I saw one case in set_value_range_with_overflow() were we were
building an invalid range with swapped ranges, where we were silently
depending on somebody further up the call chain to swap them for us.
I've fixed this at creation.

4. There is one assert in ipcp_vr_lattice which I hope to remove, but
left as proof that the original VR_UNDEFINED set was not necessary, as
it is now done by default on an empty constructor:

-  void init () { m_vr.type = VR_UNDEFINED; }
+  void init () { gcc_assert (m_vr.undefined_p ()); }

One last note.  The file tree-vrp.c already has a cripple API of sorts
in the form of functions (set_value_range_to_varying, etc).  I have
tried to keep those functions available, by calling the API under the
covers, but would be okay in removing them altogether as a follow-up.

Please refer to the RFC wrt the min/max/vrtype accessors, as well as the
new tree type field.

I am quoting the class declaration below to make it easy to review at a
high level.

Tested on x86-64 Linux.  All languages, including Ada and Go.

OK for trunk?


Reviewing in patch order.


Aldy

class GTY((for_user)) value_range
{
 public:
  value_range ();
  value_range (tree type);
  value_range (value_range_type, tree type, tree, tree, bitmap = NULL);
  bool operator== (const value_range &) const;
  bool operator!= (const value_range &) const;
  void intersect (const value_range *);
  void union_ (const value_range *);


with trailing underscore?  seriously?


Hey!  You complained about Union() last year, at which point the
consensus was that trailing underscores would be ok for symbol names
that clashed with keywords.


;)

I also thought about union_into / union_with.  As opposed to a hypothetical

value_range union (const value_range& a, const value_range& b)

function.


And yes, it was also discussed whether we should overload | and ^ for
union and intersection, but was denied for readability and what have yous.




  /* Like operator== but ignore equivalence bitmap.  */
  bool ignore_equivs_equal_p (const value_range &) const;
  /* Like a operator= but update equivalence bitmap efficiently.  */
  void copy_with_equiv_update (const value_range *);

  /* Types of value ranges.  */
  bool undefined_p () const;
  bool varying_p () const;
  bool symbolic_p () const;
  bool numeric_p () const;
  void set_undefined (tree = NULL);
  void set_varying (tree = NULL);


I'd appreciate comments on those predicates, esp. as you
replace positive tests by negative ones like in


Done.



  /* If we found any usable VR, set the VR to ssa_name and create a
 PUSH old value in the stack with the old VR.  */
-  if (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE)
+  if (!vr.undefined_p () && !vr.varying_p ())
{

I'd also spell numeric_p as constant_p or drop it alltogether
since !symbolic_p should imply it given varying_p and undefined_p
are just some special-cases of "numeric_p" (full and empty range).


Done.



That said, for the time being I'd use non_symbolic_range_or_anti_range_p
instead of numeric_p () (seeing that you maybe want to hide the fact
that we have anti-ranges?)


Errr... No.



-  value_range vr = VR_INITIALIZER;
+  value_range vr (TREE_TYPE (name));

so you basically forgo with the fact that empty ranges are universal?
I don't like it too much that we have to invent a type here.  Why enforce this
and not allow/force type == NULL_TREE for empty ranges?

One could argue VARYING is also universal to some extent and useful
only with context, so similar