Re: [14/n] PR85694: Rework overwidening detection

[Richard Sandiford]

Christophe Lyon  writes:
> On Tue, 3 Jul 2018 at 12:02, Richard Sandiford
>  wrote:
>>
>> Richard Biener  writes:
>> > On Fri, Jun 29, 2018 at 1:36 PM Richard Sandiford
>> >  wrote:
>> >>
>> >> Richard Sandiford  writes:
>> >> > This patch is the main part of PR85694.  The aim is to recognise
> at least:
>> >> >
>> >> >   signed char *a, *b, *c;
>> >> >   ...
>> >> >   for (int i = 0; i < 2048; i++)
>> >> > c[i] = (a[i] + b[i]) >> 1;
>> >> >
>> >> > as an over-widening pattern, since the addition and shift can be done
>> >> > on shorts rather than ints.  However, it ended up being a lot more
>> >> > general than that.
>> >> >
>> >> > The current over-widening pattern detection is limited to a few simple
>> >> > cases: logical ops with immediate second operands, and shifts by a
>> >> > constant.  These cases are enough for common pixel-format conversion
>> >> > and can be detected in a peephole way.
>> >> >
>> >> > The loop above requires two generalisations of the current code: support
>> >> > for addition as well as logical ops, and support for non-constant second
>> >> > operands.  These are harder to detect in the same peephole way, so the
>> >> > patch tries to take a more global approach.
>> >> >
>> >> > The idea is to get information about the minimum operation width
>> >> > in two ways:
>> >> >
>> >> > (1) by using the range information attached to the SSA_NAMEs
>> >> > (effectively a forward walk, since the range info is
>> >> > context-independent).
>> >> >
>> >> > (2) by back-propagating the number of output bits required by
>> >> > users of the result.
>> >> >
>> >> > As explained in the comments, there's a balance to be struck between
>> >> > narrowing an individual operation and fitting in with the surrounding
>> >> > code.  The approach is pretty conservative: if we could narrow an
>> >> > operation to N bits without changing its semantics, it's OK to do
> that if:
>> >> >
>> >> > - no operations later in the chain require more than N bits; or
>> >> >
>> >> > - all internally-defined inputs are extended from N bits or fewer,
>> >> >   and at least one of them is single-use.
>> >> >
>> >> > See the comments for the rationale.
>> >> >
>> >> > I didn't bother adding STMT_VINFO_* wrappers for the new fields
>> >> > since the code seemed more readable without.
>> >> >
>> >> > Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
>> >>
>> >> Here's a version rebased on top of current trunk.  Changes from last time:
>> >>
>> >> - reintroduce dump_generic_expr_loc, with the obvious change to the
>> >>   prototype
>> >>
>> >> - fix a typo in a comment
>> >>
>> >> - use vect_element_precision from the new version of 12/n.
>> >>
>> >> Tested as before.  OK to install?
>> >
>> > OK.
>>
>> Thanks.  For the record, here's what I installed (updated on top of
>> Dave's recent patch, and with an obvious fix to vect-widen-mult-u8-u32.c).
>>
>> Richard
>>
> Hi,
>
> It seems the new bb-slp-over-widen tests lack a -fdump option:
> gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects : dump file
> does not exist
> UNRESOLVED: gcc.dg/vect/bb-slp-over-widen-2.c -flto -ffat-lto-objects
> scan-tree-dump-times vect "basic block vectorized" 2

I've applied the following as obvious.

Richard


2018-07-04  Richard Sandiford  

gcc/testsuite/
* gcc.dg/vect/bb-slp-over-widen-1.c: Fix name of dump file for
final scan test.
* gcc.dg/vect/bb-slp-over-widen-2.c: Likewise.

Index: gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c
===
--- gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c 2018-07-03 
10:59:30.480481417 +0100
+++ gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c 2018-07-04 
08:16:36.210113069 +0100
@@ -63,4 +63,4 @@ main (void)
 
 /* { dg-final { scan-tree-dump "demoting int to signed short" "slp2" { target 
{ ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump "demoting int to unsigned short" "slp2" { 
target { ! vect_widen_shift } } } } */
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "vect" } } */
+/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" } } */
Index: gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-2.c
===
--- gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-2.c 2018-07-03 
10:59:30.480481417 +0100
+++ gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-2.c 2018-07-04 
08:16:36.210113069 +0100
@@ -62,4 +62,4 @@ main (void)
 
 /* { dg-final { scan-tree-dump "demoting int to signed short" "slp2" { target 
{ ! vect_widen_shift } } } } */
 /* { dg-final { scan-tree-dump "demoting int to unsigned short" "slp2" { 
target { ! vect_widen_shift } } } } */
-/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "vect" } } */
+/* { dg-final { scan-tree-dump-times "basic block vectorized" 2 "slp2" } } */

Re: [PATCH] relax lower bound for infinite arguments in gimple-ssa-sprinf.c (PR 86274)

[Richard Biener]

On Tue, 3 Jul 2018, Martin Sebor wrote:

> Committed to trunk in r86274.  Jakub/Richard, can you please
> also review and approve the corresponding fix for the release
> branches?

If it is a regression and the patch was approved for trunk it is
automatically OK for release branches without further review unless
you think it is too invasive.

Richard.

> Martin
> 
> On 07/03/2018 06:32 PM, Jeff Law wrote:
> > On 07/03/2018 04:50 PM, Martin Sebor wrote:
> > > In computing the size of expected output for non-constant floating
> > > arguments the sprintf pass doesn't consider the possibility that
> > > the argument value may be not finite (i.e., it can be infinity or
> > > NaN).  Infinities and NaNs are formatted as "inf" or "infinity"
> > > and "nan".  As a result, any floating directive can produce as
> > > few bytes on output as three for an non-finite argument, when
> > > the least amount directives such as %f produce for finite
> > > arguments is 8.
> > > 
> > > The attached patch adjusts the floating point code to correctly
> > > reflect the lower bound.
> > > 
> > > Martin
> > > 
> > > gcc-86274.diff
> > > 
> > > 
> > > PR tree-optimization/86274 - SEGFAULT when logging std::to_string(NAN)
> > > 
> > > gcc/ChangeLog:
> > > 
> > >   PR tree-optimization/86274
> > >   * gimple-ssa-sprintf.c (fmtresult::type_max_digits): Verify
> > >   precondition.
> > >   (format_floating): Correct handling of infinities and NaNs.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   PR tree-optimization/86274
> > >   * gcc.dg/tree-ssa/builtin-sprintf-9.c: New test.
> > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.
> > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: Same.
> > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Same.
> > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Same.
> > >   * gcc.dg/tree-ssa/builtin-sprintf.c: Same.
> > >   * gcc.dg/tree-ssa/pr83198.c: Same.
> > OK
> > jeff
> > 
> 
> 

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

Re: extract_range_from_binary* cleanups for VRP

[Martin Liška]

On 07/03/2018 07:48 PM, Aldy Hernandez wrote:
> 
> 
> On 07/03/2018 08:16 AM, Martin Liška wrote:
>> Hi.
>>
>> It caused UBSAN errors:
>>
>> $ cat ubsan.i
>> int a;
>> void d() { int c, b = 8 - a; }
>>
>> $ /home/marxin/Programming/gcc2/objdir/./gcc/xgcc 
>> -B/home/marxin/Programming/gcc2/objdir/./gcc/ ubsan.i -c -O2
>> ../../gcc/tree-vrp.c:1715:26: runtime error: load of value 255, which is not 
>> a valid value for type 'bool'
>>  #0 0x3246ca2 in extract_range_from_binary_expr_1(value_range*, 
>> tree_code, tree_node*, value_range*, value_range*) ../../gcc/tree-vrp.c:1715
>>  #1 0x34aa8b6 in vr_values::extract_range_from_binary_expr(value_range*, 
>> tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/vr-values.c:794
>>  #2 0x34b45fa in vr_values::extract_range_from_assignment(value_range*, 
>> gassign*) ../../gcc/vr-values.c:1455
>>  #3 0x494cfd5 in evrp_range_analyzer::record_ranges_from_stmt(gimple*, 
>> bool) ../../gcc/gimple-ssa-evrp-analyze.c:293
>>  #4 0x4942548 in evrp_dom_walker::before_dom_children(basic_block_def*) 
>> ../../gcc/gimple-ssa-evrp.c:139
>>  #5 0x487652b in dom_walker::walk(basic_block_def*) 
>> ../../gcc/domwalk.c:353
>>  #6 0x49470f9 in execute_early_vrp ../../gcc/gimple-ssa-evrp.c:310
>>  #7 0x49470f9 in execute ../../gcc/gimple-ssa-evrp.c:347
>>  #8 0x1fc4a0e in execute_one_pass(opt_pass*) ../../gcc/passes.c:2446
>>  #9 0x1fc8b47 in execute_pass_list_1 ../../gcc/passes.c:2535
>>  #10 0x1fc8b8e in execute_pass_list_1 ../../gcc/passes.c:2536
>>  #11 0x1fc8c68 in execute_pass_list(function*, opt_pass*) 
>> ../../gcc/passes.c:2546
>>  #12 0x2004c85 in do_per_function_toporder(void (*)(function*, void*), 
>> void*) ../../gcc/passes.c:1688
>>  #13 0x2005e9a in execute_ipa_pass_list(opt_pass*) 
>> ../../gcc/passes.c:2894
>>  #14 0xfcfa79 in ipa_passes ../../gcc/cgraphunit.c:2400
>>  #15 0xfcfa79 in symbol_table::compile() ../../gcc/cgraphunit.c:2536
>>  #16 0xfdc52a in symbol_table::finalize_compilation_unit() 
>> ../../gcc/cgraphunit.c:2696
>>  #17 0x25115e4 in compile_file ../../gcc/toplev.c:479
>>  #18 0x9278af in do_compile ../../gcc/toplev.c:2086
>>  #19 0x9278af in toplev::main(int, char**) ../../gcc/toplev.c:2221
>>  #20 0x92a79a in main ../../gcc/main.c:39
>>  #21 0x7659c11a in __libc_start_main ../csu/libc-start.c:308
>>  #22 0x92a8c9 in _start 
>> (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x92a8c9)
>>
>> It's because neg_min_op0, or any other from:
>>    bool neg_min_op0, neg_min_op1, neg_max_op0, neg_max_op1;
> 
> I see.
> 
> After this spaghetti...
> 
>  if (vr0.type == VR_RANGE && vr1.type == VR_RANGE
>   && (TREE_CODE (min_op0) == INTEGER_CST
>   || (sym_min_op0
>   = get_single_symbol (min_op0, &neg_min_op0, &min_op0)))
>   && (TREE_CODE (min_op1) == INTEGER_CST
>   || (sym_min_op1
>   = get_single_symbol (min_op1, &neg_min_op1, &min_op1)))
>   && (!(sym_min_op0 && sym_min_op1)
>   || (sym_min_op0 == sym_min_op1
>   && neg_min_op0 == (minus_p ? neg_min_op1 : !neg_min_op1)))
>   && (TREE_CODE (max_op0) == INTEGER_CST
>   || (sym_max_op0
>   = get_single_symbol (max_op0, &neg_max_op0, &max_op0)))
>   && (TREE_CODE (max_op1) == INTEGER_CST
>   || (sym_max_op1
>   = get_single_symbol (max_op1, &neg_max_op1, &max_op1)))
>   && (!(sym_max_op0 && sym_max_op1)
>   || (sym_max_op0 == sym_max_op1
>   && neg_max_op0 == (minus_p ? neg_max_op1 : !neg_max_op1
> 
> ...we would never actually use the neg*op* variables inside the 
> adjust_symbolic_bound code.
> 
> Does this patch fix the problem on your end?
> 
> If so, OK for trunk?

Hi.

I can confirm now ubsan bootstrap succeeded for me.

Thank you for the quick fix.
Martin

[PATCH] Fix PR84829

[Richard Biener]

The following removes adding -lieee to the link command when -mieee-fp
is specified for GNU targets as suggested by Joseph in the PR.  It doesn't
touch m32r so the fix may be incomplete depending on the C library used.

I've added a testcase that makes sure we can link but not functional
tests of -mieee-fp which I suppose exist already (eh...).

Bootstrap and regtest is running on x86_64-unknown-linux-gnu with
glibc 2.27 where the testcase fails before the patch.

OK for trunk and active branches?

Thanks,
Richard.

>From a71f976df0f17790202c0a692920c9d67e009259 Mon Sep 17 00:00:00 2001
From: Richard Guenther 
Date: Wed, 4 Jul 2018 09:34:14 +0200
Subject: [PATCH] fix-pr84829

2018-07-04  Richard Biener  

PR target/84829
* config/gnu-user.h (GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC):
Remove -mieee-fp handling.

* gcc.target/i386/pr84829.c: New testcase.

diff --git a/gcc/config/gnu-user.h b/gcc/config/gnu-user.h
index cba3c0b92e3..8620de3e42d 100644
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -123,7 +123,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 
 #define GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC \
   "%{shared:-lc} \
-   %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}"
+   %{!shared:%{profile:-lc_p}%{!profile:-lc}}"
 
 #define GNU_USER_TARGET_LIB_SPEC \
   "%{pthread:-lpthread} " \
diff --git a/gcc/testsuite/gcc.target/i386/pr84829.c 
b/gcc/testsuite/gcc.target/i386/pr84829.c
new file mode 100644
index 000..a63a49b1317
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr84829.c
@@ -0,0 +1,7 @@
+/* { dg-do link } */
+/* { dg-options "-mieee-fp" } */
+
+int main()
+{
+  return 0;
+}

Re: [PATCH] Fix bootstrap on ia64 with old GCC version.

[Martin Liška]

On 07/03/2018 07:32 PM, Jakub Jelinek wrote:
> On Tue, Jul 03, 2018 at 07:22:19PM +0200, Martin Liška wrote:
>> In order to make GCC 4.1 happy and build current tip, we need to define
>> static constants out of a class definition.
>>
>> Ready for trunk?
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-07-03  Martin Liska  
>>
>>  * tree-switch-conversion.h (struct jump_table_cluster): Define
>> constant values outside of class declaration.
> 
> That looks incorrect.  I don't see why 4.1 wouldn't allow the const static
> data members initializers inside of the class.
> 
> You just need to define those vars, and the definition (without the
> initializers) shouldn't go into the header, but to a single .c file instead
> (I know right now there is just one .c file that includes this header, but
> if we ever want to include it in more than one, it would be a problem;
> if we never want to include in more than one, the question is why we have
> the header file at all).
> 
> So IMHO keep tree-switch-conversion.h unmodified and add:
> 
> const unsigned HOST_WIDE_INT jump_table_cluster::max_ratio_for_size;
> const unsigned HOST_WIDE_INT jump_table_cluster::max_ratio_for_speed;
> 
> to tree-switch-conversion.c somewhere.

Hi.

Thanks Jakub, works for me both on x86_64 with a recent compiler and
ia64 with GCC 4.1.

I'm going to install that.

Martin

> 
>> diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-conversion.h
>> index 4beac785f05..8efb125aff1 100644
>> --- a/gcc/tree-switch-conversion.h
>> +++ b/gcc/tree-switch-conversion.h
>> @@ -259,12 +259,17 @@ struct jump_table_cluster: public group_cluster
>>static bool is_enabled (void);
>>  
>>/* Max growth ratio for code that is optimized for size.  */
>> -  static const unsigned HOST_WIDE_INT max_ratio_for_size = 3;
>> +  static const unsigned HOST_WIDE_INT max_ratio_for_size;
>>  
>>/* Max growth ratio for code that is optimized for speed.  */
>> -  static const unsigned HOST_WIDE_INT max_ratio_for_speed = 8;
>> +  static const unsigned HOST_WIDE_INT max_ratio_for_speed;
>>  };
>>  
>> +const unsigned HOST_WIDE_INT jump_table_cluster::max_ratio_for_size = 3;
>> +
>> +const unsigned HOST_WIDE_INT jump_table_cluster::max_ratio_for_speed = 8;
>> +
>> +
>>  /* A GIMPLE switch statement can be expanded to a short sequence of bit-wise
>>  comparisons.  "switch(x)" is converted into "if ((1 << (x-MINVAL)) & CST)"
>>  where CST and MINVAL are integer constants.  This is better than a series
>>
> 
> 
>   Jakub
> 

Re: [patch, fortran] Asynchronous I/O, take 3

[Rainer Orth]

Hi Thomas,

> Ah, I see what was wrong.
>
> The attached patch should fix this.

it almost did the trick indeed.  With the new patch, only two failures
remain:

FAIL: gfortran.dg/flush_1.f90   -O0  execution test
FAIL: gfortran.dg/flush_1.f90   -O1  execution test
FAIL: gfortran.dg/flush_1.f90   -O2  execution test
FAIL: gfortran.dg/flush_1.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/flush_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/flush_1.f90   -Os  execution test
FAIL: gfortran.dg/newunit_1.f90   -O0  execution test
FAIL: gfortran.dg/newunit_1.f90   -O1  execution test
FAIL: gfortran.dg/newunit_1.f90   -O2  execution test
FAIL: gfortran.dg/newunit_1.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/newunit_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/newunit_1.f90   -Os  execution test

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
Segmentation Fault

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfe1b1773 in mutex_lock_impl () from /lib/libc.so.1
(gdb) where
#0  0xfe1b1773 in mutex_lock_impl () from /lib/libc.so.1
#1  0xfe1b1a03 in pthread_mutex_lock () from /lib/libc.so.1
#2  0xfe5d1da4 in __gthread_mutex_lock (__mutex=0x18)
at ../libgcc/gthr-default.h:748
#3  _gfortran_st_flush (fpp=0xfeffda40)
at /vol/gcc/src/hg/trunk/solaris/libgfortran/io/file_pos.c:514
#4  0x0805106f in flush_1 ()
at /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gfortran.dg/flush_1.f90:11
#5  0x080512a7 in main (argc=1, argv=0xfeffdbfa)
at /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gfortran.dg/flush_1.f90:28
#6  0x08050de6 in _start ()

I've not yet investigated why they only occur for 32-bit.  I tried the
following snippet to fix them

--- libgfortran/io/file_pos.c.save	2018-07-03 22:48:42.485018736 +
+++ libgfortran/io/file_pos.c	2018-07-04 07:51:43.494582145 +
@@ -511,7 +511,8 @@ st_flush (st_parameter_filepos *fpp)
   else
 	{
 	  needs_unlock = true;
-	  LOCK (&u->au->io_lock);
+	  if (u->au)
+	LOCK (&u->au->io_lock);
 	}
 
   /* Make sure format buffer is flushed.  */

which did so indeed, but now there's another failure, again 32-bit only:

FAIL: gfortran.dg/eof_4.f90   -O0  execution test
FAIL: gfortran.dg/eof_4.f90   -O1  execution test
FAIL: gfortran.dg/eof_4.f90   -O2  execution test
FAIL: gfortran.dg/eof_4.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loo
ps -ftracer -finline-functions  execution test
FAIL: gfortran.dg/eof_4.f90   -O3 -g  execution test
FAIL: gfortran.dg/eof_4.f90   -Os  execution test

At line 12 of file 
/vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gfortran.dg/eof_4.f90 (unit = 99)
Fortran runtime error: Cannot open file 'test.dat': File exists

Error termination. Backtrace:

Rainer

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

Re: [PATCH] P0556R3 Integral power-of-2 operations, P0553R2 Bit operations

[Jonathan Wakely]

On 03/07/18 23:23 +0100, Jonathan Wakely wrote:

On 03/07/18 23:40 +0200, Jakub Jelinek wrote:

On Tue, Jul 03, 2018 at 10:02:47PM +0100, Jonathan Wakely wrote:

+#ifndef _GLIBCXX_BIT
+#define _GLIBCXX_BIT 1
+
+#pragma GCC system_header
+
+#if __cplusplus >= 201402L
+
+#include 
+#include 
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  template
+constexpr _Tp
+__rotl(_Tp __x, unsigned int __s) noexcept
+{
+  constexpr auto _Nd = numeric_limits<_Tp>::digits;
+  const unsigned __sN = __s % _Nd;
+  if (__sN)
+return (__x << __sN) | (__x >> (_Nd - __sN));


Wouldn't it be better to use some branchless pattern that
GCC can also optimize well, like:
return (__x << __sN) | (__x >> ((-_sN) & (_Nd - 1)));
(iff _Nd is always power of two),


_Nd is 20 for one of the INT_N types on msp340, but we could have a
special case for the rare integer types with unusual sizes.


or perhaps
return (__x << __sN) | (__x >> ((-_sN) % _Nd));
which is going to be folded into the above one for power of two constants?


That looks good.


Committed as attached (with a test I forgot to add for popcount).


commit 796e90be02c691bc57c89172940aa047caa199ab
Author: Jonathan Wakely 
Date:   Wed Jul 4 00:07:43 2018 +0100

Optimize std::rotl and std::rotr, add test for std::popcount

* include/std/bit (__rotl, __rotr): Avoid branch.
(_If_is_unsigned_integer): Use remove_cv_t.
* testsuite/26_numerics/bit/bitops.count/popcount.cc: New.

diff --git a/libstdc++-v3/include/std/bit b/libstdc++-v3/include/std/bit
index 76aa0957b56..ace88954030 100644
--- a/libstdc++-v3/include/std/bit
+++ b/libstdc++-v3/include/std/bit
@@ -46,9 +46,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   constexpr auto _Nd = numeric_limits<_Tp>::digits;
   const unsigned __sN = __s % _Nd;
-  if (__sN)
-return (__x << __sN) | (__x >> (_Nd - __sN));
-  return __x;
+  return (__x << __sN) | (__x >> ((-__sN) % _Nd));
 }
 
   template
@@ -57,9 +55,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   constexpr auto _Nd = numeric_limits<_Tp>::digits;
   const unsigned __sN = __s % _Nd;
-  if (__sN)
-return (__x >> __sN) | (__x << (_Nd - __sN));
-  return __x;
+  return (__x >> __sN) | (__x << ((-__sN) % _Nd));
 }
 
   template
@@ -237,7 +233,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 using _If_is_unsigned_integer
-  = typename _If_is_unsigned_integer_type<_Tp, _Up>::type;
+  = typename _If_is_unsigned_integer_type, _Up>::type;
 
 #if ! __STRICT_ANSI__
   // [bitops.rot], rotating
diff --git a/libstdc++-v3/testsuite/26_numerics/bit/bitops.count/popcount.cc b/libstdc++-v3/testsuite/26_numerics/bit/bitops.count/popcount.cc
new file mode 100644
index 000..2982cb19bbe
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/bit/bitops.count/popcount.cc
@@ -0,0 +1,108 @@
+// 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-do run { target c++11 } }
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+
+template
+constexpr auto
+test(UInt x)
+-> decltype(std::popcount(x))
+{
+  static_assert( noexcept(std::popcount(x)) );
+
+  constexpr unsigned digits = std::numeric_limits::digits;
+
+  static_assert( std::popcount((UInt)0) == 0 );
+  static_assert( std::popcount((UInt)-1) == digits );
+  static_assert( std::popcount((UInt)-2) == digits - 1 );
+  static_assert( std::popcount((UInt)127) == 7 );
+
+  static_assert( std::popcount((UInt)1) == 1 );
+  static_assert( std::popcount((UInt)2) == 1 );
+  static_assert( std::popcount((UInt)0x70) == 3 );
+
+  if constexpr (std::numeric_limits::digits > 8)
+  {
+static_assert( std::popcount((UInt)(0x101)) == 2 );
+static_assert( std::popcount((UInt)(0xfff)) == 12 );
+  }
+
+  if constexpr (std::numeric_limits::digits > 64)
+  {
+static_assert( std::popcount((UInt)0x) == 64 );
+static_assert( std::popcount(0x | ((UInt)1 << 64)) == 33 );
+static_assert( std::popcount(0x | ((UInt)3 << 64)) == 34 );
+  }
+
+  return true;
+}
+
+static_assert( test( (unsigned char)0 ) );
+static_assert( test( (unsigned short)0 ) );
+static_as

Re: [PATCH] P0556R3 Integral power-of-2 operations, P0553R2 Bit operations

[Jakub Jelinek]

On Tue, Jul 03, 2018 at 11:24:00PM +0100, Jonathan Wakely wrote:
> > Wouldn't it be better to use some branchless pattern that
> > GCC can also optimize well, like:
> >  return (__x << __sN) | (__x >> ((-_sN) & (_Nd - 1)));
> > (iff _Nd is always power of two),
> 
> _Nd is 20 for one of the INT_N types on msp340, but we could have a
> special case for the rare integer types with unusual sizes.
> 
> > or perhaps
> >  return (__x << __sN) | (__x >> ((-_sN) % _Nd));
> > which is going to be folded into the above one for power of two constants?
> 
> That looks good.

Unfortunately it is not correct if _Nd is not power of two.
E.g. for __sN 1, -1U % 20 is 15, not 19.
So it would need to be 
  return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));
Unfortunately, our rotate pattern recognizer handles
  return (__x << __sN) | (__x >> ((-__sN) % _Nd));
or
  return (__x << __sN) | (__x >> ((-__sN) & (_Nd - 1)));
but doesn't handle the _Nd - __sN case.
Is this C++17+ only?  Then perhaps
  if constexpr ((_Nd & (_Nd - 1)) == 0)
return (__x << __sN) | (__x >> (-__sN & (_Nd - 1)));
  return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));

Verify that on x86_64 for all the unsigned {char,short,int,long long} you
actually get a mere rol? instruction with perhaps some register movement,
but no masking, nor shifts etc.

> > E.g. ia32intrin.h also uses:
> > /* 64bit rol */
> > extern __inline unsigned long long
> > __attribute__((__gnu_inline__, __always_inline__, __artificial__))
> > __rolq (unsigned long long __X, int __C)
> > {
> >  __C &= 63;
> >  return (__X << __C) | (__X >> (-__C & 63));
> > }
> > etc.
> 
> Should we delegate to those intrinsics for x86, so that
> __builtin_ia32_rolqi and __builtin_ia32_rolhi can be used when
> relevant?

No, the pattern recognizers should handle (for power of two bitcounts)
even the char/short cases.  Those intrinsics predate the improvements
in rotate pattern recognition.

Jakub

Re: [patch] jump threading multiple paths that start from the same BB

[Aldy Hernandez]

On 07/03/2018 08:16 PM, Jeff Law wrote:

On 07/03/2018 03:31 AM, Aldy Hernandez wrote:

On 07/02/2018 07:08 AM, Christophe Lyon wrote:


On 11/07/2017 10:33 AM, Aldy Hernandez wrote:

While poking around in the backwards threader I noticed that we bail if

we have already seen a starting BB.

 /* Do not jump-thread twice from the same block.  */
 if (bitmap_bit_p (threaded_blocks, entry->src->index)

This limitation discards paths that are sub-paths of paths that have
already been threaded.

The following patch scans the remaining to-be-threaded paths to identify

if any of them start from the same point, and are thus sub-paths of the

just-threaded path.  By removing the common prefix of blocks in upcoming

threadable paths, and then rewiring first non-common block
appropriately, we expose new threading opportunities, since we are no
longer starting from the same BB.  We also simplify the would-be
threaded paths, because we don't duplicate already duplicated paths.

[snip]

Hi,

I've noticed a regression on aarch64:
FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps
threaded: 3"
very likely caused by this patch (appeared between 262282 and 262294)

Christophe


The test needs to be adjusted here.

The long story is that the aarch64 IL is different at thread3 time in
that it has 2 profitable sub-paths that can now be threaded with my
patch.  This is causing the threaded count to be 5 for aarch64, versus 3
for x86 64.  Previously we couldn't thread these in aarch64, so the
backwards threader would bail.

One can see the different threading opportunities by sticking
debug_all_paths() at the top of thread_through_all_blocks().  You will
notice that aarch64 has far more candidates to begin with.  The IL on
the x86 backend, has no paths that start on the same BB.  The aarch64,
on the other hand, has many to choose from:

path: 52 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11,
path: 51 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16,
path: 53 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16,
path: 52 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11, 11 -> 35,
path: 51 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11, 11 -> 35,
path: 53 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11, 11 -> 35,
path: 52 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16, 16 -> 17,
path: 51 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16, 16 -> 17,
path: 53 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16, 16 -> 19,

Some of these prove unprofitable, but 2 more than before are profitable now.


BTW, I see another threading related failure on aarch64 which is
unrelated to my patch, and was previously there:

FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp2 "Jumps
threaded"

This is probably another IL incompatibility between architectures.

Anyways... the attached path fixes the regression.  I have added a note
to the test explaining the IL differences.  We really should rewrite all
the threading tests (I am NOT volunteering ;-)).

OK for trunk?
Aldy

curr.patch


gcc/testsuite/

* gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust test because aarch64
has a slightly different IL that provides more threading
opportunities.

OK.

WRT rewriting the tests.  I'd certainly agree that we don't have the
right set of knobs to allow us to characterize the target nor do we have
the right dumping/scanning facilities to describe and query the CFG changes.

The fact that the IL changes so much across targets is a sign that
target dependency (probably BRANCH_COST) is twiddling the gimple we
generate.  I strongly suspect we'd be a lot better off if we tackled the
BRANCH_COST problem first.


Huh.  I've always accepted differing IL between architectures as a 
necessary evil for things like auto-vectorization and the like.


What's the ideal plan here? A knob to set default values for target 
dependent variables that can affect IL layout?  Then we could pass 
-fthis-is-an-IL-test and things be normalized?


Thanks.
Aldy

Re: [PATCH] P0556R3 Integral power-of-2 operations, P0553R2 Bit operations

[Jonathan Wakely]

On 04/07/18 10:09 +0200, Jakub Jelinek wrote:

On Tue, Jul 03, 2018 at 11:24:00PM +0100, Jonathan Wakely wrote:

> Wouldn't it be better to use some branchless pattern that
> GCC can also optimize well, like:
>  return (__x << __sN) | (__x >> ((-_sN) & (_Nd - 1)));
> (iff _Nd is always power of two),

_Nd is 20 for one of the INT_N types on msp340, but we could have a
special case for the rare integer types with unusual sizes.

> or perhaps
>  return (__x << __sN) | (__x >> ((-_sN) % _Nd));
> which is going to be folded into the above one for power of two constants?

That looks good.


Unfortunately it is not correct if _Nd is not power of two.
E.g. for __sN 1, -1U % 20 is 15, not 19.
So it would need to be
 return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));
Unfortunately, our rotate pattern recognizer handles
 return (__x << __sN) | (__x >> ((-__sN) % _Nd));
or
 return (__x << __sN) | (__x >> ((-__sN) & (_Nd - 1)));
but doesn't handle the _Nd - __sN case.
Is this C++17+ only?  Then perhaps


The std::rotr and std::rotl functions are C++2a only, but I've added
the __rotr and __rotl versions for our own internal use in C++14 and
later.

In practice I have no internal use for rotr and rotl, so I could
remove the __rot[rl] forms. However, won't ((_Nd & (_Nd - 1)) optimize
to a constant even without if-constexpr? I'll check.


 if constexpr ((_Nd & (_Nd - 1)) == 0)
return (__x << __sN) | (__x >> (-__sN & (_Nd - 1)));
 return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));

Verify that on x86_64 for all the unsigned {char,short,int,long long} you
actually get a mere rol? instruction with perhaps some register movement,
but no masking, nor shifts etc.


Will do.


> E.g. ia32intrin.h also uses:
> /* 64bit rol */
> extern __inline unsigned long long
> __attribute__((__gnu_inline__, __always_inline__, __artificial__))
> __rolq (unsigned long long __X, int __C)
> {
>  __C &= 63;
>  return (__X << __C) | (__X >> (-__C & 63));
> }
> etc.

Should we delegate to those intrinsics for x86, so that
__builtin_ia32_rolqi and __builtin_ia32_rolhi can be used when
relevant?


No, the pattern recognizers should handle (for power of two bitcounts)
even the char/short cases.  Those intrinsics predate the improvements
in rotate pattern recognition.


OK, good to know.

Re: [PATCH] P0556R3 Integral power-of-2 operations, P0553R2 Bit operations

[Jakub Jelinek]

On Wed, Jul 04, 2018 at 09:14:04AM +0100, Jonathan Wakely wrote:
> > Unfortunately it is not correct if _Nd is not power of two.
> > E.g. for __sN 1, -1U % 20 is 15, not 19.
> > So it would need to be
> >  return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));
> > Unfortunately, our rotate pattern recognizer handles
> >  return (__x << __sN) | (__x >> ((-__sN) % _Nd));
> > or
> >  return (__x << __sN) | (__x >> ((-__sN) & (_Nd - 1)));
> > but doesn't handle the _Nd - __sN case.
> > Is this C++17+ only?  Then perhaps
> 
> The std::rotr and std::rotl functions are C++2a only, but I've added
> the __rotr and __rotl versions for our own internal use in C++14 and
> later.
> 
> In practice I have no internal use for rotr and rotl, so I could
> remove the __rot[rl] forms. However, won't ((_Nd & (_Nd - 1)) optimize
> to a constant even without if-constexpr? I'll check.

It should, sure.

Anyway, I guess my C tests didn't test properly what happens in your
functions.  We actually do optimize:
unsigned long long foo (unsigned long long __x, unsigned int __s)
{
  constexpr int _Nd = 64;
  unsigned int _sN = __s % _Nd;
  return (__x << _sN) | (__x >> ((_Nd - _sN) % _Nd));
}
properly, just don't do it if it is:
unsigned long long foo (unsigned long long __x, unsigned int __s)
{
  int _Nd = 64;
  unsigned int _sN = __s % _Nd;
  return (__x << _sN) | (__x >> ((_Nd - _sN) % _Nd));
}
Apparently, the (64 - x) & 63 optimization to -x & 63 is only done
somewhere in the FEs and not in match.pd, which is something we should fix.

But with constexpr _Nd you actually can use
  return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));
unconditionally.

Jakub

Re: [PATCH 18/n, 386]: Fix PR85694, Generation of vectorized AVG (Average) instruction

[Uros Bizjak]

On Tue, Jul 3, 2018 at 7:38 PM, Uros Bizjak  wrote:
> Hello!
>
> Attached patch implements unsigned HImode and QImode vector average
> instructions. This is all x86 has to offer...

FYI, I have tried the effectiveness of patched gcc with SPEC CPU2006
464.h264 (actually, jm19.0.zip source from [1]). Results with
CFLAGS="-Ofast -mavx2" show that:

$ objdump -d ldecod.exe | grep pavg | wc -l
6
$ objdump -d lencod.exe | grep pavg | wc -l
24

while without your patch, there were no instances of pavg found.

Quite impressive effect!

BTW: I didn't check the runtime, I'll wait for gcc SPEC tester [2] to
pick up the patch.

Uros.

[1] http://iphome.hhi.de/suehring/tml/download/
[2] https://vmakarov.fedorapeople.org/spec/index.html

Re: [patch] jump threading multiple paths that start from the same BB

[Richard Biener]

On Wed, Jul 4, 2018 at 10:12 AM Aldy Hernandez  wrote:
>
>
>
> On 07/03/2018 08:16 PM, Jeff Law wrote:
> > On 07/03/2018 03:31 AM, Aldy Hernandez wrote:
> >> On 07/02/2018 07:08 AM, Christophe Lyon wrote:
> >>
> > On 11/07/2017 10:33 AM, Aldy Hernandez wrote:
> >> While poking around in the backwards threader I noticed that we bail if
> >>
> >> we have already seen a starting BB.
> >>
> >>  /* Do not jump-thread twice from the same block.  */
> >>  if (bitmap_bit_p (threaded_blocks, entry->src->index)
> >>
> >> This limitation discards paths that are sub-paths of paths that have
> >> already been threaded.
> >>
> >> The following patch scans the remaining to-be-threaded paths to 
> >> identify
> >>
> >> if any of them start from the same point, and are thus sub-paths of the
> >>
> >> just-threaded path.  By removing the common prefix of blocks in 
> >> upcoming
> >>
> >> threadable paths, and then rewiring first non-common block
> >> appropriately, we expose new threading opportunities, since we are no
> >> longer starting from the same BB.  We also simplify the would-be
> >> threaded paths, because we don't duplicate already duplicated paths.
> >> [snip]
> >>> Hi,
> >>>
> >>> I've noticed a regression on aarch64:
> >>> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps
> >>> threaded: 3"
> >>> very likely caused by this patch (appeared between 262282 and 262294)
> >>>
> >>> Christophe
> >>
> >> The test needs to be adjusted here.
> >>
> >> The long story is that the aarch64 IL is different at thread3 time in
> >> that it has 2 profitable sub-paths that can now be threaded with my
> >> patch.  This is causing the threaded count to be 5 for aarch64, versus 3
> >> for x86 64.  Previously we couldn't thread these in aarch64, so the
> >> backwards threader would bail.
> >>
> >> One can see the different threading opportunities by sticking
> >> debug_all_paths() at the top of thread_through_all_blocks().  You will
> >> notice that aarch64 has far more candidates to begin with.  The IL on
> >> the x86 backend, has no paths that start on the same BB.  The aarch64,
> >> on the other hand, has many to choose from:
> >>
> >> path: 52 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11,
> >> path: 51 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16,
> >> path: 53 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16,
> >> path: 52 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11, 11 -> 35,
> >> path: 51 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11, 11 -> 35,
> >> path: 53 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 11, 11 -> 35,
> >> path: 52 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16, 16 -> 17,
> >> path: 51 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16, 16 -> 17,
> >> path: 53 -> 56, 56 -> 57, 57 -> 58, 58 -> 10, 10 -> 16, 16 -> 19,
> >>
> >> Some of these prove unprofitable, but 2 more than before are profitable 
> >> now.
> >>
> >>
> >> BTW, I see another threading related failure on aarch64 which is
> >> unrelated to my patch, and was previously there:
> >>
> >> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump-not vrp2 "Jumps
> >> threaded"
> >>
> >> This is probably another IL incompatibility between architectures.
> >>
> >> Anyways... the attached path fixes the regression.  I have added a note
> >> to the test explaining the IL differences.  We really should rewrite all
> >> the threading tests (I am NOT volunteering ;-)).
> >>
> >> OK for trunk?
> >> Aldy
> >>
> >> curr.patch
> >>
> >>
> >> gcc/testsuite/
> >>
> >>  * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust test because aarch64
> >>  has a slightly different IL that provides more threading
> >>  opportunities.
> > OK.
> >
> > WRT rewriting the tests.  I'd certainly agree that we don't have the
> > right set of knobs to allow us to characterize the target nor do we have
> > the right dumping/scanning facilities to describe and query the CFG changes.
> >
> > The fact that the IL changes so much across targets is a sign that
> > target dependency (probably BRANCH_COST) is twiddling the gimple we
> > generate.  I strongly suspect we'd be a lot better off if we tackled the
> > BRANCH_COST problem first.
>
> Huh.  I've always accepted differing IL between architectures as a
> necessary evil for things like auto-vectorization and the like.
>
> What's the ideal plan here? A knob to set default values for target
> dependent variables that can affect IL layout?  Then we could pass
> -fthis-is-an-IL-test and things be normalized?

Use gimple testcases.  It's currently a bit awkward in some cases
but it worked for me in a few cases.

Richard.

> Thanks.
> Aldy

Re: extract_range_from_binary* cleanups for VRP

[Richard Biener]

On Tue, Jul 3, 2018 at 7:49 PM Aldy Hernandez  wrote:
>
>
>
> On 07/03/2018 08:16 AM, Martin Liška wrote:
> > Hi.
> >
> > It caused UBSAN errors:
> >
> > $ cat ubsan.i
> > int a;
> > void d() { int c, b = 8 - a; }
> >
> > $ /home/marxin/Programming/gcc2/objdir/./gcc/xgcc 
> > -B/home/marxin/Programming/gcc2/objdir/./gcc/ ubsan.i -c -O2
> > ../../gcc/tree-vrp.c:1715:26: runtime error: load of value 255, which is 
> > not a valid value for type 'bool'
> >  #0 0x3246ca2 in extract_range_from_binary_expr_1(value_range*, 
> > tree_code, tree_node*, value_range*, value_range*) ../../gcc/tree-vrp.c:1715
> >  #1 0x34aa8b6 in 
> > vr_values::extract_range_from_binary_expr(value_range*, tree_code, 
> > tree_node*, tree_node*, tree_node*) ../../gcc/vr-values.c:794
> >  #2 0x34b45fa in vr_values::extract_range_from_assignment(value_range*, 
> > gassign*) ../../gcc/vr-values.c:1455
> >  #3 0x494cfd5 in evrp_range_analyzer::record_ranges_from_stmt(gimple*, 
> > bool) ../../gcc/gimple-ssa-evrp-analyze.c:293
> >  #4 0x4942548 in evrp_dom_walker::before_dom_children(basic_block_def*) 
> > ../../gcc/gimple-ssa-evrp.c:139
> >  #5 0x487652b in dom_walker::walk(basic_block_def*) 
> > ../../gcc/domwalk.c:353
> >  #6 0x49470f9 in execute_early_vrp ../../gcc/gimple-ssa-evrp.c:310
> >  #7 0x49470f9 in execute ../../gcc/gimple-ssa-evrp.c:347
> >  #8 0x1fc4a0e in execute_one_pass(opt_pass*) ../../gcc/passes.c:2446
> >  #9 0x1fc8b47 in execute_pass_list_1 ../../gcc/passes.c:2535
> >  #10 0x1fc8b8e in execute_pass_list_1 ../../gcc/passes.c:2536
> >  #11 0x1fc8c68 in execute_pass_list(function*, opt_pass*) 
> > ../../gcc/passes.c:2546
> >  #12 0x2004c85 in do_per_function_toporder(void (*)(function*, void*), 
> > void*) ../../gcc/passes.c:1688
> >  #13 0x2005e9a in execute_ipa_pass_list(opt_pass*) 
> > ../../gcc/passes.c:2894
> >  #14 0xfcfa79 in ipa_passes ../../gcc/cgraphunit.c:2400
> >  #15 0xfcfa79 in symbol_table::compile() ../../gcc/cgraphunit.c:2536
> >  #16 0xfdc52a in symbol_table::finalize_compilation_unit() 
> > ../../gcc/cgraphunit.c:2696
> >  #17 0x25115e4 in compile_file ../../gcc/toplev.c:479
> >  #18 0x9278af in do_compile ../../gcc/toplev.c:2086
> >  #19 0x9278af in toplev::main(int, char**) ../../gcc/toplev.c:2221
> >  #20 0x92a79a in main ../../gcc/main.c:39
> >  #21 0x7659c11a in __libc_start_main ../csu/libc-start.c:308
> >  #22 0x92a8c9 in _start 
> > (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x92a8c9)
> >
> > It's because neg_min_op0, or any other from:
> >bool neg_min_op0, neg_min_op1, neg_max_op0, neg_max_op1;
>
> I see.
>
> After this spaghetti...
>
>   if (vr0.type == VR_RANGE && vr1.type == VR_RANGE
>   && (TREE_CODE (min_op0) == INTEGER_CST
>   || (sym_min_op0
>   = get_single_symbol (min_op0, &neg_min_op0, &min_op0)))
>   && (TREE_CODE (min_op1) == INTEGER_CST
>   || (sym_min_op1
>   = get_single_symbol (min_op1, &neg_min_op1, &min_op1)))
>   && (!(sym_min_op0 && sym_min_op1)
>   || (sym_min_op0 == sym_min_op1
>   && neg_min_op0 == (minus_p ? neg_min_op1 : !neg_min_op1)))
>   && (TREE_CODE (max_op0) == INTEGER_CST
>   || (sym_max_op0
>   = get_single_symbol (max_op0, &neg_max_op0, &max_op0)))
>   && (TREE_CODE (max_op1) == INTEGER_CST
>   || (sym_max_op1
>   = get_single_symbol (max_op1, &neg_max_op1, &max_op1)))
>   && (!(sym_max_op0 && sym_max_op1)
>   || (sym_max_op0 == sym_max_op1
>   && neg_max_op0 == (minus_p ? neg_max_op1 : !neg_max_op1
>
> ...we would never actually use the neg*op* variables inside the
> adjust_symbolic_bound code.
>
> Does this patch fix the problem on your end?
>
> If so, OK for trunk?

OK.  neg_* may be unset if the == INTEGER_CST check fires in which case
they are not implicitely negated.

Thanks,
Richard.

[PATCH] PR libstdc++/86398 fix std::is_trivially_constructible regression

[Jonathan Wakely]

The intrinsic doesn't check for allowed conversions between scalar
types, so restore the std::is_constructible check.

Also make some trivial whitespace changes.

PR libstdc++/86398
* include/std/type_traits (is_trivially_constructible): Check
is_constructible before __is_trivially_constructible.
* testsuite/20_util/is_trivially_constructible/value.cc: Add more
tests, including negative cases.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Use
zero for dg-error lineno.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

I got sick of repeatedly adjusting the dg-error lines in the
make_signed/make_unsigned tests so have just changed them to match any
line.

Tested powerpc64le-linux, committed to trunk.

commit dfa577ddbb6a4161f23e61fde5ca9ca09753a4ab
Author: Jonathan Wakely 
Date:   Wed Jul 4 09:40:07 2018 +0100

PR libstdc++/86398 fix std::is_trivially_constructible regression

The intrinsic doesn't check for allowed conversions between scalar
types, so restore the std::is_constructible check.

Also make some trivial whitespace changes.

PR libstdc++/86398
* include/std/type_traits (is_trivially_constructible): Check
is_constructible before __is_trivially_constructible.
* testsuite/20_util/is_trivially_constructible/value.cc: Add more
tests, including negative cases.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Use
zero for dg-error lineno.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index accea6df648..4df82bf6d8c 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1136,7 +1136,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /// is_trivially_constructible
   template
 struct is_trivially_constructible
-: public __bool_constant<__is_trivially_constructible(_Tp, _Args...)>
+: public __and_, __bool_constant<
+ __is_trivially_constructible(_Tp, _Args...)>>::type
 { };
 
   /// is_trivially_default_constructible
@@ -1159,21 +1160,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 struct __is_implicitly_default_constructible_impl
-  : public __do_is_implicitly_default_constructible_impl
-  {
-typedef decltype(__test(declval<_Tp>())) type;
-  };
+: public __do_is_implicitly_default_constructible_impl
+{
+  typedef decltype(__test(declval<_Tp>())) type;
+};
 
   template
 struct __is_implicitly_default_constructible_safe
-  : public __is_implicitly_default_constructible_impl<_Tp>::type
-  { };
+: public __is_implicitly_default_constructible_impl<_Tp>::type
+{ };
 
   template 
 struct __is_implicitly_default_constructible
-  : public __and_,
-  __is_implicitly_default_constructible_safe<_Tp>>
-  { };
+: public __and_,
+   __is_implicitly_default_constructible_safe<_Tp>>
+{ };
 
   /// is_trivially_copy_constructible
 
diff --git a/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc 
b/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
index d2ab27df86f..f260c2a7927 100644
--- a/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
+++ b/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
@@ -44,124 +44,140 @@ void test01()
   using std::is_trivially_constructible;
   using namespace __gnu_test;
 
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(false), "PR 86398");
+  static_assert(test_property(false), "PR 86398");
+  static_assert(test_property(false), "PR 86398");
+  static_assert(test_property(false), "PR 86398");
+  static_assert(test_property(false), "PR 86398");
+  static_assert(test_property(false), "");
+  static_assert(test_property(true), "");
+  static_assert(test_property(true), "");
+  static_assert(test_property(true), "");
+  static_assert(test_property(false), "");
-  static_assert(test_property(false), "");
-  static_assert(test_property(false), "");
-  static_assert(test_property(false), "");
-  static_assert(test_property(false), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(false), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "");
-  static_assert(test_property(true), "

[PATCH] Fix _Pragma GCC diagnostic in macro expansions

[Bernd Edlinger]

Hi,

currently _Pragma("GCC diagnostic ...") does not properly
work in macro expansions.

Consider the following code:

#define B _Pragma("GCC diagnostic push") \
  _Pragma("GCC diagnostic ignored \"-Wattributes\"")
#define E _Pragma("GCC diagnostic pop")

#define X() B int __attribute((unknown_attr)) x; E /* { dg-bogus "attribute 
directive ignored" } */

void test1(void)
{
X()  /* { dg-bogus "in expansion of macro" } */
}


Warnings happen in C++ despite the _Pragma, while C happens to suppress the 
warnings
more or less by accident.

This is connected to the fact that GCC uses the location of the closing 
parenthesis of the
function-like macro expansion in the _Pragma, while the rest of the locations 
are relative
to the macro expansion point, which is the letter X in this case.

This patch changes the location of builtin macros and _Pragma to use the macro 
expansion
point instead of the closing parenthesis.

A few test cases had to be adjusted, most changes were necessary because the 
__LINE__
location moved to the macro expansion point, which looks like a straight 
improvement.

In pr61817-2.c the location of __LINE__ depends on -ftrack-macro-expansion,
when enabled the location of the macro argument is the spelling location, while 
all other
locations change to the macro expansion point.

The C++ pagma plugin.c is also affected by the change, because the 
input_location is now
the spelling location of _Pragma in DO_PRAGMA and has to be converted to the 
expansion
point of the macro to get the expected result.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.libcpp:
2018-07-04  Bernd Edlinger  

* macro.c (enter_macro_context): Change the location info for builtin
macros from location of the closing parenthesis to location of the macro
expansion point.

testsuite:
2018-07-04  Bernd Edlinger  

* c-c++-common/cpp/diagnostic-pragma-2.c: New test.
* c-c++-common/pr69558.c: Remove xfail.
* gcc.dg/cpp/builtin-macro-1.c: Adjust test expectations.
* gcc.dg/pr61817-1.c: Likewise.
* gcc.dg/pr61817-2.c: Likewise.
* g++.dg/plugin/pragma_plugin.c: Warn at expansion_point_location.
Index: gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c
===
--- gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c	(revision 0)
+++ gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c	(working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+
+#define B _Pragma("GCC diagnostic push") \
+	  _Pragma("GCC diagnostic ignored \"-Wattributes\"")
+#define E _Pragma("GCC diagnostic pop")
+
+#define X() B int __attribute((unknown_attr)) x; E /* { dg-bogus "attribute directive ignored" } */
+#define Y   B int __attribute((unknown_attr)) y; E /* { dg-bogus "attribute directive ignored" } */
+
+void test1(void)
+{
+X()  /* { dg-bogus "in expansion of macro" } */
+Y/* { dg-bogus "in expansion of macro" } */
+}
Index: gcc/testsuite/c-c++-common/pr69558.c
===
--- gcc/testsuite/c-c++-common/pr69558.c	(revision 262287)
+++ gcc/testsuite/c-c++-common/pr69558.c	(working copy)
@@ -11,9 +11,9 @@
   _Pragma ("GCC diagnostic pop")
 #define C(x) \
   A \
-  static inline void bar (void) { x (); } /* { dg-bogus "in definition of|deprecated" "" { xfail { c++ } } } */ \
+  static inline void bar (void) { x (); } /* { dg-bogus "in definition of|deprecated" "" } */ \
   B
 
-__attribute__((deprecated)) void foo (void); /* { dg-bogus "declared here" "" { xfail { c++ } } } */
+__attribute__((deprecated)) void foo (void); /* { dg-bogus "declared here" "" } */
 
 C (foo) /* { dg-bogus "is deprecated" } */
Index: gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c
===
--- gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c	(revision 262287)
+++ gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c	(working copy)
@@ -1,8 +1,8 @@
 /* Origin PR preprocessor/64803
 
This test ensures that the value the __LINE__ macro expands to is
-   constant and corresponds to the line of the closing parenthesis of
-   the top-most function-like macro expansion it's part of.
+   constant and corresponds to the line of the macro expansion point
+   the function-like macro expansion it's part of.
 
{ dg-do run }
{ do-options -no-integrated-cpp }  */
@@ -19,8 +19,8 @@
   M(a
 );
 
-  assert(L20 == 20);		/* 20 is the line number of the
-   closing parenthesis of the
+  assert(L19 == 19);		/* 19 is the line number of the
+   macro expansion point of the
    invocation of the M macro.  Please
    adjust in case the layout of this
    file changes.  */
Index: gcc/testsuite/gcc.dg/pr61817-1.c
===
--- gcc/testsuite/gcc.dg/pr61817-1.c	(revision 262287)
+++ gcc/testsuite/gcc.dg/pr61817-1.c	(working c

[PR 86371] Remove spurious $HOME include from BRIG FE Makefile

[Martin Jambor]

Hi,

a spurious include directory from $HOME slipped into a BRIG FE Makefile.
I've bootstrapped and tested the following fix, which I am going to
commit in a few moments.

Martin



2018-07-04  Martin Jambor  

PR hsa/86371
* Make-lang.in (BRIGINCLUDES): Remove erroneous include path in $HOME.

diff --git a/gcc/brig/Make-lang.in b/gcc/brig/Make-lang.in
index 151b92d..8799aa7 100644
--- a/gcc/brig/Make-lang.in
+++ b/gcc/brig/Make-lang.in
@@ -239,8 +239,7 @@ brig.stagefeedback: stagefeedback-start
 CFLAGS-brig/brig-lang.o += -DDEFAULT_TARGET_VERSION=\"$(version)\" \
-DDEFAULT_TARGET_MACHINE=\"$(target_noncanonical)\"
 
-BRIGINCLUDES = -I $(srcdir)/brig -I ${HOME}/local/include \
-   -I $(srcdir)/brig/brigfrontend
+BRIGINCLUDES = -I $(srcdir)/brig -I $(srcdir)/brig/brigfrontend
 
 brig/brig-machine.o: brig/brigfrontend/brig-machine.c
$(COMPILE) $(BRIGINCLUDES) $<

Re: [testsuite/guality, committed] Prevent optimization of local in vla-1.c

[Tom de Vries]

On 07/03/2018 11:05 AM, Tom de Vries wrote:
> On 07/02/2018 10:16 AM, Jakub Jelinek wrote:
>> On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote:
>>> Given the array has size i + 1 it's upper bound should be 'i' and 'i'
>>> should be available via DW_OP_[GNU_]entry_value.
>>>
>>> I see it is
>>>
>>> <175>   DW_AT_upper_bound : 10 byte block: 75 1 8 20 24 8 20 26 31
>>> 1c   (DW_OP_breg5 (rdi): 1; DW_OP_const1u: 32; DW_OP_shl;
>>> DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus)
>>>
>>> and %rdi is 1.  Not sure why gdb fails to print it's length.  Yes, the
>>> storage itself doesn't have a location but the
>>> type specifies the size.
>>>
>>> (gdb) ptype a
>>> type = char [variable length]
>>> (gdb) p sizeof(a)
>>> $3 = 0
>>>
>>> this looks like a gdb bug to me?
>>>
> 
> With gdb patch:
> ...
> diff --git a/gdb/findvar.c b/gdb/findvar.c
> index 8ad5e25cb2..ebaff923a1 100644
> --- a/gdb/findvar.c
> +++ b/gdb/findvar.c
> @@ -789,6 +789,8 @@ default_read_var_value
>break;
> 
>  case LOC_OPTIMIZED_OUT:
> +  if (is_dynamic_type (type))
> +   type = resolve_dynamic_type (type, NULL,
> +/* Unused address.  */ 0);
>return allocate_optimized_out_value (type);
> 
>  default:
> ...
> 
> I get:
> ...
> $ ./gdb -batch -ex "b f1" -ex "r" -ex "p sizeof (a)" vla-1.exe
> Breakpoint 1 at 0x4004a8: file vla-1.c, line 17.
> 
> Breakpoint 1, f1 (i=i@entry=5) at vla-1.c:17
> 17return a[0];
> $1 = 6
> ...
> 

Well, for -O1 and -O2.

For O3, I get instead:
...
$ ./gdb vla-1.exe -q -batch -ex "b f1" -ex "run" -ex "p sizeof (a)"
Breakpoint 1 at 0x4004b0: f1. (2 locations)

Breakpoint 1, f1 (i=5) at vla-1.c:17
17return a[0];
$1 = 0
...

At O3, f1 is cloned to a version f1.constprop with no parameters,
eliminating parameter i, but i is still accessible via
DW_OP_GNU_parameter_ref:
...
$ ./gdb vla-1.exe -q -batch -ex "b f1" -ex "run" -ex "p i" -ex "info addr i"
Breakpoint 1 at 0x4004b0: f1. (2 locations)

Breakpoint 1, f1 (i=5) at vla-1.c:17
17return a[0];
$1 = 5
Symbol "i" is a complex DWARF expression:
 0: DW_OP_GNU_parameter_ref offset 125
 5: DW_OP_stack_value
.
...

Variable a in f1 has full info available:
...
 <2><1f6>: Abbrev Number: 20 (DW_TAG_variable)
<1f7>   DW_AT_name: a
<1f9>   DW_AT_decl_file   : 1
<1fa>   DW_AT_decl_line   : 15
<1fb>   DW_AT_decl_column : 8
<1fc>   DW_AT_type: <0x201>
 <2><200>: Abbrev Number: 0
 <1><201>: Abbrev Number: 15 (DW_TAG_array_type)
<202>   DW_AT_type: <0x21b>
<206>   DW_AT_sibling : <0x21b>
 <2><20a>: Abbrev Number: 21 (DW_TAG_subrange_type)
<20b>   DW_AT_type: <0x1ce>
<20f>   DW_AT_upper_bound :
10 byte block: 75 1 8 20 24 8 20 26 31 1c
(DW_OP_breg5 (rdi): 1; DW_OP_const1u: 32; DW_OP_shl;
 DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1;
 DW_OP_minus)
 <2><21a>: Abbrev Number: 0
...

but a in f1.constprop has no DW_AT_upper_bound:
...
 <2><26e>: Abbrev Number: 26 (DW_TAG_variable)
<26f>   DW_AT_abstract_origin: <0x1f6>
<273>   DW_AT_type: <0x284>
 <2><283>: Abbrev Number: 0
 <1><284>: Abbrev Number: 15 (DW_TAG_array_type)
<285>   DW_AT_type: <0x21b>
<289>   DW_AT_sibling : <0x293>
 <2><28d>: Abbrev Number: 28 (DW_TAG_subrange_type)
<28e>   DW_AT_type: <0x1ce>
 <2><292>: Abbrev Number: 0
...

AFAIU, we could emit a DW_AT_upper_bound here as well, using
DW_OP_GNU_parameter_ref as we do for i.

Thanks,
- Tom

Fix old thinko in choose_multiplier

[Eric Botcazou]

As spotted by the reporter of the bug, there is a small thinko at the end of 
choose_multiplier whereby the (N + 1)th bit of the result is set when the 
computed value is exactly 2**N.  But it turns out that this case can never 
actually happen given how the function is invoked in the compiler.

Bootstrapped/regtested on x86-64/Linux, applied on the mainline as obvious.


2018-07-04  Eric Botcazou  

PR middle-end/86380
* expmed.c (choose_multiplier): Fix incorrect comparison with mask.

-- 
Eric BotcazouIndex: expmed.c
===
--- expmed.c	(revision 262339)
+++ expmed.c	(working copy)
@@ -3678,7 +3678,7 @@ choose_multiplier (unsigned HOST_WIDE_IN
 {
   unsigned HOST_WIDE_INT mask = (HOST_WIDE_INT_1U << n) - 1;
   *multiplier_ptr = mhigh.to_uhwi () & mask;
-  return mhigh.to_uhwi () >= mask;
+  return mhigh.to_uhwi () > mask;
 }
   else
 {

Re: [PATCH] relax lower bound for infinite arguments in gimple-ssa-sprinf.c (PR 86274)

[Christophe Lyon]

Hi,

On Wed, 4 Jul 2018 at 09:26, Richard Biener  wrote:
>
> On Tue, 3 Jul 2018, Martin Sebor wrote:
>
> > Committed to trunk in r86274.  Jakub/Richard, can you please
> > also review and approve the corresponding fix for the release
> > branches?
>
> If it is a regression and the patch was approved for trunk it is
> automatically OK for release branches without further review unless
> you think it is too invasive.
>
> Richard.
>
> > Martin
> >
> > On 07/03/2018 06:32 PM, Jeff Law wrote:
> > > On 07/03/2018 04:50 PM, Martin Sebor wrote:
> > > > In computing the size of expected output for non-constant floating
> > > > arguments the sprintf pass doesn't consider the possibility that
> > > > the argument value may be not finite (i.e., it can be infinity or
> > > > NaN).  Infinities and NaNs are formatted as "inf" or "infinity"
> > > > and "nan".  As a result, any floating directive can produce as
> > > > few bytes on output as three for an non-finite argument, when
> > > > the least amount directives such as %f produce for finite
> > > > arguments is 8.
> > > >
> > > > The attached patch adjusts the floating point code to correctly
> > > > reflect the lower bound.
> > > >
> > > > Martin
> > > >
> > > > gcc-86274.diff
> > > >
> > > >
> > > > PR tree-optimization/86274 - SEGFAULT when logging std::to_string(NAN)
> > > >
> > > > gcc/ChangeLog:
> > > >
> > > >   PR tree-optimization/86274
> > > >   * gimple-ssa-sprintf.c (fmtresult::type_max_digits): Verify
> > > >   precondition.
> > > >   (format_floating): Correct handling of infinities and NaNs.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > >   PR tree-optimization/86274
> > > >   * gcc.dg/tree-ssa/builtin-sprintf-9.c: New test.

I've noticed a failure with this new test (on arm and aarch64, but
I've seen other targets are affected on gcc-testresults):
gcc.dg/tree-ssa/builtin-sprintf-9.c: dump file does not exist
UNRESOLVED: gcc.dg/tree-ssa/builtin-sprintf-9.c scan-tree-dump-times
optimized" "call_made_in_true_branch_" 6"

The test is compiled with -fdump-tree-optimized

Christophe

> > > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust.
> > > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: Same.
> > > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Same.
> > > >   * gcc.dg/tree-ssa/builtin-sprintf-warn-7.c: Same.
> > > >   * gcc.dg/tree-ssa/builtin-sprintf.c: Same.
> > > >   * gcc.dg/tree-ssa/pr83198.c: Same.
> > > OK
> > > jeff
> > >
> >
> >
>
> --
> Richard Biener 
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nuernberg)

Re: [PATCH] P0556R3 Integral power-of-2 operations, P0553R2 Bit operations

[Jonathan Wakely]

On 04/07/18 10:26 +0200, Jakub Jelinek wrote:

On Wed, Jul 04, 2018 at 09:14:04AM +0100, Jonathan Wakely wrote:

> Unfortunately it is not correct if _Nd is not power of two.
> E.g. for __sN 1, -1U % 20 is 15, not 19.
> So it would need to be
>  return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));
> Unfortunately, our rotate pattern recognizer handles
>  return (__x << __sN) | (__x >> ((-__sN) % _Nd));
> or
>  return (__x << __sN) | (__x >> ((-__sN) & (_Nd - 1)));
> but doesn't handle the _Nd - __sN case.
> Is this C++17+ only?  Then perhaps

The std::rotr and std::rotl functions are C++2a only, but I've added
the __rotr and __rotl versions for our own internal use in C++14 and
later.

In practice I have no internal use for rotr and rotl, so I could
remove the __rot[rl] forms. However, won't ((_Nd & (_Nd - 1)) optimize
to a constant even without if-constexpr? I'll check.


It should, sure.

Anyway, I guess my C tests didn't test properly what happens in your
functions.  We actually do optimize:
unsigned long long foo (unsigned long long __x, unsigned int __s)
{
 constexpr int _Nd = 64;
 unsigned int _sN = __s % _Nd;
 return (__x << _sN) | (__x >> ((_Nd - _sN) % _Nd));
}
properly, just don't do it if it is:
unsigned long long foo (unsigned long long __x, unsigned int __s)
{
 int _Nd = 64;
 unsigned int _sN = __s % _Nd;
 return (__x << _sN) | (__x >> ((_Nd - _sN) % _Nd));
}
Apparently, the (64 - x) & 63 optimization to -x & 63 is only done
somewhere in the FEs and not in match.pd, which is something we should fix.

But with constexpr _Nd you actually can use
 return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));
unconditionally.


OK here's what I've just tested and committed to trunk.


commit 35640efe0911095ad6ce38771e40a22a6cbb1221
Author: Jonathan Wakely 
Date:   Wed Jul 4 14:37:57 2018 +0100

Fix std::__rotl and std::__rotr

2018-07-04  Jonathan Wakely  
Jakub Jelinek  

* include/std/bit (__rotl, __rotr): Fix for non-power of two sizes.

diff --git a/libstdc++-v3/include/std/bit b/libstdc++-v3/include/std/bit
index ace88954030..a23f2ba60d1 100644
--- a/libstdc++-v3/include/std/bit
+++ b/libstdc++-v3/include/std/bit
@@ -46,7 +46,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   constexpr auto _Nd = numeric_limits<_Tp>::digits;
   const unsigned __sN = __s % _Nd;
-  return (__x << __sN) | (__x >> ((-__sN) % _Nd));
+  return (__x << __sN) | (__x >> ((_Nd - __sN) % _Nd));
 }
 
   template
@@ -55,7 +55,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   constexpr auto _Nd = numeric_limits<_Tp>::digits;
   const unsigned __sN = __s % _Nd;
-  return (__x >> __sN) | (__x << ((-__sN) % _Nd));
+  return (__x >> __sN) | (__x << ((_Nd - __sN) % _Nd));
 }
 
   template

[C++ PATCH] PR c++/86398

[Ville Voutilainen]

This has been buggy for a while, but since we were implementing
the library triviality traits in terms of just the intrinsic since GCC 8,
not too many users ran into it. The bug has been worked around
in the library, but I'd rather have the intrinsic give the right
answer and not require the library work-around.

Tested on Linux-PPC64, ok for trunk and the gcc-8 branch?

2018-07-04  Ville Voutilainen  

gcc/cp/

PR c++/86398
* method.c (is_trivially_xible): Return false
if is_xible_helper returns a NULL_TREE.

testsuite/

PR c++/86398
* g++.dg/ext/is_trivially_constructible1.C: Add new tests.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 858655b..0b208a8 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1216,7 +1216,7 @@ is_trivially_xible (enum tree_code code, tree to, tree from)
   tree expr;
   expr = is_xible_helper (code, to, from, /*trivial*/true);
 
-  if (expr == error_mark_node)
+  if (expr == NULL_TREE || expr == error_mark_node)
 return false;
   tree nt = cp_walk_tree_without_duplicates (&expr, check_nontriv, NULL);
   return !nt;
diff --git a/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C b/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
index 175eae9..191b696 100644
--- a/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
+++ b/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
@@ -39,6 +39,11 @@ SA(!__is_trivially_constructible(void,int));
 SA(!__is_trivially_constructible(const void,int));
 SA(!__is_trivially_constructible(volatile void,int));
 SA(!__is_trivially_constructible(const volatile void,int));
+SA(!__is_trivially_constructible(int, void*));
+SA(!__is_trivially_constructible(int, int*));
+SA(!__is_trivially_constructible(int, const int*));
+SA(!__is_trivially_constructible(int*, void*));
+SA(!__is_trivially_constructible(int*, const int*));
 
 SA(!__is_trivially_constructible(D));
 

Re: [PATCH] Add experimental::sample and experimental::shuffle from N4531

[Jonathan Wakely]

On 29/06/18 10:45 +0100, Jonathan Wakely wrote:

On 29/06/18 09:39 +0200, Christophe Lyon wrote:

On Fri, 29 Jun 2018 at 09:21, Jonathan Wakely  wrote:


On 29/06/18 08:55 +0200, Christophe Lyon wrote:

On Mon, 25 Jun 2018 at 18:23, Jonathan Wakely  wrote:


The additions to  were added in 2015 but the new
algorithms in  were not. This adds them.

* include/experimental/algorithm (sample, shuffle): Add new overloads
using per-thread random number engine.
* testsuite/experimental/algorithm/sample.cc: Simpify and reduce
dependencies by using __gnu_test::test_container.
* testsuite/experimental/algorithm/sample-2.cc: New.
* testsuite/experimental/algorithm/shuffle.cc: New.

Tested x86_64-linux, committed to trunk.

This would be safe to backport, but nobody has noticed the algos are
missing or complained, so it doesn't seem very important to backport.




Hi,

On bare-metal targets (aarch64 and arm + newlib), I've noticed that
the two new tests fail:
PASS: experimental/algorithm/shuffle.cc (test for excess errors)
spawn 
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/utils/bin/qemu-wrapper.sh
./shuffle.exe
terminate called after throwing an instance of 'std::runtime_error'
 what():  random_device::random_device(const std::string&)

*** EXIT code 4242
FAIL: experimental/algorithm/shuffle.cc execution test

PASS: experimental/algorithm/sample-2.cc (test for excess errors)
spawn 
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/utils/bin/qemu-wrapper.sh
./sample-2.exe
terminate called after throwing an instance of 'std::runtime_error'
 what():  random_device::random_device(const std::string&)

*** EXIT code 4242
FAIL: experimental/algorithm/sample-2.cc execution test

Does this ring a bell?


Does the existing testsuite/experimental/random/randint.cc file fail
in the same way?



Yes it does.

And so do:
25_algorithms/make_heap/complexity.cc


This one also uses std::random_device.


23_containers/array/element_access/at_neg.cc


Hmm,

// Expected behavior is to either throw and have the uncaught
// exception end up in a terminate handler which eventually exits,
// or abort. (Depending on -fno-exceptions.)

So this is expected to XFAIL.


26_numerics/random/random_device/cons/default.cc


We should XFAIL the ones that use std::random_device, if we can
identify an effective target to describe them.


This adds a new "random_device" effective-target, so the tests are
disabled when the random_device isn't usable.

Tested powerpc64le-linux, committed to trunk. If this works for
Christophe's bare metal targets I'll backport it to gcc-8-branch too.


commit b32bcdc1dc7ff6d483a4a7223d78198b7522cbe4
Author: Jonathan Wakely 
Date:   Wed Jul 4 15:44:45 2018 +0100

Define "random_device" effective target

Currently only matches targets where _GLIBCXX_USE_RANDOM_TR1 is defined,
which means /dev/random and /dev/urandom are usable.

* testsuite/25_algorithms/make_heap/complexity.cc: Require effective
target for std::random_device.
* testsuite/26_numerics/random/random_device/cons/default.cc:
Likewise.
* testsuite/experimental/algorithm/sample-2.cc: Likewise.
* testsuite/experimental/algorithm/shuffle.cc: Likewise.
* testsuite/experimental/random/randint.cc: Likewise.
* testsuite/lib/libstdc++.exp
(check_effective_target_random_device): New proc.

diff --git a/libstdc++-v3/testsuite/25_algorithms/make_heap/complexity.cc b/libstdc++-v3/testsuite/25_algorithms/make_heap/complexity.cc
index cca48f61e0a..069d2d0433d 100644
--- a/libstdc++-v3/testsuite/25_algorithms/make_heap/complexity.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/make_heap/complexity.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do run { target c++11 } }
+// { dg-require-effective-target random_device }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/default.cc b/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/default.cc
index 38210963f7e..5a34526a5f7 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/default.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/random_device/cons/default.cc
@@ -1,4 +1,5 @@
 // { dg-do run { target c++11 } }
+// { dg-require-effective-target random_device }
 // { dg-require-cstdint "" }
 //
 // 2008-11-24  Edward M. Smith-Rowland <3dw...@verizon.net>
diff --git a/libstdc++-v3/testsuite/experimental/algorithm/sample-2.cc b/libstdc++-v3/testsuite/experimental/algorithm/sample-2.cc
index 541d17e08a0..ef3f7daa14c 100644
--- a/libstdc++-v3/testsuite/experimental/algorithm/sample-2.cc
+++ b/libstdc++-v3/testsuite/experimental/algorithm/sample-2.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do run { target c++14 } }
+// { dg-require-effective-target random_device }
 // { dg-require-effective-target tls_runtime }
 // { 

Re: [PATCH][PR sanitizer/84250] Avoid global symbols collision when using both ASan and UBSan

[Maxim Ostapenko]

Hi Jeff,

On 07/04/2018 05:45 AM, Jeff Law wrote:
> On 05/23/2018 11:15 AM, Maxim Ostapenko wrote:
>> Hi,
>>
>>
>> as described in PR, when using both ASan and UBSan
>> (-fsanitize=address,undefined ), we have symbols collision for global
>> functions, like __sanitizer_set_report_path. This leads to fuzzy results
>> when printing reports into files e.g. for this test case:
>>
>> #include 
>> int main(int argc, char **argv) {
>>     __sanitizer_set_report_path("/tmp/sanitizer.txt");
>>     int i = 23;
>>     i <<= 32;
>>     int *array = new int[100];
>>     delete [] array;
>>     return array[argc];
>> }
>>
>> only ASan's report gets written to file; UBSan output goes to stderr.
>>
>> To resolve this issue we could use two approaches:
>>
>> 1) Use the same approach to that is implemented in Clang (UBSan embedded
>> to ASan). The only caveat here is that we need to link (unused) C++ part
>> of UBSan even in C programs when linking static ASan runtime. This
>> happens because GCC, as opposed to Clang, doesn't split C and C++
>> runtimes for sanitizers.
>>
>> 2) Just add SANITIZER_INTERFACE_ATTRIBUTE to report_file global
>> variable. In this case all __sanitizer_set_report_path calls will set
>> the same report_file variable. IMHO this is a hacky way to fix the
>> issue, it's better to use the first option if possible.
>>
>>
>> The attached patch fixes the symbols collision by embedding UBSan into
>> ASan (variant 1), just like we do for LSan.
>>
>>
>> Regtested/bootstrapped on x86_64-unknown-linux-gnu, looks reasonable
>> enough for trunk?
>>
>>
>> -Maxim
>>
>>
>> pr84250-2.diff
>>
>>
>> gcc/ChangeLog:
>>
>> 2018-05-23  Maxim Ostapenko  
>>
>>  * config/gnu-user.h (LIBASAN_EARLY_SPEC): Pass -lstdc++ for static
>>  libasan.
>>  * gcc.c: Do not pass LIBUBSAN_SPEC if ASan is enabled with UBSan.
>>
>> libsanitizer/ChangeLog:
>>
>> 2018-05-23  Maxim Ostapenko  
>>
>>  * Makefile.am: Reorder libs.
>>  * Makefile.in: Regenerate.
>>  * asan/Makefile.am: Define DCAN_SANITIZE_UB=1, add dependancy from
>>  libsanitizer_ubsan.la.
>>  * asan/Makefile.in: Regenerate.
>>  * ubsan/Makefile.am: Define new libsanitizer_ubsan.la library.
>>  * ubsan/Makefile.in: Regenerate.
> You know this code better than anyone else working on GCC.  My only
> concern would be the kernel builds with asan, but I suspect they're
> providing their own runtime anyway, so the libstdc++ caveat shouldn't apply.

Yes, you are right, kernel provides its own runtime.

>
> OK for the trunk.

Ok, thanks, I'll apply the patch today (with fixed ChangeLog entry).

-Maxim

> jeff
>
>
>

Re: [RFC PATCH] diagnose built-in declarations without prototype (PR 83656)

[Martin Sebor]

On 07/03/2018 08:33 PM, Jeff Law wrote:

On 06/29/2018 09:54 AM, Martin Sebor wrote:


All the warnings I have seen are because of declarations like
the one in the test below that checks for the presence of symbol
sin in the library:

  char sin ();
  int main () { return sin (); }

GCC has warned for this code by default since at least 4.1 so if
it is, in fact, a problem it has been with us for over a decade.

There's a comment in the test that explains that the char return
type is deliberate to prevent GCC from treating the function as
a built-in.  (That, of course, relies on undefined behavior
because names of extern library functions are reserved and
conforming compilers could simply avoid emitting the call or
replace it with a trap.)

As you noted, by doing this the test can verify if there's a sin()
function in the library or not, regardless of whether or not the
compiler has a builtin for sin().

I wonder if stepping forward to a more modern version of autoconf is
going to help here and if we should be feeding them updates to make this
kind of stuff less pervasive, at least in standard autoconf tests.


That would make sense to me.  The tests should not rely on
undefined behavior.  They should declare standard functions with
the right prototypes.  IMO, for GCC and compatible compilers they
should disable built-in expansion instead via -fno-builtin.  For
all other compilers, they could store the address of each function
in a (perhaps volatile) pointer and use it to make the call instead.

I think the problem is they can't rely on the compiler having the
-fno-builtin flag.  Of course they're relying on other compilers having
the same kind of behavior as GCC WRT which is possibly worse.

I guess there's a reason why they didn't extract the set of symbols from
the library. :-)



But since the number of warnings here hasn't changed, the ones
in GCC logs predate my changes.  So updating the tests seems
like an improvement to consider independently of the patch.

Agreed.  I'm still wary of proceeding given the general concerns about
configure tests.  It's good that GCC's configury bits aren't affected,
but I'm not sure we can generalize a whole lot from that.


So what's the next step?  I'm open to relaxing the warning
so it only triggers with -Wall or -Wextra and not by default
if that's considered necessary.

At the same time, the instances of the warning we have seen
have all been issued for the configure tests for years and
we have not seen any new instances of it as a result of
this change, so the concern that the patch might lead to some
more while at the same time accepting the ones we know about
doesn't make sense to me.

Any new warning that's enabled by default has the potential
to trigger for invalid configure tests or any other such code.
I would expect tests deliberately written to rely on undefined
behavior to be prepared for compiler warnings, so I'm not sure
I understand the basis for the concern in this case.  I also
don't recall the concern being raised for newly added warnings
in the past that were enabled by default and I'm not sure I see
what makes this one different.

Martin

[patch, committed, fortran] PR82009 [F08] ICE with block construct

[Jerry DeLisle]

This patch committed as obvious after regression testing and auditing 
the code.  New test case added.


Author: jvdelisle
Date: Wed Jul  4 18:08:16 2018
New Revision: 262416

URL: https://gcc.gnu.org/viewcvs?rev=262416&root=gcc&view=rev
Log:
2018-07-04  Jerry DeLisle  

PR fortran/82009
* trans-decl.c (gfc_process_block_locals): Delete assert and set
saved_local_decls = NULL_TREE.

* gfortran.dg/block_16.f08. New test.

Added:
trunk/gcc/testsuite/gfortran.dg/block_16.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog



diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 254768c5828..08c1ebd2d4b 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -6751,7 +6751,7 @@ gfc_process_block_locals (gfc_namespace* ns)
 {
   tree decl;

-  gcc_assert (saved_local_decls == NULL_TREE);
+  saved_local_decls = NULL_TREE;
   has_coarray_vars = false;

   generate_local_vars (ns);

[PATCH] P0458R2 Checking for Existence of an Element in Associative Containers

[Jonathan Wakely]

* include/bits/stl_map.h (map::contains): Add for C++2a.
* include/bits/stl_multimap.h (multimap::contains): Likewise.
* include/bits/stl_multiset.h (multiset::contains): Likewise.
* include/bits/stl_set.h (set::contains): Likewise.
* include/bits/stl_tree.h (__has_is_transparent_t): Define alias.
(_Rb_tree::_M_find_tr, _Rb_tree::_M_count_tr)
(_Rb_tree::_M_lower_bound_tr, _Rb_tree::_M_upper_bound_tr)
(_Rb_tree::_M_equal_range_tr): Use __has_is_transparent_t.
* include/bits/unordered_map.h (unordered_map::contains)
(unordered_multimap::contains): Add for C++2a.
* include/bits/unordered_set.h (unordered_set::contains)
(unordered_multiset::contains): Likewise.
* testsuite/23_containers/map/operations/contains.cc: New.
* testsuite/23_containers/multimap/operations/contains.cc: New.
* testsuite/23_containers/multiset/operations/contains.cc: New.
* testsuite/23_containers/set/operations/contains.cc: New.
* testsuite/23_containers/unordered_map/operations/contains.cc: New.
* testsuite/23_containers/unordered_multimap/operations/contains.cc:
New.
* testsuite/23_containers/unordered_multiset/operations/contains.cc:
New.
* testsuite/23_containers/unordered_set/operations/contains.cc: New.

Tested powerpc64le-linux, committed to trunk.


commit c38607c44696e07f44f56abf339f5453b04a5e70
Author: Jonathan Wakely 
Date:   Wed Jul 4 19:15:11 2018 +0100

P0458R2 Checking for Existence of an Element in Associative Containers

* include/bits/stl_map.h (map::contains): Add for C++2a.
* include/bits/stl_multimap.h (multimap::contains): Likewise.
* include/bits/stl_multiset.h (multiset::contains): Likewise.
* include/bits/stl_set.h (set::contains): Likewise.
* include/bits/stl_tree.h (__has_is_transparent_t): Define alias.
(_Rb_tree::_M_find_tr, _Rb_tree::_M_count_tr)
(_Rb_tree::_M_lower_bound_tr, _Rb_tree::_M_upper_bound_tr)
(_Rb_tree::_M_equal_range_tr): Use __has_is_transparent_t.
* include/bits/unordered_map.h (unordered_map::contains)
(unordered_multimap::contains): Add for C++2a.
* include/bits/unordered_set.h (unordered_set::contains)
(unordered_multiset::contains): Likewise.
* testsuite/23_containers/map/operations/contains.cc: New.
* testsuite/23_containers/multimap/operations/contains.cc: New.
* testsuite/23_containers/multiset/operations/contains.cc: New.
* testsuite/23_containers/set/operations/contains.cc: New.
* testsuite/23_containers/unordered_map/operations/contains.cc: New.
* testsuite/23_containers/unordered_multimap/operations/contains.cc:
New.
* testsuite/23_containers/unordered_multiset/operations/contains.cc:
New.
* testsuite/23_containers/unordered_set/operations/contains.cc: New.

diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index b81a2c4b7fc..fdd058b060d 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -1223,6 +1223,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 #endif
   //@}
 
+#if __cplusplus > 201703L
+  //@{
+  /**
+   *  @brief  Finds whether an element with the given key exists.
+   *  @param  __x  Key of (key, value) pairs to be located.
+   *  @return  True if there is an element with the specified key.
+   */
+  bool
+  contains(const key_type& __x) const
+  { return _M_t.find(__x) != _M_t.end(); }
+
+  template
+	auto
+	contains(const _Kt& __x) const
+	-> decltype(_M_t._M_find_tr(__x), void(), true)
+	{ return _M_t._M_find_tr(__x) != _M_t.end(); }
+  //@}
+#endif
+
   //@{
   /**
*  @brief Finds the beginning of a subsequence matching given key.
diff --git a/libstdc++-v3/include/bits/stl_multimap.h b/libstdc++-v3/include/bits/stl_multimap.h
index 23332ee53f8..9357d1db6aa 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ b/libstdc++-v3/include/bits/stl_multimap.h
@@ -893,6 +893,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 #endif
   //@}
 
+#if __cplusplus > 201703L
+  //@{
+  /**
+   *  @brief  Finds whether an element with the given key exists.
+   *  @param  __x  Key of (key, value) pairs to be located.
+   *  @return  True if there is any element with the specified key.
+   */
+  bool
+  contains(const key_type& __x) const
+  { return _M_t.find(__x) != _M_t.end(); }
+
+  template
+	auto
+	contains(const _Kt& __x) const
+	-> decltype(_M_t._M_find_tr(__x), void(), true)
+	{ return _M_t._M_find_tr(__x) != _M_t.end(); }
+  //@}
+#endif
+
   //@{
   /**
*  @brief Finds the beginning of a subsequence matching given key.
diff --git a/libstdc++-v3

Re: [patch, committed, fortran] PR82009 [F08] ICE with block construct

[Paul Richard Thomas]

Thanks, Jerry.
On Wed, 4 Jul 2018 at 19:14, Jerry DeLisle  wrote:
>
> This patch committed as obvious after regression testing and auditing
> the code.  New test case added.
>
> Author: jvdelisle
> Date: Wed Jul  4 18:08:16 2018
> New Revision: 262416
>
> URL: https://gcc.gnu.org/viewcvs?rev=262416&root=gcc&view=rev
> Log:
> 2018-07-04  Jerry DeLisle  
>
> PR fortran/82009
> * trans-decl.c (gfc_process_block_locals): Delete assert and set
> saved_local_decls = NULL_TREE.
>
> * gfortran.dg/block_16.f08. New test.
>
> Added:
>  trunk/gcc/testsuite/gfortran.dg/block_16.f08
> Modified:
>  trunk/gcc/fortran/ChangeLog
>  trunk/gcc/fortran/trans-decl.c
>  trunk/gcc/testsuite/ChangeLog
>
>
>
> diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
> index 254768c5828..08c1ebd2d4b 100644
> --- a/gcc/fortran/trans-decl.c
> +++ b/gcc/fortran/trans-decl.c
> @@ -6751,7 +6751,7 @@ gfc_process_block_locals (gfc_namespace* ns)
>   {
> tree decl;
>
> -  gcc_assert (saved_local_decls == NULL_TREE);
> +  saved_local_decls = NULL_TREE;
> has_coarray_vars = false;
>
> generate_local_vars (ns);



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

Re: [C++ PATCH] PR c++/86398

[Jason Merrill]

Ok.

On Wed, Jul 4, 2018, 11:52 AM Ville Voutilainen 
wrote:

> This has been buggy for a while, but since we were implementing
> the library triviality traits in terms of just the intrinsic since GCC 8,
> not too many users ran into it. The bug has been worked around
> in the library, but I'd rather have the intrinsic give the right
> answer and not require the library work-around.
>
> Tested on Linux-PPC64, ok for trunk and the gcc-8 branch?
>
> 2018-07-04  Ville Voutilainen  
>
> gcc/cp/
>
> PR c++/86398
> * method.c (is_trivially_xible): Return false
> if is_xible_helper returns a NULL_TREE.
>
> testsuite/
>
> PR c++/86398
> * g++.dg/ext/is_trivially_constructible1.C: Add new tests.
>

Re: Extend tree code folds to IFN_COND_*

[Richard Sandiford]

Finally getting back to this...

Richard Biener  writes:
> On Wed, Jun 6, 2018 at 10:16 PM Richard Sandiford
>  wrote:
>>
>> > On Thu, May 24, 2018 at 11:36 AM Richard Sandiford
>> >  wrote:
>> >>
>> >> This patch adds match.pd support for applying normal folds to their
>> >> IFN_COND_* forms.  E.g. the rule:
>> >>
>> >>   (plus @0 (negate @1)) -> (minus @0 @1)
>> >>
>> >> also allows the fold:
>> >>
>> >>   (IFN_COND_ADD @0 @1 (negate @2) @3) -> (IFN_COND_SUB @0 @1 @2 @3)
>> >>
>> >> Actually doing this by direct matches in gimple-match.c would
>> >> probably lead to combinatorial explosion, so instead, the patch
>> >> makes gimple_match_op carry a condition under which the operation
>> >> happens ("cond"), and the value to use when the condition is false
>> >> ("else_value").  Thus in the example above we'd do the following
>> >>
>> >> (a) convert:
>> >>
>> >>   cond:NULL_TREE (IFN_COND_ADD @0 @1 @4 @3) else_value:NULL_TREE
>> >>
>> >> to:
>> >>
>> >>   cond:@0 (plus @1 @4) else_value:@3
>> >>
>> >> (b) apply gimple_resimplify to (plus @1 @4)
>> >>
>> >> (c) reintroduce cond and else_value when constructing the result.
>> >>
>> >> Nested operations inherit the condition of the outer operation
>> >> (so that we don't introduce extra faults) but have a null else_value.
>> >> If we try to build such an operation, the target gets to choose what
>> >> else_value it can handle efficiently: obvious choices include one of
>> >> the operands or a zero constant.  (The alternative would be to have some
>> >> representation for an undefined value, but that seems a bit invasive,
>> >> and isn't likely to be useful here.)
>> >>
>> >> I've made the condition a mandatory part of the gimple_match_op
>> >> constructor so that it doesn't accidentally get dropped.
>> >>
>> >> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
>> >> and x86_64-linux-gnu.  OK to install?
>> >
>> > It looks somewhat clever but after looking for a while it doesn't handle
>> > simplifying
>> >
>> >  (IFN_COND_ADD @0 @1 (IFN_COND_SUB @0 @2 @1 @3) @3)
>> >
>> > to
>> >
>> >  (cond @0 @2 @3)
>> >
>> > right?  Because while the conditional gimple_match_op is built
>> > by try_conditional_simplification it isn't built when doing
>> > SSA use->def following in the generated matching code?
>>
>> Right.  This would be easy to add, but there's no motivating case yet.
>
> ...
>
>> > So it looks like a bit much noise for this very special case?
>> >
>> > I suppose you ran into the need of these foldings from looking
>> > at real code - which foldings specifically were appearing here?
>> > Usually code is well optimized before if-conversion/vectorization
>> > so we shouldn't need full-blown handling?
>>
>> It's needed to get the FMA, FMS, FNMA and FNMS folds for IFN_COND_* too.
>> I thought it'd be better to do it "automatically" rather than add specific
>> folds, since if we don't do it automatically now, it's going to end up
>> being a precedent for not doing it automatically in future either.
>
> ... not like above isn't a similar precedent ;)  But OK, given...

But we're not doing the above case manually either yet :-)  Whereas the
series does need to do what the patch does one way or another.

Also, it might be hard to do the above case manually anyway (i.e. match
nested IFN_COND_* ops with an implicitly-conditional top-level op),
since the match.pd rule wouldn't have easy access to the overall condition.
And that's by design, or so I'd like to claim.

>> > That said, I'm not sure how much work it is to massage
>> >
>> >   if (gimple *def_stmt = get_def (valueize, op2))
>> > {
>> >   if (gassign *def = dyn_cast  (def_stmt))
>> > switch (gimple_assign_rhs_code (def))
>> >   {
>> >   case PLUS_EXPR:
>> >
>> > to look like
>> >
>> >   if (gimple *def_stmt = get_def (valueize, op2))
>> > {
>> >code = ERROR_MARK;
>> >if (!is_cond_ifn_with_cond (curr_gimple_match_op, &code))
>> >  if (gassign *def dyn_cast  (def_stmt))
>> >code = gimple_assign_rhs_code (def);
>> >switch (code)
>> >  {
>> >  case PLUS_EXPR:
>> >
>> > thus transparently treat the IFN_COND_* as their "code" if the condition
>> > matches that of the context (I'm not sure if we can do anything for
>> > mismatching contexts).
>>
>> Yeah, this was one approach I had in mind for the subnodes, if we do
>> end up needing it.  But at least for the top-level node, we want to try
>> both as a native IFN_COND_FOO and as a conditional FOO, which is why the
>> top-level case is handled directly in gimple-match-head.c.
>>
>> Of course, trying both for subnodes would lead to exponential behaviour
>> in general.  And like you say, in practice most double-IFN_COND cases
>> should have been folded before we created the IFN_CONDs, so it's hard
>> to tell which recursive behaviour would be best.
>
> ... this it probably makes sense t

Re: [PATCH] relax lower bound for infinite arguments in gimple-ssa-sprinf.c (PR 86274)

[Martin Sebor]

On 07/04/2018 08:04 AM, Christophe Lyon wrote:

Hi,

On Wed, 4 Jul 2018 at 09:26, Richard Biener  wrote:


On Tue, 3 Jul 2018, Martin Sebor wrote:


Committed to trunk in r86274.  Jakub/Richard, can you please
also review and approve the corresponding fix for the release
branches?


If it is a regression and the patch was approved for trunk it is
automatically OK for release branches without further review unless
you think it is too invasive.


Will do.  Thanks for clarifying.




I've noticed a failure with this new test (on arm and aarch64, but
I've seen other targets are affected on gcc-testresults):
gcc.dg/tree-ssa/builtin-sprintf-9.c: dump file does not exist
UNRESOLVED: gcc.dg/tree-ssa/builtin-sprintf-9.c scan-tree-dump-times
optimized" "call_made_in_true_branch_" 6"

The test is compiled with -fdump-tree-optimized


Thanks.  There was a typo in the dg-final directive in the test
and I missed the UNRESOLVED result among all the others that
have recently started showing up.  I fixed the typo in r262419
and raised bug 86405 for the unresolved tests.

Martin

Re: [RFC, testsuite/guality] Use relative line numbers in gdb-test

[Richard Sandiford]

Tom de Vries  writes:
> [ was: [PATCH, testsuite/guality] Use line number vars in gdb-test ]
> On Thu, Jun 28, 2018 at 07:49:30PM +0200, Tom de Vries wrote:
>> Hi,
>> 
>> I played around with pr45882.c and ran into FAILs.  It took me a while to
>> realize that the FAILs where due to the gdb-test (a dg-final action) using
>> absolute line numbers, and me adding lines before the gdb-test lines.
>> 
>> I've written this patch, which factors out the handling of relative line
>> numbers as well as line number variables from process-message, and reuses the
>> functionality in gdb-test.
>> 
>> This enables the line number variables functionality in gdb-test.  [ There's
>> one quirk: line number variables have a define-before-use semantics (with
>> matching used-before-defined error) but in the test-case the use in gdb-test
>> preceeds the definition in gdb-line.  This doesn't cause errors, because
>> the dg-final actions are executed after the definition has taken effect. ]
>> 
>> [ Relative line numbers still don't work in gdb-test, but that's due to an
>> orthogonal issue: gdb-test is a dg-final action, and while dg-final receives
>> the line number on which it occurred as it's first argument, it doesn't pass
>> on this line number to the argument list of the action. I'll submit a
>> follow-on rfc patch for this. ]
>>
>
> This patch adds a dg-final override that passes it's first argument to the
> gdb-test action.  This allows us to use relative line numbers in gdb-test.
>
> Tested pr45882.c.
>
> Any comments?
>  
> Thanks,
> - Tom
>
> [testsuite/guality] Use relative line numbers in gdb-test
>
> 2018-06-28  Tom de Vries  
>
>   * gcc.dg/guality/pr45882.c (foo): Use relative line numbers.
>   * lib/gcc-dg.exp (dg-final): New proc.
>   * lib/gcc-gdb-test.exp (gdb-test): Add and handle additional line number
>   argument.
>
> ---
>  gcc/testsuite/gcc.dg/guality/pr45882.c | 10 +-
>  gcc/testsuite/lib/gcc-dg.exp   | 20 
>  gcc/testsuite/lib/gcc-gdb-test.exp |  4 ++--
>  3 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/guality/pr45882.c 
> b/gcc/testsuite/gcc.dg/guality/pr45882.c
> index da9e2755590..02d74389ea0 100644
> --- a/gcc/testsuite/gcc.dg/guality/pr45882.c
> +++ b/gcc/testsuite/gcc.dg/guality/pr45882.c
> @@ -9,11 +9,11 @@ volatile short int v;
>  __attribute__((noinline,noclone,used)) int
>  foo (int i, int j)
>  {
> -  int b = i; /* { dg-final { gdb-test bpline "b" "7" } } */
> -  int c = i + 4; /* { dg-final { gdb-test bpline "c" "11" } } */
> -  int d = a[i];  /* { dg-final { gdb-test bpline "d" "112" } } */
> -  int e = a[i + 6];  /* { dg-final { gdb-test bpline "e" "142" } } */
> -  ++v;   /* { dg-line bpline } */
> +  int b = i; /* { dg-final { gdb-test .+4 "b" "7" } } */
> +  int c = i + 4; /* { dg-final { gdb-test .+3 "c" "11" } } */
> +  int d = a[i];  /* { dg-final { gdb-test .+2 "d" "112" } } */
> +  int e = a[i + 6];  /* { dg-final { gdb-test .+1 "e" "142" } } */
> +  ++v;
>return ++j;
>  }
>  
> diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> index 22065c7e3fe..6f88ce2213e 100644
> --- a/gcc/testsuite/lib/gcc-dg.exp
> +++ b/gcc/testsuite/lib/gcc-dg.exp
> @@ -114,6 +114,26 @@ if [info exists ADDITIONAL_TORTURE_OPTIONS] {
>   [concat $DG_TORTURE_OPTIONS $ADDITIONAL_TORTURE_OPTIONS]
>  }
>  
> +proc dg-final { args } {
> +upvar dg-final-code final-code
> +
> +if { [llength $args] > 2 } {
> + error "[lindex $args 0]: too many arguments"
> +}
> +set line [lindex $args 0]
> +set code [lindex $args 1]
> +set directive [lindex $code 0]
> +set withline \
> + [switch $directive {
> + gdb-test {expr {1}}
> + default  {expr {0}}
> + }]
> +if { $withline == 1 } {
> + set code [linsert $code 1 $line]
> +}
> +append final-code "$code\n"
> +}

Like the idea, but I think:

set withline \
[switch $directive {
gdb-test {expr {1}}
default  {expr {0}}
}]
if { $withline == 1 } {
set code [linsert $code 1 $line]
}

would be clearer as:

switch $directive {
gdb-test {
set code [linsert $code 1 $line]
}
}

Thanks,
Richard

[PATCH] P0646R1 Improving the Return Value of Erase-Like Algorithms I

[Jonathan Wakely]

In C++2a the remove, remove_if and unique members of std::list and
std::forward_list have been changed to return the number of elements
removed. This is an ABI change for the remove members and the
non-template unique members, so an abi-tag is used to give those symbols
new mangled names in C++2a mode. For the function templates the return
type is part of the mangled name so no abi-tag is needed.

* include/bits/forward_list.h (__cpp_lib_list_remove_return_type):
Define.
(forward_list::__remove_return_type): Define typedef as size_type or
void, according to __cplusplus value.
(_GLIBCXX_FWDLIST_REMOVE_RETURN_TYPE_TAG): Define macro as abi-tag or
empty, according to __cplusplus value.
(forward_list::remove, forward_list::unique): Use typedef and macro
to change return type and add abi-tag for C++2a.
(forward_list::remove_if, forward_list::unique): Use
typedef to change return type for C++2a.
* include/bits/forward_list.tcc (_GLIBCXX20_ONLY): Define macro.
(forward_list::remove, forward_list::remove_if)
(forward_list::unique): Return number of removed elements
for C++2a.
* include/bits/list.tcc (_GLIBCXX20_ONLY): Define macro.
(list::remove, list::unique, list::remove_if)
(list::unique): Return number of removed elements
for C++2a.
* include/bits/stl_list.h (__cpp_lib_list_remove_return_type): Define.
(list::__remove_return_type): Define typedef as size_type or
void, according to __cplusplus value.
(_GLIBCXX_LIST_REMOVE_RETURN_TYPE_TAG): Define macro as abi-tag or
empty, according to __cplusplus value.
(list::remove, list::unique): Use typedef and macro to change return
type and add abi-tag for C++2a.
(list::remove_if, list::unique): Use
typedef to change return type for C++2a.
* include/std/version (__cpp_lib_list_remove_return_type): Define.
* testsuite/23_containers/forward_list/operations/
remove_cxx20_return.cc: New.
* testsuite/23_containers/forward_list/operations/
unique_cxx20_return.cc: New.

Tested powerpc64le-linux, committed to trunk.


commit 438e6398493708d2fb13766c9dff5305ebb98eec
Author: Jonathan Wakely 
Date:   Wed Jul 4 20:13:34 2018 +0100

P0646R1 Improving the Return Value of Erase-Like Algorithms I

In C++2a the remove, remove_if and unique members of std::list and
std::forward_list have been changed to return the number of elements
removed. This is an ABI change for the remove members and the
non-template unique members, so an abi-tag is used to give those symbols
new mangled names in C++2a mode. For the function templates the return
type is part of the mangled name so no abi-tag is needed.

* include/bits/forward_list.h (__cpp_lib_list_remove_return_type):
Define.
(forward_list::__remove_return_type): Define typedef as size_type or
void, according to __cplusplus value.
(_GLIBCXX_FWDLIST_REMOVE_RETURN_TYPE_TAG): Define macro as abi-tag 
or
empty, according to __cplusplus value.
(forward_list::remove, forward_list::unique): Use typedef and macro
to change return type and add abi-tag for C++2a.
(forward_list::remove_if, forward_list::unique): Use
typedef to change return type for C++2a.
* include/bits/forward_list.tcc (_GLIBCXX20_ONLY): Define macro.
(forward_list::remove, forward_list::remove_if)
(forward_list::unique): Return number of removed elements
for C++2a.
* include/bits/list.tcc (_GLIBCXX20_ONLY): Define macro.
(list::remove, list::unique, list::remove_if)
(list::unique): Return number of removed elements
for C++2a.
* include/bits/stl_list.h (__cpp_lib_list_remove_return_type): 
Define.
(list::__remove_return_type): Define typedef as size_type or
void, according to __cplusplus value.
(_GLIBCXX_LIST_REMOVE_RETURN_TYPE_TAG): Define macro as abi-tag or
empty, according to __cplusplus value.
(list::remove, list::unique): Use typedef and macro to change return
type and add abi-tag for C++2a.
(list::remove_if, list::unique): Use
typedef to change return type for C++2a.
* include/std/version (__cpp_lib_list_remove_return_type): Define.
* testsuite/23_containers/forward_list/operations/
remove_cxx20_return.cc: New.
* testsuite/23_containers/forward_list/operations/
unique_cxx20_return.cc: New.

diff --git a/libstdc++-v3/include/bits/forward_list.h 
b/libstdc++-v3/include/bits/forward_list.h
index 8c4c074e454..84a4ad4d5dc 100644
--- a/libstdc++-v3/include/bits/forward_list.h
+++ b/libstdc++-v3/include/bits/forward_list.h
@@ 

[wwwdocs] Document more C++2a support in libstdc++

[Jonathan Wakely]

Committed to CVS.


? htdocs/gcc-9/.changes.html.swp
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.10
diff -u -r1.10 changes.html
--- htdocs/gcc-9/changes.html	2 Jul 2018 16:08:32 -	1.10
+++ htdocs/gcc-9/changes.html	4 Jul 2018 20:16:09 -
@@ -60,8 +60,11 @@
 Runtime Library (libstdc++)
 
   Improved experimental support for C++2a,
-  including std::remove_cvref
-  and the  header.
+  including type traits std::remove_cvref,
+  std::is_trivially_convertible, and
+  std::type_identity,
+  and headers  and .
+  
   Support for opening file streams with wide character paths on Windows
   Incomplete support for the C++17 Filesystem library and the Filesystem
   TS on Windows.

Re: [wwwdocs] Document more C++2a support in libstdc++

[Tim Song]

On Wed, Jul 4, 2018 at 4:17 PM, Jonathan Wakely  wrote:
> +  std::is_trivially_convertible, and

s/trivially/nothrow/

Re: [wwwdocs] Document more C++2a support in libstdc++

[Jonathan Wakely]

On 04/07/18 16:19 -0400, Tim Song wrote:

On Wed, Jul 4, 2018 at 4:17 PM, Jonathan Wakely  wrote:

+  std::is_trivially_convertible, and


s/trivially/nothrow/


Oops, thanks - fixed by this patch, also committed.


Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.11
diff -u -r1.11 changes.html
--- htdocs/gcc-9/changes.html	4 Jul 2018 20:16:47 -	1.11
+++ htdocs/gcc-9/changes.html	4 Jul 2018 20:21:58 -
@@ -61,7 +61,7 @@
 
   Improved experimental support for C++2a,
   including type traits std::remove_cvref,
-  std::is_trivially_convertible, and
+  std::is_nothrow_convertible, and
   std::type_identity,
   and headers  and .
   

[PATCH] Enable decimal float on x86_64 kFreeBSD and Hurd

[James Clarke]

config/
* dfp.m4 (enable_decimal_float): Enable for x86_64*-*-gnu* to
catch x86_64 kFreeBSD and Hurd.

gcc/
* configure: Regenerate.

libdecnumber/
* configure: Regenerate.

libgcc/
* configure: Regenerate.
---
 config/dfp.m4  | 2 +-
 gcc/configure  | 2 +-
 libdecnumber/configure | 2 +-
 libgcc/configure   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/config/dfp.m4 b/config/dfp.m4
index 5b29089cec5..f9b447e1a9c 100644
--- a/config/dfp.m4
+++ b/config/dfp.m4
@@ -21,7 +21,7 @@ Valid choices are 'yes', 'bid', 'dpd', and 'no'.]) ;;
 [
   case $1 in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/gcc/configure b/gcc/configure
index 60d373982fd..46be6b93a2a 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -7458,7 +7458,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/libdecnumber/configure b/libdecnumber/configure
index 4cb732e80d4..0eb6e04ffe9 100755
--- a/libdecnumber/configure
+++ b/libdecnumber/configure
@@ -4709,7 +4709,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/libgcc/configure b/libgcc/configure
index b2f3f870844..055ec66ce48 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4647,7 +4647,7 @@ else
 
   case $host in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
-- 
2.17.0

[PATCH v2] Enable decimal float on x86_64 kFreeBSD and Hurd

[James Clarke]

config/
* dfp.m4 (enable_decimal_float): Enable for x86_64*-*-gnu* to
catch x86_64 kFreeBSD and Hurd.

gcc/
* configure: Regenerate.

libdecnumber/
* configure: Regenerate.

libgcc/
* configure: Regenerate.
---

Hi,
Apologies; I accidentally sent an older version of this to the list, so
here's the correct version. Also, the motivation for this patch:

Decimal float has been enabled on GNU/Hurd for a while, by adding the
i?86*-*-gnu* pattern. However, this also matches i386 GNU/kFreeBSD
triples, such as i386-unknown-kfreebsd-gnu, yet since there is not
currently an x86_64 GNU/Hurd port there is no pattern for
x86_64*-*-gnu*, and so x86_64 GNU/kFreeBSD also does not match anything.
Thus, adding the x86_64 GNU/Hurd pattern both future-proofs the
configure script for a time when such a sytem exists, as well as making
x86_64 GNU/kFreeBSD match the behaviour of i386.

Regards,
James

 config/dfp.m4  | 2 +-
 gcc/configure  | 2 +-
 libdecnumber/configure | 2 +-
 libgcc/configure   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/config/dfp.m4 b/config/dfp.m4
index 5b29089cec5..a137ddebf8c 100644
--- a/config/dfp.m4
+++ b/config/dfp.m4
@@ -21,7 +21,7 @@ Valid choices are 'yes', 'bid', 'dpd', and 'no'.]) ;;
 [
   case $1 in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/gcc/configure b/gcc/configure
index 60d373982fd..35564942bbf 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -7458,7 +7458,7 @@ else

   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/libdecnumber/configure b/libdecnumber/configure
index 4cb732e80d4..b1588f4e884 100755
--- a/libdecnumber/configure
+++ b/libdecnumber/configure
@@ -4709,7 +4709,7 @@ else

   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/libgcc/configure b/libgcc/configure
index b2f3f870844..f395474beac 100644
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4647,7 +4647,7 @@ else

   case $host in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
--
2.17.0

[PATCH] use TYPE_SIZE instead of TYPE_DOMAIN to compute array size (PR 86400)

[Martin Sebor]

A change of mine to the strlen pass assumes that the strlen
argument points to an object of the correct type and does
not correctly handle GIMPLE where the argument has the wrong
type such as in:

  extern char a[1][2];
  n = strlen (*a);

where the strlen pass actually sees

  n = strlen (a);

The attached patch corrects the code to use TYPE_SIZE to
determine the size of the array argument rather than using
TYPE_DOMAIN.

Tested on x86_64-linux.

Martin

PR tree-optimization/86400 - set::set::set

Enhance __gnu_debug::string debug assertion

[François Dumont]

    This patch improves the assertion message generated in 2 
__gnu_debug::string constructors giving the assertion context thanks to 
the __FUNCTION__ macro.


Was:

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/string:56: 
const _CharT* __gnu_debug::__check_string(const _CharT*, _Integer, const 
char*, unsigned int, const char*) [with _CharT = char; _Integer = long 
unsigned int]: Assertion '__s != 0 || __n == 0' failed.

XFAIL: 21_strings/basic_string/debug/1_neg.cc execution test

Now:

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/string:172:
In function:
    __gnu_debug::basic_string<_CharT, _Traits,
    _Allocator>::basic_string(const _CharT*,
    __gnu_debug::basic_string<_CharT, _Traits, _Allocator>::size_type, 
const

    _Allocator&) [with _CharT = char; _Traits = std::char_traits;
    _Allocator = std::allocator; __gnu_debug::basic_string<_CharT,
    _Traits, _Allocator>::size_type = long unsigned int]

Error: __s != 0 || __n == 0.
XFAIL: 21_strings/basic_string/debug/1_neg.cc execution test

    Tested under Linux x86_64 normal and debug modes.

    If not told otherwise I plan to commit the attached patch tomorrow.

François

diff --git a/libstdc++-v3/include/debug/functions.h b/libstdc++-v3/include/debug/functions.h
index 5c16a45..97b1f94 100644
--- a/libstdc++-v3/include/debug/functions.h
+++ b/libstdc++-v3/include/debug/functions.h
@@ -239,29 +239,6 @@ namespace __gnu_debug
   return __foreign_iterator_aux(__it, __other, __other_end, _Integral());
 }
 
-  /** Checks that __s is non-NULL or __n == 0, and then returns __s. */
-  template
-inline const _CharT*
-__check_string(const _CharT* __s,
-		   const _Integer& __n __attribute__((__unused__)))
-{
-#ifdef _GLIBCXX_DEBUG_PEDANTIC
-  __glibcxx_assert(__s != 0 || __n == 0);
-#endif
-  return __s;
-}
-
-  /** Checks that __s is non-NULL and then returns __s. */
-  template
-inline const _CharT*
-__check_string(const _CharT* __s)
-{
-#ifdef _GLIBCXX_DEBUG_PEDANTIC
-  __glibcxx_assert(__s != 0);
-#endif
-  return __s;
-}
-
   // Can't check if an input iterator sequence is sorted, because we
   // can't step through the sequence.
   template
diff --git a/libstdc++-v3/include/debug/string b/libstdc++-v3/include/debug/string
index 963b84f..9568f8b 100644
--- a/libstdc++-v3/include/debug/string
+++ b/libstdc++-v3/include/debug/string
@@ -36,8 +36,50 @@
 #include 
 #include 
 
+#define _GLIBCXX_DEBUG_VERIFY_STR_COND_AT(_Cond,_File,_Line,_Func)	\
+  if (! (_Cond))			\
+__gnu_debug::_Error_formatter::_S_at(_File, _Line, _Func)		\
+  ._M_message(#_Cond)._M_error()
+
 namespace __gnu_debug
 {
+  /** Checks that __s is non-NULL or __n == 0, and then returns __s. */
+  template
+inline const _CharT*
+__check_string(const _CharT* __s,
+		   _Integer __n __attribute__((__unused__)),
+		   const char* __file __attribute__((__unused__)),
+		   unsigned int __line __attribute__((__unused__)),
+		   const char* __function __attribute__((__unused__)))
+{
+#ifdef _GLIBCXX_DEBUG_PEDANTIC
+  _GLIBCXX_DEBUG_VERIFY_STR_COND_AT(__s != 0 || __n == 0,
+	__file, __line, __function);
+#endif
+  return __s;
+}
+
+  /** Checks that __s is non-NULL and then returns __s. */
+  template
+inline const _CharT*
+__check_string(const _CharT* __s,
+		   const char* __file __attribute__((__unused__)),
+		   unsigned int __line __attribute__((__unused__)),
+		   const char* __function __attribute__((__unused__)))
+{
+#ifdef _GLIBCXX_DEBUG_PEDANTIC
+  _GLIBCXX_DEBUG_VERIFY_STR_COND_AT(__s != 0,
+	__file, __line, __function);
+#endif
+  return __s;
+}
+
+#define __glibcxx_check_string_n_constructor(_Str, _Size) \
+  __check_string(_Str, _Size, __FILE__, __LINE__, __PRETTY_FUNCTION__)
+
+#define __glibcxx_check_string_constructor(_Str) \
+  __check_string(_Str, __FILE__, __LINE__, __PRETTY_FUNCTION__)
+
   /// Class std::basic_string with safety/checking/debug instrumentation.
   template,
 	   typename _Allocator = std::allocator<_CharT> >
@@ -127,10 +169,10 @@ template,
 
   basic_string(const _CharT* __s, size_type __n,
 		   const _Allocator& __a = _Allocator())
-: _Base(__gnu_debug::__check_string(__s, __n), __n, __a) { }
+  : _Base(__glibcxx_check_string_n_constructor(__s, __n), __n, __a) { }
 
   basic_string(const _CharT* __s, const _Allocator& __a = _Allocator())
-: _Base(__gnu_debug::__check_string(__s), __a)
+  : _Base(__glibcxx_check_string_constructor(__s), __a)
   { this->assign(__s); }
 
   basic_string(size_type __n, _CharT __c,
@@ -565,7 +607,8 @@ template,
 
   template
 	iterator
-  insert(const_iterator __p, _InputIterator __first, _InputIterator __last)
+	insert(const_iterator __p,
+	   _InputIterator __first, _InputIterator __last)
 	{
 	  typename __gnu_debug::_Distance_traits<_InputIterator>::__type __dist;
 	  __glibcxx_check_insert_range(__p, __f