date:20180618


Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html

On 06/11/2018 11:34 AM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html

On 06/04/2018 05:45 PM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html

On 05/29/2018 10:19 AM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html

On 05/22/2018 07:40 PM, Martin Sebor wrote:

Here's another small refinement to -Wstringop-truncation to
avoid diagnosing more arguably "safe" cases of strncat() that
match the expected pattern of

  strncat (d, s, sizeof d - strlen (d) - 1);

such as

  extern char a[4];
  strncat (a, "12", sizeof d - strlen (a) - 1);

Since the bound is derived from the length of the destination
as GCC documents is the expected use, the call should probably
not be diagnosed even though truncation is possible.

The trouble with strncat is that it specifies a single count
that can be (and has been) used to specify either the remaining
space in the destination or the maximum number of characters
to append, but not both.  It's nearly impossible to tell for
certain which the author meant, and if it's safe, hence all
this fine-tuning.  I suspect this isn't the last tweak, either.

In any event, I'd like to commit the patch to both trunk and
gcc-8-branch.  The bug isn't marked regression but I suppose
it could (should) well be considered one.

Martin

Re: RFA: Restore ability to build zlib in a srcdir == builddir

OK.

On Mon, Jun 18, 2018 at 5:35 AM, Nick Clifton  wrote:
> Hi Guys,
>
>   The patch below allows the zlib library to be built when the build
>   directory is the same as the source directory.  This patch has been in
>   the binutils/gdb sources for a while now, but unfortunately was never
>   copied to gcc.  So I am trying to right that mistake now.
>
>   OK to apply ?
>
> Cheers
>   Nick
>
> ./ChangeLog
> * zlib/configure.ac: Restore old behaviour of only enabling
> multilibs when a target subdirectory is defined.  This allows
> building with srcdir == builddir.
> * zlib/configure: Regenerate.
>
> diff --git a/zlib/configure.ac b/zlib/configure.ac
> index fb8d943905..57d6fa56b6 100644
> --- a/zlib/configure.ac
> +++ b/zlib/configure.ac
> @@ -4,7 +4,9 @@ AC_PREREQ(2.64)
>  AC_INIT
>  AC_CONFIG_SRCDIR([zlib.h])
>
> -AM_ENABLE_MULTILIB(, ..)
> +if test -n "${with_target_subdir}"; then
> +  AM_ENABLE_MULTILIB(, ..)
> +fi
>
>  AC_CANONICAL_SYSTEM

Re: [PATCH], Backport IEEE 128-bit changes to GCC 8.x, preliminary, Patch #3

As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch.  The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.

I'm sending out these patches in terms of the submission to the FSF trunk.  I
will probably wait a few days before committing the patches just in case
something major was broken.

Patch #1 is the May 21st submission.  Note, in this patch, we had 3 separate
types activelly used (__ibm128, __float128, and long double).  However we
eventually decided we only wanted to use 2 types, and this changed in Patch #2.

Patch #2 is the June 1-8th changes by me (Michael Meissner), Segher Boessenkool
and David Edelsohn.  In the second set of changed we changed this to the
current two active types, one of which is the long double type, and other is
the alternate type.  We also changed the C++ mangling of the float128 type (and
long double if it uses the IEEE 128-bit encoding) from "U10__float128" to
"u9__ieee128".  We put out weak aliases so that old code could still call
functions compiled with the new compiler.

Patch #3 is the change committed on June 18th that reworks the internal
ordering of the 128-bit binary floating point types.  This prevents the machine
independent portions of the compiler trying to convert __ibm128 data to
__float128 if you are running on a Power9 (ISA 3.0) system that has 128-bit
hardware floating point support.

Patch #4 will be a collection of small patches to fix some problems that were
noticed in running the test suite with the long double default changed to IEEE
128-bit floating point.

This is patch #3.

[gcc]
2018-06-18  Michael Meissner  

Back port from trunk
2018-06-18  Michael Meissner  

PR target/85358
* config/rs6000/rs6000-modes.def (toplevel): Rework the 128-bit
floating point modes, so that IFmode is numerically greater than
TFmode, which is greater than KFmode using FRACTIONAL_FLOAT_MODE
to declare the ordering.  This prevents IFmode from being
converted to TFmode when long double is IEEE 128-bit on an ISA 3.0
machine.  Include rs6000-modes.h to share the fractional values
between genmodes* and the rest of the compiler.
(IFmode): Likewise.
(KFmode): Likewise.
(TFmode): Likewise.
* config/rs6000/rs6000-modes.h: New file.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Change the
meaning of rs6000_long_double_size so that 126..128 selects an
appropriate 128-bit floating point type.
(rs6000_option_override_internal): Likewise.
* config/rs6000/rs6000.h (toplevel): Include rs6000-modes.h.
(TARGET_LONG_DOUBLE_128): Change the meaning of
rs6000_long_double_size so that 126..128 selects an appropriate
128-bit floating point type.
(LONG_DOUBLE_TYPE_SIZE): Update comment.
* config/rs6000/rs6000.md (trunciftf2): Correct the modes of the
source and destination to match the standard usage.
(truncifkf2): Likewise.
(copysign3, IEEE iterator): Rework copysign of float128 on
ISA 2.07 to use an explicit clobber, instead of passing in a
temporary.
(copysign3_soft): Likewise.

[libgcc]
2018-06-18  Michael Meissner  

Back port from trunk
2018-06-18  Michael Meissner  

* config/rs6000/t-float128 (FP128_CFLAGS_SW): Compile float128
support modules with -mno-gnu-attribute.
* config/rs6000/t-float128-hw (FP128_CFLAGS_HW): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-modes.def
===
--- gcc/config/rs6000/rs6000-modes.def  (revision 261712)
+++ gcc/config/rs6000/rs6000-modes.def  (working copy)
@@ -18,16 +18,39 @@
along with GCC; see the file COPYING3.  If not see
.  */
 
-/* IBM 128-bit floating point.  IFmode and KFmode use the fractional float
-   support in order to declare 3 128-bit floating point types.  */
-FRACTIONAL_FLOAT_MODE (IF, 106, 16, ibm_extended_format);
+/* We order the 3 128-bit floating point types so that IFmode (IBM 128-bit
+   floating point) is the 128-bit floating point type with the highest
+   precision (128 bits).  This so that machine independent parts of the
+   compiler do not try to widen IFmode to TFmode on ISA 3.0 (power9) that has
+   hardware support for IEEE 128-bit.  We set TFmode (long double mode) in
+   between, and KFmode (explicit __float128) below it.
+
+   Previously, IFmode and KFmode were defined to be fractional modes and TFmode
+   was the standard mode.  Since IFmode does not define the normal arithmetic
+   insns (other than neg/abs), on a ISA

Re: [PATCH] Use __builtin_memmove for trivially copy assignable types

2018-06-18 Thread Glen Fernandes

On Mon, Jun 18, 2018 at 6:12 PM Ville Voutilainen wrote:
> On 16 June 2018 at 18:05, Marc Glisse wrote:
> > On Sat, 16 Jun 2018, Glen Fernandes wrote:
> >
> >> Use __builtin_memmove for trivially copy assignable types
> >>
> >> 2018-06-14  Glen Joseph Fernandes  
> >>
> >>* include/bits/stl_algobase.h
> >>(__is_simple_copy_move): Defined helper.
> >>(__copy_move_a): Used helper.
> >>(__copy_move_backward_a): Likewise.
> >>* testsuite/25_algorithms/copy/58982.cc: Updated tests.
> >>* testsuite/25_algorithms/copy_n/58982.cc: Likewise.
> >>
> >> Tested x86_64-pc-linux-gnu.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 looks related but for a
> > different function. Hopefully the issues discussed there don't apply here...
>
> I would certainly prefer this sort of patches to check via tests that
> uninitialized_{copy,move} is unaffected.

Will do.

Glen

C++ PATCHes for c++/86200, ICE with unexpanded pack in lambda parameter

Now that we allow unexpanded packs in a lambda, since they can be part
of the pattern of a pack expansion, we need to look at the argument
types when we scan the full-expression later.

But fixing this added an unexpected error to the test for 81060, where
we weren't properly diagnosing the unexpanded pack.  Fixing that makes
the unexpected error go away.

I also noticed that the diagnostic location for the unexpanded pack in
the lambda was the trailing semicolon, which is suboptimal.  This
turned out to be because EXPR_LOC_OR_LOC doesn't consider
LAMBDA_EXPR_LOCATION, because LAMBDA_EXPR is tcc_exceptional, not
EXPR_P.  So I'm introducing cp_expr_loc_or_loc that handles
LAMBDA_EXPR as well.

I'm also changing the location of a LAMBDA_EXPR to be its full range,
rather than just the first [.

Tested x86_64-pc-linux-gnu, applying to trunk.  First two patches also
applying to 8.
commit d9959931944e05e8d4d7db5a0f617d5a47ee2f1a
Author: Jason Merrill 
Date:   Mon Jun 18 16:03:32 2018 -0400

PR c++/86200 - ICE with unexpanded pack in lambda parameter.

* pt.c (find_parameter_packs_r) [LAMBDA_EXPR]: Also look into the
function type.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5af0f9afefc..b783b5e1436 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3839,8 +3839,10 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees, void* data)
 	 cap; cap = TREE_CHAIN (cap))
 	  cp_walk_tree (_VALUE (cap), _parameter_packs_r, ppd,
 			ppd->visited);
-	/* Since we defer implicit capture, look in the body as well.  */
+	/* Since we defer implicit capture, look in the parms and body.  */
 	tree fn = lambda_function (t);
+	cp_walk_tree (_TYPE (fn), _parameter_packs_r, ppd,
+		  ppd->visited);
 	cp_walk_tree (_SAVED_TREE (fn), _parameter_packs_r, ppd,
 		  ppd->visited);
 	*walk_subtrees = 0;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic7.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic7.C
new file mode 100644
index 000..c5355b0a8d8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic7.C
@@ -0,0 +1,14 @@
+// PR c++/86200
+// { dg-do compile { target c++11 } }
+
+template
+static void foo()
+{
+  [](Args, int x) {
+x;
+  };// { dg-error "packs not expanded" }
+}
+int main()
+{
+  foo();
+}

Re: [PATCH] avoid ICE when pretty-printing a VLA with an error bound (PR 85956)


On 05/31/2018 11:43 AM, Jakub Jelinek wrote:

On Thu, May 31, 2018 at 01:34:19PM -0400, Jason Merrill wrote:

Where is the error_mark_node coming from in the first place?


remap_type invoked during omp-low.c (scan_omp).
omp_copy_decl returns error_mark_node for decls that tree-inline.c wants
to remap, but they aren't actually remapped for some reason.
For normal VLAs gimplify.c makes sure the needed artifical decls are
firstprivatized, but in this case (VLA not in some decl's type, but just
referenced indirectly through pointers) nothing scans those unless
those temporaries are actually used in the code.


Returning error_mark_node from omp_copy_decl and then continuing seems
like the problem, then.  Would it really be that hard to return an
uninitialized variable instead?


The routine doesn't know if it is used in a context of a VLA bound or
something else, in the former case it is acceptable to swap it for some
other var, but in the latter case it would be just a bug, so using
error_mark_node in that case instead is better to catch those.
I can try to do that in tree-inline.c, but really not sure how hard would it
be.
Or handle it in the gimplifier, scan for such vars and add private clauses
for those, that will mean nothing will be passed around.


Are you still working on this approach or should I resubmit my
simple patch with the corresponding change for the C++ FE?

Martin

PING [PATCH] update Zero-length array documentation


Attached is an updated patch with the additional text as
discussed below.

Martin

On 06/11/2018 03:05 PM, Martin Sebor wrote:

On 06/11/2018 02:03 PM, Richard Sandiford wrote:

Martin Sebor  writes:

On 06/11/2018 12:08 PM, Richard Sandiford wrote:

Martin Sebor  writes:

@@ -1553,12 +1553,28 @@ struct line *thisline = (struct line *)
 thisline->length = this_length;
 @end smallexample

-In ISO C90, you would have to give @code{contents} a length of 1,
which
-means either you waste space or complicate the argument to
@code{malloc}.
+Although the size of a zero-length array is zero, an array member of
+this kind may increase the size the enclosing type as a result of
tail
+padding.  The offset of a zero-length array member from the beginning
+of the enclosing structure is the same as the offset of an array with
+one or more elements of the same type.  The alignment of a
zero-length
+array is the same as the alignment of its elements.

-In ISO C99, you would use a @dfn{flexible array member}, which is
-slightly different in syntax and semantics:
+Declaring zero-length arrays in other contexts, including as interior
+members of structure objects or as non-member objects is discouraged.
+Accessing elements of zero-length arrays declared in such contexts is
+undefined and may be diagnosed.

+In the absence of the zero-length array extension, in ISO C90 the
+@code{contents} array in the example above would typically be
declared
+to have a single element.  Although this technique is discouraged,
GCC
+handles trailing one-element array members similarly to zero-length
+arrays.


This last sentence seems a bit vague.  E.g. GCC should never diagnose
an access to element 0 of a 1-element trailing array, whereas (like you
say above) it might for zero-length trailing arrays.


GCC doesn't diagnose past-the-end accesses to trailing member
arrays regardless of their size.  I don't think it should start
diagnosing them for zero-length arrays, and probably not even
for one-element arrays (at least not in C90 mode).  I think in
the future it would be worthwhile to consider diagnosing past-
the-end accesses to trailing member arrays of two or more
elements, but this patch isn't meant to suggest it's done yet.
At the same time, I do want to leave the door open to diagnosing
such accesses eventually, so I don't want to go into too much
detail describing exactly what is and what isn't diagnosed today.


Yeah, agree that we shouldn't go into detail about what is
and isn't diagnosed.  I just don't think we should claim that
one-element arrays are treated "similarly" to zero-length arrays
without saying what "similarly" means.  They're certainly different
at some level, otherwise the extension wouldn't have been added :-)

If we don't want to give much more detail about this then I think it
would be better to keep the original paragraph:

  In ISO C90, you would have to give @code{contents} a length of 1, which
  means either you waste space or complicate the argument to
@code{malloc}.

instead of the last one.  (The other changes look good to me FWIW.)


I changed it because the text seemed both vague (why does it waste
space and what complication to the malloc call would avoid wasting
it?) and superfluous (it seems obvious that a one-element array
takes up at least 1 unit worth of space, and that allocating less
would mean changing the malloc argument).  But perhaps it would
be helpful to be explicit about the allocation size while still
saying as little as possible about diagnostics.  How abut this:

  In the absence of the zero-length array extension, in ISO C90
  the @code{contents} array in the example above would typically
  be declared to have a single element.  Unlike a zero-length
  array which only contributes to the size of the enclosing
  structure for the purposes of alignment, a one-element array
  always occupies at least as much space as a single object of
  the type.  Although using one-element arrays this way is
  discouraged, GCC handles accesses to trailing one-element
  array members analogously to zero-length arrays.



Noticed later,


+The preferred mechanism to declare variable-length types like
+@code{struct line} above is the ISO C99 @dfn{flexible array member},
+with slightly different in syntax and semantics:


Don't think the s/which is/with/ change is correct here.


Thanks, fixed.

Martin


gcc/ChangeLog:

	* doc/extend.texi (Zero-length arrays): Update and clarify.

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 261716)
+++ gcc/doc/extend.texi	(working copy)
@@ -1537,9 +1537,9 @@ defined when these address spaces are supported.
 @cindex length-zero arrays
 @cindex flexible array members
 
-Zero-length arrays are allowed in GNU C@.  They are very useful as the
-last element of a structure that is really a header for a variable-length
-object:
+Declaring zero-length arrays is allowed in GNU C as an extension.
+A

Re: [PATCH], Backport IEEE 128-bit changes to GCC 8.x, Patch #2

As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch.  The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.

I'm sending out these patches in terms of the submission to the FSF trunk.  I
will probably wait a few days before committing the patches just in case
something major was broken.

Patch #1 is the May 21st submission.  Note, in this patch, we had 3 separate
types activelly used (__ibm128, __float128, and long double).  However we
eventually decided we only wanted to use 2 types, and this changed in Patch #2.

Patch #2 is the June 1-8th changes by me (Michael Meissner), Segher Boessenkool
and David Edelsohn.  In the second set of changed we changed this to the
current two active types, one of which is the long double type, and other is
the alternate type.  We also changed the C++ mangling of the float128 type (and
long double if it uses the IEEE 128-bit encoding) from "U10__float128" to
"u9__ieee128".  We put out weak aliases so that old code could still call
functions compiled with the new compiler.

Patch #3 is the change committed on June 18th that reworks the internal
ordering of the 128-bit binary floating point types.  This prevents the machine
independent portions of the compiler trying to convert __ibm128 data to
__float128 if you are running on a Power9 (ISA 3.0) system that has 128-bit
hardware floating point support.

Patch #4 will be a collection of small patches to fix some problems that were
noticed in running the test suite with the long double default changed to IEEE
128-bit floating point.

This is patch #2.  Patches #1 and #2 were tested together on a little endian
power8 system.  I did two runs.  The first run used the default long double as
IBM extended double, and there were no regressions.  The second run changed the
default to IEEE 128-bit floating point.  The regressions were the same as in
the GCC trunk for the same submission level.

[gcc]
2018-06-18  Michael Meissner  

Back port from trunk
2018-06-08  David Edelsohn  

* config/rs6000/rs6000.c (rs6000_passes_ieee128): Protect with #if
TARGET_ELF.

Back port from trunk
2018-06-04  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_passes_ieee128): New boolean to
track if we pass or return IEEE 128-bit floating point.
(ieee128_mangling_gcc_8_1): New boolean to say whether to generate
C++ mangling that is compatible with GCC 8.1.
(TARGET_ASM_GLOBALIZE_DECL_NAME): Override target hook.
(init_cumulative_args): Note if we pass or return IEEE 128-bit
floating point types.
(rs6000_function_arg_advance_1): Likewise.
(rs6000_mangle_type): Optionally generate mangled names that match
what GCC 8.1 generated for IEEE 128-bit floating point types.
(rs6000_globalize_decl_name): If we have an external function that
passes or returns IEEE 128-bit types, generate a weak reference
from the mangled name used in GCC 8.1 to the current mangled
name.
(rs6000_init_builtins): Make __ibm128 use the long double type if
long double is IBM extended double.  Make __float128 use the long
double type if long double is IEEE 128-bit.

PR target/85657
* config/rs6000/rs6000-builtin.def (BU_IBM128_2): New helper
macro for __ibm128 built-in functions.
(PACK_IF): Add __ibm128 pack/unpack functions.
(UNPACK_IF): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Do not
enable long double built-in functions if long double is IEEE
128-bit floating point.
(rs6000_invalid_builtin): Update long double built-in function
error message.
(rs6000_expand_builtin): For PACK_IF and UNPACK_IF built-in
functions, adjust the built-in function to use the long double
built-in function if __ibm128 and long double are the same type.
* doc/extend.texi (PowerPC builtins): Update documention for
__builtin_{,un}pack_longdouble.  Add documentation for
__builtin_{,un}pack_ibm128.

Back port from trunk
2018-06-01  Segher Boessenkool  

* config/rs6000/rs6000.c (rs6000_mangle_type): Change the mangling of
the 128-bit floating point types.  Fix function comment.

[gcc/testsuite]
2018-06-18  Michael Meissner  

Back port from trunk
2018-06-06  Michael Meissner  

PR target/85657
* g++.dg/pr85657.C: Only test whether __ibm128 and long double can
be used in templates.  Don't check for them in overloaded functions.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

backporting fix for pr85602 to 8 branch


Richard & Jakub,

I would like to backport the fix for pr85602 to gcc-8-branch.
Can you please review the original patch below and let me know
if you have any concerns with the backport?

https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00869.html

Thanks
Martin

Re: [PATCH], Backport IEEE 128-bit changes to GCC 8.x, Patch #1

As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch.  The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.

I'm sending out these patches in terms of the submission to the FSF trunk.  I
will probably wait a few days before committing the patches just in case
something major was broken.

Patch #1 is the May 21st submission.  Note, in this patch, we had 3 separate
types activelly used (__ibm128, __float128, and long double).  However we
eventually decided we only wanted to use 2 types, and this changed in Patch #2.

Patch #2 is the June 1-8th changes by me (Michael Meissner), Segher Boessenkool
and David Edelsohn.  In the second set of changed we changed this to the
current two active types, one of which is the long double type, and other is
the alternate type.  We also changed the C++ mangling of the float128 type (and
long double if it uses the IEEE 128-bit encoding) from "U10__float128" to
"u9__ieee128".  We put out weak aliases so that old code could still call
functions compiled with the new compiler.

Patch #3 is the change committed on June 18th that reworks the internal
ordering of the 128-bit binary floating point types.  This prevents the machine
independent portions of the compiler trying to convert __ibm128 data to
__float128 if you are running on a Power9 (ISA 3.0) system that has 128-bit
hardware floating point support.

Patch #4 will be a collection of small patches to fix some problems that were
noticed in running the test suite with the long double default changed to IEEE
128-bit floating point.

This is patch #1.  Patches #1 and #2 were tested together on a little endian
power8 system.  I did two runs.  The first run used the default long double as
IBM extended double, and there were no regressions.  The second run changed the
default to IEEE 128-bit floating point.  The regressions were the same as in
the GCC trunk for the same submission level.

[gcc]
2018-06-18  Michael Meissner  

Back port from trunk
2018-05-21  Michael Meissner  

PR target/85657
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Do not
define __ibm128 as long double.
* config/rs6000/rs6000.c (rs6000_init_builtins): Create __ibm128
as a distinct type with IEEE 128-bit floating point is supported.
(init_float128_ieee): Fix up conversions between IFmode and IEEE
128-bit types to use the correct functions.
(rs6000_expand_float128_convert): Use explicit FLOAT_EXTEND to
convert between 128-bit floating point types that have different
modes but the same representation, instead of using gen_lowpart to
makean alias.
* config/rs6000/rs6000.md (IFKF): New iterator for IFmode and
KFmode.
(IFKF_reg): New attributes to give the register constraints for
IFmode and KFmode.
(extendtf2_internal): New insns to mark an explicit
conversion between 128-bit floating point types that have a
different mode but share the same representation.

[gcc/testsuite]
2018-06-18  Michael Meissner  

Back port from trunk
2018-05-21  Michael Meissner  

PR target/85657
* gcc.target/powerpc/pr85657-1.c: New test for converting between
__float128, __ibm128, and long double.
* gcc.target/powerpc/pr85657-2.c: Likewise.
* gcc.target/powerpc/pr85657-3.c: Likewise.
* g++.dg/pr85667.C: New test to make sure __ibm128 is
implementated as a separate type internally, and is not just an
alias for long double.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 261664)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -617,8 +617,6 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfi
 builtin_define ("__RSQRTEF__");
   if (TARGET_FLOAT128_TYPE)
 builtin_define ("__FLOAT128_TYPE__");
-  if (TARGET_LONG_DOUBLE_128 && FLOAT128_IBM_P (TFmode))
-builtin_define ("__ibm128=long double");
 #ifdef TARGET_LIBC_PROVIDES_HWCAP_IN_TCB
   builtin_define ("__BUILTIN_CPU_SUPPORTS__");
 #endif
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 261664)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -17027,35 +17027,28 @@ rs6000_init_builtins (void)
  floating point, we need make sure the type is non-zero or else self-test
  fails during bootstrap.
 
- We don't register a built-in type for __ibm128 if the type is the same as
- long double.  Instead we add a #define for __ibm128 in
-

[PATCH], Backport IEEE 128-bit changes to GCC 8.x, preliminary

As we have discussed on the patch submission, I'm going to be back porting the
IEEE 128-bit changes that we've made recently in the trunk to the GCC 8.x
branch.  The motivation is to allow distributions to switch to IEEE 128-bit
long double without having to wait for the GCC 9.1 compiler.

I'm sending out these patches in terms of the submission to the FSF trunk.  I
will probably wait a few days before committing the patches just in case
something major was broken.

Patch #1 is the May 21st submission.  Note, in this patch, we had 3 separate
types activelly used (__ibm128, __float128, and long double).  However we
eventually decided we only wanted to use 2 types, and this changed in Patch #2.

Patch #2 is the June 1-8th changes by me (Michael Meissner), Segher Boessenkool
and David Edelsohn.  In the second set of changed we changed this to the
current two active types, one of which is the long double type, and other is
the alternate type.  We also changed the C++ mangling of the float128 type (and
long double if it uses the IEEE 128-bit encoding) from "U10__float128" to
"u9__ieee128".  We put out weak aliases so that old code could still call
functions compiled with the new compiler.

Patch #3 is the change committed on June 18th that reworks the internal
ordering of the 128-bit binary floating point types.  This prevents the machine
independent portions of the compiler trying to convert __ibm128 data to
__float128 if you are running on a Power9 (ISA 3.0) system that has 128-bit
hardware floating point support.

Patch #4 will be a collection of small patches to fix some problems that were
noticed in running the test suite with the long double default changed to IEEE
128-bit floating point.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] gracefully deal with invalid strlen declarations (PR 86114)


On 06/12/2018 03:37 PM, Jeff Law wrote:

On 06/12/2018 03:29 PM, Martin Sebor wrote:

Declaring strlen() to return a pointer instead of size_t
and then calling the function can result in an ICE due to
both gimple-fold and tree-ssa-strlen assuming the function
necessarily returns an integer.

As luck would have it, the incompatible declaration isn't
detected by -Wbuiltin-declaration-mismatch (bug 86125), nor
apparently even by gimple_builtin_call_types_compatible_p(),
and so the invalid declaration makes its way where it isn't
expected.

The attached patch avoids the ICE by removing the unsafe
assumption from both the folder and the strlen pass.

Martin

gcc-86114.diff


PR tree-optimization/86114 - ICE in gimple_fold_builtin_strlen with an invalid 
call to strnlen

gcc/testsuite/ChangeLog:

PR tree-optimization/86114
* gcc.dg/pr86114.c: New test.

gcc/ChangeLog:

PR tree-optimization/86114
* gimple-fold.c (gimple_fold_builtin_strlen): Only handle LHS
of integer types.
* tree-ssa-strlen.c (maybe_set_strlen_range): Same.

OK.  However ISTM that catching this earlier would be advisable.


Agreed.  Discarding invalid built-in declarations (in addition
to issuing a warning) would have prevented this bug as well as
bug 86202.  I'm working on a patch to at least warn on these
bad declarations if not drop them altogether (as GCC already
does some others).  This is bug 86125.

Martin

Re: [PATCH] Use __builtin_memmove for trivially copy assignable types

2018-06-18 Thread Ville Voutilainen

On 16 June 2018 at 18:05, Marc Glisse  wrote:
> On Sat, 16 Jun 2018, Glen Fernandes wrote:
>
>> Use __builtin_memmove for trivially copy assignable types
>>
>> 2018-06-14  Glen Joseph Fernandes  
>>
>>* include/bits/stl_algobase.h
>>(__is_simple_copy_move): Defined helper.
>>(__copy_move_a): Used helper.
>>(__copy_move_backward_a): Likewise.
>>* testsuite/25_algorithms/copy/58982.cc: Updated tests.
>>* testsuite/25_algorithms/copy_n/58982.cc: Likewise.
>>
>> Tested x86_64-pc-linux-gnu.
>
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350 looks related but for a
> different function. Hopefully the issues discussed there don't apply here...

I would certainly prefer this sort of patches to check via tests that
uninitialized_{copy,move} is unaffected.

[PATCH] xtensa: fix PR target/65416

2018-06-18 Thread Max Filippov

The issue is caused by reordering of stack pointer update after stack
space allocation with instructions that write to the allocated stack
space. In windowed ABI register spill area for the previous call frame
is located just below the stack pointer and may be reloaded back into
the register file on movsp.
Implement allocate_stack pattern for windowed ABI configuration and
insert an instruction that prevents reordering of frame memory access
and stack pointer update.

gcc/
2018-06-17  Max Filippov  

* config/xtensa/xtensa.md (UNSPEC_FRAME_BLOCKAGE): New unspec
constant.
(allocate_stack, frame_blockage, *frame_blockage): New patterns.
---
 gcc/config/xtensa/xtensa.md | 46 +
 1 file changed, 46 insertions(+)

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 84967dbedc08..209f839cfb0f 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -38,6 +38,7 @@
   (UNSPEC_MEMW 11)
   (UNSPEC_LSETUP_START  12)
   (UNSPEC_LSETUP_END13)
+  (UNSPEC_FRAME_BLOCKAGE 14)
 
   (UNSPECV_SET_FP  1)
   (UNSPECV_ENTRY   2)
@@ -1676,6 +1677,32 @@
 
 ;; Miscellaneous instructions.
 
+;; In windowed ABI stack pointer adjustment must happen before any access
+;; to the space allocated on stack is allowed, otherwise register spill
+;; area may be clobbered.  That's what frame blockage is supposed to enforce.
+
+(define_expand "allocate_stack"
+  [(set (match_operand 0 "nonimmed_operand")
+(minus (reg A1_REG) (match_operand 1 "add_operand")))
+   (set (reg A1_REG)
+(minus (reg A1_REG) (match_dup 1)))]
+  "TARGET_WINDOWED_ABI"
+{
+  if (CONST_INT_P (operands[1]))
+{
+  rtx neg_op0 = GEN_INT (-INTVAL (operands[1]));
+  emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx, neg_op0));
+}
+  else
+{
+  emit_insn (gen_subsi3 (stack_pointer_rtx, stack_pointer_rtx,
+operands[1]));
+}
+  emit_move_insn (operands[0], virtual_stack_dynamic_rtx);
+  emit_insn (gen_frame_blockage ());
+  DONE;
+})
+
 (define_expand "prologue"
   [(const_int 0)]
   ""
@@ -1767,6 +1794,25 @@
   [(set_attr "length" "0")
(set_attr "type" "nop")])
 
+;; Do not schedule instructions accessing memory before this point.
+
+(define_expand "frame_blockage"
+  [(set (match_dup 0)
+(unspec:BLK [(match_dup 1)] UNSPEC_FRAME_BLOCKAGE))]
+  ""
+{
+  operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
+  MEM_VOLATILE_P (operands[0]) = 1;
+  operands[1] = stack_pointer_rtx;
+})
+
+(define_insn "*frame_blockage"
+  [(set (match_operand:BLK 0 "" "")
+(unspec:BLK [(match_operand:SI 1 "" "")] UNSPEC_FRAME_BLOCKAGE))]
+  ""
+  ""
+  [(set_attr "length" "0")])
+
 (define_insn "trap"
   [(trap_if (const_int 1) (const_int 0))]
   ""
-- 
2.11.0

Rope iterator patch reminder

2018-06-18 Thread Jeremy Sawicki

Last month I sent a patch for a bug in the rope template.  I want to 
make sure it is not forgotten:


https://gcc.gnu.org/ml/libstdc++/2018-05/msg00115.html
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01006.html

When an iterator is copied or assigned, the copy can retain pointers to 
an internal buffer in the original.  When the copy is later 
dereferenced, problems ranging from incorrect results to undefined 
behavior can occur depending on what has happened to the original in the 
meantime.  See the test in the patch for a reproducible case.


Please let me know if anything else is needed from me.

Jeremy

Limit Debug mode impact: overload __niter_base

2018-06-18 Thread François Dumont


Hi

    I abandon the idea of providing Debug algos, it would be too much 
code to add and maintain. However I haven't quit on reducing Debug mode 
performance impact.


    So this patch make use of the existing std::__niter_base to get rid 
of the debug layer around __gnu_debug::vector<>::iterator so that 
__builtin_memmove replacement can take place.


    As _Safe_iterator<> do not have a constructor taking a pointer I 
change algos implementation so that we do not try to instantiate the 
iterator type ourselves but rather rely on its operators + or -.


    The small drawback is that for std::equal algo where we can't use 
the __glibcxx_can_increment we need to keep the debug layer to make sure 
we don't reach past-the-end iterator. So I had to remove usage of 
__niter_base when in Debug mode, doing so it also disable potential 
usage of __builtin_memcmp when calling std::equal on 
std::__cxx1998::vector<> iterators. A rather rare situation I think.


    Note that I don't know how to test that __builtin_memmove has been 
indeed used. So I've been through some debug sessions to check that.


    I am not really happy with ChangeLog entry I came up with, I'll try 
to improve it before this patch is validated.



    * include/bits/stl_algobase.h
    (__copy_move<_IsMove, _IsSimple, random_access_iterator_tag>
    ::__copy_impl): New.
    (__copy_move<_IsMove, _IsSimple, random_access_iterator_tag>
    ::__copy_m): Use latter.
    (__copy_move<_IsMove, true, random_access_iterator_tag>::__copy_m):
    Add __base_res parameter.
    (__copy_move<_IsMove, true, random_access_iterator_tag>::__copy_m): Add
    __res_base parameter and use it to call __builtin_memmove.
    (__copy_move_a): Adapt.
    (__copy_move_a2): Adapt.
    (__copy_move_backward<_IsMove, _IsSimple, random_access_iterator_tag>
    ::__copy_b_impl): New.
    (__copy_move_backward<_IsMove, _IsSimple, random_access_iterator_tag>
    ::__copy_move_b): Use latter.
    (__copy_move_backward<_IsMove, true, random_access_iterator_tag>
    ::__copy_move_b): Add __res_base parameter and use it to call
    __builtin_memmove.
    (__copy_move_backward_a): Adapt.
    (__copy_move_backward_a2): Adapt.
    (__fill_n_a): Add _OI template parameter.
    (std::equal<>(_II1, _II1, _II2)): Remove usage of __niter_base on
    __first2 in _GLIBCXX_DEBUG mode.
    * include/debug/stl_iterator.h
    (std::__niter_base(const __gnu_cxx::_Safe_iterator<
    __gnu_cxx::__normal_iterator<>, _Sequence>&)): New declaration.
    * include/debug/vector (__niter_base(const __gnu_cxx::_Safe_iterator<
    __gnu_cxx::__normal_iterator<>, _Sequence>&)): New.

Tested under x86_64 linux.

Ok to commit ?

François

diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h
index d429943..100676b 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -286,9 +286,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct __copy_move
 {
-  template
+  template
 	static _OI
-	__copy_m(_II __first, _II __last, _OI __result)
+	__copy_m(_II __first, _II __last, _OI __result, _OIBase)
 	{
 	  for (; __first != __last; ++__result, (void)++__first)
 	*__result = *__first;
@@ -300,9 +300,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 struct __copy_move
 {
-  template
+  template
 	static _OI
-	__copy_m(_II __first, _II __last, _OI __result)
+	__copy_m(_II __first, _II __last, _OI __result, _OIBase)
 	{
 	  for (; __first != __last; ++__result, (void)++__first)
 	*__result = std::move(*__first);
@@ -314,9 +314,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template<>
 struct __copy_move
 {
+private:
   template
 	static _OI
-	__copy_m(_II __first, _II __last, _OI __result)
+	__copy_impl(_II __first, _II __last, _OI __result)
 	{
 	  typedef typename iterator_traits<_II>::difference_type _Distance;
 	  for (_Distance __n = __last - __first; __n > 0; --__n)
@@ -327,15 +328,30 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	}
 	  return __result;
 	}
+
+public:
+  template
+	static _OI
+	__copy_m(_II __first, _II __last, _OI __result, _OI)
+	{ return __copy_impl(__first, __last, __result); }
+
+  template
+	static _OI
+	__copy_m(_II __first, _II __last, _OI __result, _OIBase __res_base)
+	{
+	  _OIBase __end = __copy_impl(__first, __last, __res_base);
+	  return __result + (__end - __res_base);
+	}
 };
 
 #if __cplusplus >= 201103L
   template<>
 struct __copy_move
 {
+private:
   template
 	static _OI
-	__copy_m(_II __first, _II __last, _OI __result)
+	__copy_impl(_II __first, _II __last, _OI __result)
 	{
 	  typedef typename iterator_traits<_II>::difference_type _Distance;
 	  for (_Distance __n = __last - __first; __n > 0; --__n)
@@ -346,15 +362,30 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	}
 	  return __result;
 	}
+
+public:
+  template
+	static _OI
+	__copy_m(_II __first, _II __last, _OI __result, _OI)
+	{ return

Re: [PATCH, rs6000] Fix AIX expected builtin instruction counts

2018-06-18 Thread Carl Love

Segher:

Per our discussions, the previous patch had issues with the target
!powerpc*-*-aix* not working correctly and thus the instruction count
test was not being done.  I have addressed those issues and verified by
inspecting the gcc/testsuite/gcc/gcc.log file to make sure the test was
actually executed.

As for the issues with the xxlxor being used as a move instruction in
builtins-1.c, I moved vec_or instructions to a new file.  The number of
xxlor instructions from the vec_or test cases can now be cleanly
counted without the move instructions from other tests.

I found in a few places that by qualifying the instruction counts
better, I was able to remove the target for BE and LE and m32 versus
m64.

I added the -dp option to the vsx-vector-6.p7.c test file.

I have retested again on 

powerpc64le-unknown-linux-gnu (Power 8 LE)  
powerpc64-unknown-linux-gnu (Power 8 BE)
    AIX 7200-00-01-1543 (Power 8 BE)

With no regressions.

Please let me know if the patch looks OK for GCC mainline. 

 Carl Love



gcc/testsuite/ChangeLog:

2018-06-18  Carl Love  

* gcc.target/powerpc/altivec-7.c: Add qualifiers for counts on AIX
versus Linux.
* gcc.target/powerpc/builtins-1.c: Move vec_or tests to a new file.
Add powerpc*-*-aix* and powerpc*-*-linux* target qualifiers.
* gcc.target/powerpc/builtins-4.c: Fix matching for vsl instructions.
* gcc.target/powerpc/builtins-5.c: New test file for vec_or test cases.
* gcc.target/powerpc/vsx-vector-6.p7.c: Fix xxlnor BE expected count.
Add -dp to dg-options, update expected counts.
---
 gcc/testsuite/gcc.target/powerpc/altivec-7.c   | 16 
 gcc/testsuite/gcc.target/powerpc/builtins-1.c  | 18 ++---
 gcc/testsuite/gcc.target/powerpc/builtins-4.c  |  5 +--
 gcc/testsuite/gcc.target/powerpc/builtins-5.c  | 44 ++
 gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c | 14 +++
 5 files changed, 65 insertions(+), 32 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-5.c

diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-7.c 
b/gcc/testsuite/gcc.target/powerpc/altivec-7.c
index b61092c..8d8559b 100644
--- a/gcc/testsuite/gcc.target/powerpc/altivec-7.c
+++ b/gcc/testsuite/gcc.target/powerpc/altivec-7.c
@@ -73,8 +73,8 @@ int main ()
  vec_unpacklvupkhsh
  vec_unpacklvupkhpx
  vec_unpacklvupkhsb
- vec_andc   xxnor
-xxland
+ vec_andc   xxlnor (vnor AIX)
+xxland (vand AIX)
  vec_vxor   xxlxor
  vec_vmsumubm   vmsumubm
  vec_vmulesbvmulosb
@@ -85,17 +85,17 @@ int main ()
 /* { dg-final { scan-assembler-times "vpkpx" 2 } } */
 /* { dg-final { scan-assembler-times "vmulesb" 1 } } */
 /* { dg-final { scan-assembler-times "vmulosb" 1 } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M} 42 { target le } } } 
*/
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M} 4 { target be } } } 
*/
+/* { dg-final { scan-assembler-times {\mlvx\M} 0 { target { powerpc*-*-linux* 
} } } } */
+/* { dg-final { scan-assembler-times {\mlvx\M} 42 { target { powerpc*-*-aix* } 
} } } */
 /* { dg-final { scan-assembler-times "lvewx" 2 } } */
 /* { dg-final { scan-assembler-times "lvxl" 1 } } */
 /* { dg-final { scan-assembler-times "vupklsh" 2 } } */
 /* { dg-final { scan-assembler-times "vupkhsh" 2 } } */
-/* { dg-final { scan-assembler-times "xxlnor" 4 } } */
-/* { dg-final { scan-assembler-times "xxland" 4 } } */
-/* { dg-final { scan-assembler-times "xxlxor" 5 } } */
+/* { dg-final { scan-assembler-times {\mxxlnor\M|\mvnor\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mxxland\M|\mvand\M} 4 } } */
+/* { dg-final { scan-assembler-times "xxlxor" 5 { target { powerpc*-*-linux* } 
} } } */
+/* { dg-final { scan-assembler-times "xxlxor" 0 { target { powerpc*-*-aix* } } 
} } */
 /* { dg-final { scan-assembler-times "xxlandc" 0 } } */
-/* { dg-final { scan-assembler-times "lvx" 1 } } */
 /* { dg-final { scan-assembler-times "vmsumubm" 1 } } */
 /* { dg-final { scan-assembler-times "vupklpx" 1 } } */
 /* { dg-final { scan-assembler-times "vupklsx" 0 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1.c 
b/gcc/testsuite/gcc.target/powerpc/builtins-1.c
index 45727b9..0492bf6 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-1.c
@@ -81,14 +81,6 @@ int main ()
   vector unsigned long long uq = vec_nor (ua, ud);
   vector unsigned long long ur = vec_nor (ud, ua);
 
-  vector long long ls = vec_or (la, lb);
-  vector long long lt = vec_or (la, ld);
-  vector long long lu = vec_or (ld, la);
-
-  vector unsigned long long us = vec_or (ua, ub);
-

PATCH to fix ICE with -Wint-conversion (PR middle-end/86202)

2018-06-18 Thread Marek Polacek

This patch improves the checks in size_must_be_zero_p so that we don't
call get_range_info with SIZE of a pointer type.

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

2018-06-18  Marek Polacek  

PR middle-end/86202
* gimple-fold.c (size_must_be_zero_p): Check the type of the size.

* gcc.dg/Wint-conversion-2.c: New test.

diff --git gcc/gimple-fold.c gcc/gimple-fold.c
index a01bce7ab08..e97e8c74308 100644
--- gcc/gimple-fold.c
+++ gcc/gimple-fold.c
@@ -646,7 +646,7 @@ size_must_be_zero_p (tree size)
   if (integer_zerop (size))
 return true;
 
-  if (TREE_CODE (size) != SSA_NAME)
+  if (TREE_CODE (size) != SSA_NAME || !INTEGRAL_TYPE_P (TREE_TYPE (size)))
 return false;
 
   wide_int min, max;
diff --git gcc/testsuite/gcc.dg/Wint-conversion-2.c 
gcc/testsuite/gcc.dg/Wint-conversion-2.c
index e69de29bb2d..0c9dac44c41 100644
--- gcc/testsuite/gcc.dg/Wint-conversion-2.c
+++ gcc/testsuite/gcc.dg/Wint-conversion-2.c
@@ -0,0 +1,11 @@
+/* PR middle-end/86202 */
+/* { dg-do compile } */
+/* { dg-options "-Wint-conversion" } */
+
+void *memcpy (void *, void *, __SIZE_TYPE__ *);
+void *a, *b;
+void f (void)
+{
+  long unsigned int c = 0;
+  memcpy (a, b, c); /* { dg-warning "passing argument" } */
+}

Marek

Re: [PATCH] PR libstdc++/78870 support std::filesystem on Windows

2018-06-18 Thread Christophe Lyon

On Mon, 18 Jun 2018 at 18:01, Jonathan Wakely  wrote:
>
> On 16/06/18 20:56 -0600, Sandra Loosemore wrote:
> >On 06/16/2018 05:05 PM, Jonathan Wakely wrote:
> >>Oops, that message got bounced from the lists and was the wrong
> >>version of the patch anyway - this is the one I meant to attach.
> >>
> >>On Sun, 17 Jun 2018 at 00:00, Jonathan Wakely  wrote:
> >>>
> >>>Here's what I wanted to test, which removes the new AC_CHECK_FUNCS 
> >>>(replacing them with GLIBCXX_COMPILE_OR_LINK tests that shouldn't even get 
> >>>run on bare metal ).
> >
> >This patch worked for me, or at least I got successful builds now.
> >I'm testing the new C-SKY port and built both csky-elf and
> >csky-linux-gnu. (I expect to be submitting the port within the next
> >few weeks.)
>
> Here's what I've committed (it's the same apart from some comments and
> re-indenting).
>
> Tested x86_64-linux and powerpc64le-linux, committed to trunk.
>
>
Thanks! It does fix the aarch64 bare-metal builds (arm-none-eabi was
not affected)

[PATCH] LWG 2975 ensure construct(pair*, ...) used to construct pairs


* include/std/scoped_allocator (__not_pair): Define SFINAE helper.
(construct(_Tp*, _Args&&...)): Remove from overload set when _Tp is
a specialization of std::pair.
* testsuite/20_util/scoped_allocator/construct_pair.cc: Ensure
pair elements are constructed correctly.

Tested powerpc64le-linux, committed to trunk.


commit d0d30a98189f840f1132a2ce02bc26fe8da570d6
Author: Jonathan Wakely 
Date:   Mon Jun 18 20:36:49 2018 +0100

LWG 2975 ensure construct(pair*, ...) used to construct pairs

* include/std/scoped_allocator (__not_pair): Define SFINAE helper.
(construct(_Tp*, _Args&&...)): Remove from overload set when _Tp is
a specialization of std::pair.
* testsuite/20_util/scoped_allocator/construct_pair.cc: Ensure
pair elements are constructed correctly.

diff --git a/libstdc++-v3/include/std/scoped_allocator 
b/libstdc++-v3/include/std/scoped_allocator
index 195db397ac9..ea62f113517 100644
--- a/libstdc++-v3/include/std/scoped_allocator
+++ b/libstdc++-v3/include/std/scoped_allocator
@@ -241,6 +241,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 is_constructible<_OuterAlloc, _Alloc>::value
   >::type;
 
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 2975. Missing case for pair construction in scoped [...] allocators
+  template
+   struct __not_pair { using type = void; };
+
+  template
+   struct __not_pair> { };
+
 public:
   typedef _OuterAlloc   outer_allocator_type;
   typedef typename __inner_type::__type inner_allocator_type;
@@ -348,13 +356,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return __traits::max_size(outer_allocator()); }
 
   template
-void construct(_Tp* __p, _Args&&... __args)
-{
-  auto& __inner = inner_allocator();
-  auto __use_tag
-= __use_alloc<_Tp, inner_allocator_type, _Args...>(__inner);
-  _M_construct(__use_tag, __p, std::forward<_Args>(__args)...);
-}
+   typename __not_pair<_Tp>::type
+   construct(_Tp* __p, _Args&&... __args)
+   {
+ auto& __inner = inner_allocator();
+ auto __use_tag
+   = __use_alloc<_Tp, inner_allocator_type, _Args...>(__inner);
+ _M_construct(__use_tag, __p, std::forward<_Args>(__args)...);
+   }
 
   template
diff --git a/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair.cc 
b/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair.cc
index 341328e487f..b34efc88798 100644
--- a/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair.cc
+++ b/libstdc++-v3/testsuite/20_util/scoped_allocator/construct_pair.cc
@@ -73,9 +73,37 @@ test03()
   a.deallocate(ptr, 1);
 }
 
+void
+test04()
+{
+  struct X
+  {
+using allocator_type = std::allocator;
+X() = default;
+X(const X&) { throw 1; }
+X(const X&, const allocator_type&) { }
+  };
+
+  struct Y
+  {
+using allocator_type = std::allocator;
+Y() = default;
+Y(const Y&) = delete;
+Y(std::allocator_arg_t, const allocator_type&, const Y&) { }
+  };
+
+  using pair_type = std::pair;
+  std::scoped_allocator_adaptor> a;
+  auto ptr = a.allocate(1);
+  /* not const */ pair_type p;
+  a.construct(ptr, p); // LWG 2975
+  a.deallocate(ptr, 1);
+}
+
 int main()
 {
   test01();
   test02();
   test03();
+  test04();
 }

Re: [PATCH applied], 3 PowerPC long double patches applied

On Mon, 18 Jun 2018, Michael Meissner wrote:

> In terms of the tests, the following tests fail if you switch the default long
> double format.

Also, having done a test build: various *tf* and *tc* libgcc functions end 
up getting built incorrectly (to use IEEE long double when the ABIs for 
those functions are supposed to use IBM long double) if you switch the 
default long double format.  This affects at least __multc3 __divtc3 
__powitf2 __fix{,uns}tf{di,ti} __float{,un}{di,ti}tf.

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

Re: [PATCH applied], 3 PowerPC long double patches applied

On Mon, Jun 18, 2018 at 07:40:46PM +, Joseph Myers wrote:
> On Mon, 18 Jun 2018, Michael Meissner wrote:
> 
> > gcc.target/powerpc/pr70117.c(bug in isnormal on 
> > IEEE 128)
> 
> Doesn't look like a bug in isnormal to me.  That test is explicitly using 
> an IBM long double representation and can't possibly be expected to work 
> with IEEE long double - either it needs to be disabled for IEEE long 
> double, or to use -mabi=ibmlongdouble explicitly, or to use __ibm128 (but 
> if you use __ibm128 you can't then test the type-specific __builtin_isinfl 
> like it does at present).

I've fixed the test to use __ibm128 already in my branch.  The issue is the
compiler generates different code for __ibm128 (when long double is IEEE
128-bit) than it does for long double using IBM extended double.  The code
fails for __ibm128, but does not fail normally.

I haven't fully investigated why the code is different.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH applied], 3 PowerPC long double patches applied

On Mon, 18 Jun 2018, Michael Meissner wrote:

> gcc.target/powerpc/pr70117.c  (bug in isnormal on IEEE 128)

Doesn't look like a bug in isnormal to me.  That test is explicitly using 
an IBM long double representation and can't possibly be expected to work 
with IEEE long double - either it needs to be disabled for IEEE long 
double, or to use -mabi=ibmlongdouble explicitly, or to use __ibm128 (but 
if you use __ibm128 you can't then test the type-specific __builtin_isinfl 
like it does at present).

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

[PATCH applied], 3 PowerPC long double patches applied

This is just the combined patch of the last three patches that have been
approved for trunk.  I expanded the description in rs6000-modes.def of what the
3 128-bit floating point types are and why IFmode needs to be ordered above
KFmode and TFmode.

These patches were individually proposed in:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00634.html
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00796.html
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00799.html

In terms of the tests, the following tests fail if you switch the default long
double format.  At the moment, I don't have the GLIBC that provides native
support for IEEE 128-bit long double:

C tests:
c-c++-common/dfp/cast.c (_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-11.c   (_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-2.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-3.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-4.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-5.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-6.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp.c  (_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/pr39034.c  (_Decimal128 <-> IEEE 128-bit)
gcc.dg/nextafter-2.c(needs updated GLIBC)
gcc.dg/torture/float128-nan.c   (I need to investigate this)
gcc.dg/tree-ssa/builtin-sprintf.c   (needs updated GLIBC)
gcc.dg/tree-ssa/vrp104.c(I need to investigate this)
gcc.target/powerpc/clone1.c (I have patches for this)
gcc.target/powerpc/clone2.c (I have patches for this)
gcc.target/powerpc/divkc3-1.c   (I have patches for this)
gcc.target/powerpc/float128-3.c (I have patches for this)
gcc.target/powerpc/float128-5.c (I have patches for this)
gcc.target/powerpc/float128-complex-1.c (I have patches for this)
gcc.target/powerpc/float128-mix.c   (I have patches for this)
gcc.target/powerpc/mulkc3-1.c   (I have patches for this)
gcc.target/powerpc/nan128-1.c   (I need to investigate this)
gcc.target/powerpc/pack02.c (I have patches for this)
gcc.target/powerpc/pr57150.c(I have patches for this)
gcc.target/powerpc/pr60203.c(I have patches for this)
gcc.target/powerpc/pr67808.c(I have patches for this)
gcc.target/powerpc/pr70117.c(bug in isnormal on IEEE 128)
gcc.target/powerpc/pr78056-1.c  (I have patches for this)
gcc.target/powerpc/pr78056-3.c  (I have patches for this)
gcc.target/powerpc/pr80210-2.c  (I have patches for this)
gcc.target/powerpc/pr80210.c(I have patches for this)
gcc.target/powerpc/pr85657-3.c  (I have patches for this)
gcc.target/powerpc/tfmode_off.c (I have patches for this)

C++ tests:
c-c++-common/dfp/cast.c (_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-11.c   (_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-2.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-3.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-4.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-5.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp-6.c(_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/convert-bfp.c  (_Decimal128 <-> IEEE 128-bit)
c-c++-common/dfp/pr39034.c  (_Decimal128 <-> IEEE 128-bit)
g++.dg/cdce3.C  (needs updated GLIBC) 

The following Fortran tests fail.  I assume most of these are library issues:
gfortran.dg/erf_3.F90
gfortran.dg/fmt_en.f90
gfortran.dg/fmt_g0_7.f08
gfortran.dg/fmt_pf.f90
gfortran.dg/ieee/large_1.f90
gfortran.dg/ieee/large_3.F90
gfortran.dg/large_real_kind_1.f90
gfortran.dg/large_real_kind_2.F90
gfortran.dg/large_real_kind_3.F90
gfortran.dg/large_real_kind_form_io_1.f90
gfortran.dg/large_real_kind_form_io_2.f90
gfortran.dg/norm2_3.f90
gfortran.dg/quad_2.f90
gfortran.dg/round_2.f03

[gcc]
2018-06-18  Michael Meissner  

PR target/85358
* config/rs6000/rs6000-modes.def (toplevel): Rework the 128-bit
floating point modes, so that IFmode is numerically greater than
TFmode, which is greater than KFmode using FRACTIONAL_FLOAT_MODE
to declare the ordering.  This prevents IFmode from being
converted to TFmode when long double is IEEE 128-bit on an ISA 3.0
machine.  Include rs6000-modes.h to share the fractional values
between genmodes* and the rest of the compiler.

Re: [PATCH v2] C/C++: Add -Waddress-of-packed-member

On Mon, 18 Jun 2018, Jason Merrill wrote:

> On Mon, Jun 18, 2018 at 11:59 AM, Joseph Myers  
> wrote:
> > On Mon, 18 Jun 2018, Jason Merrill wrote:
> >
> >> > +  if (TREE_CODE (rhs) == COND_EXPR)
> >> > +{
> >> > +  /* Check the THEN path first.  */
> >> > +  tree op1 = TREE_OPERAND (rhs, 1);
> >> > +  context = check_address_of_packed_member (type, op1);
> >>
> >> This should handle the GNU extension of re-using operand 0 if operand
> >> 1 is omitted.
> >
> > Doesn't that just use a SAVE_EXPR?
> 
> Hmm, I suppose it does, but many places in the compiler seem to expect
> that it produces a COND_EXPR with TREE_OPERAND 1 as NULL_TREE.

Maybe that's used somewhere inside the C++ front end.  For C a SAVE_EXPR 
is produced directly.

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

[PATCH] avoid using strnlen result for late calls to strlen (PR 82604)


While looking into opportunities to detect strnlen/strlen coding
mistakes (pr86199) I noticed a bug in the strnlen implementation
I committed earlier today that lets a strnlen() result be saved
and used in subsequent calls to strlen() with the same argument.
The attached patch changes the handle_builtin_strlen() function
to discard the strnlen() result unless its bound is greater than
the length of the string.

Martin
PR tree-optimization/86204 -  wrong strlen result after prior strnlen

gcc/ChangeLog:

	PR tree-optimization/86204
	* tree-ssa-strlen.c (handle_builtin_strlen): Avoid storing
	a strnlen result if it's less than the length of the string.

gcc/testsuite/ChangeLog:

	PR tree-optimization/86204
	* gcc.dg/strlenopt-46.c: New test.

Index: gcc/testsuite/gcc.dg/strlenopt-46.c
===
--- gcc/testsuite/gcc.dg/strlenopt-46.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/strlenopt-46.c	(working copy)
@@ -0,0 +1,131 @@
+/* PR tree-optimization/86204 - wrong strlen result after prior strnlen
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+#include "strlenopt.h"
+
+#define NOIPA   __attribute__ ((noipa))
+
+char a[] = "12345";
+
+NOIPA void f0 (void)
+{
+  unsigned n0 = strnlen (a, 0);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 0 || n1 != 5)
+abort ();
+}
+
+NOIPA void f1 (void)
+{
+  unsigned n0 = strnlen (a, 1);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 1 || n1 != 5)
+abort ();
+}
+
+NOIPA void f2 (void)
+{
+  unsigned n0 = strnlen (a, 2);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 2 || n1 != 5)
+abort ();
+}
+
+NOIPA void f3 (void)
+{
+  unsigned n0 = strnlen (a, 3);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 3 || n1 != 5)
+abort ();
+}
+
+NOIPA void f4 (void)
+{
+  unsigned n0 = strnlen (a, 4);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 4 || n1 != 5)
+abort ();
+}
+
+NOIPA void f5 (void)
+{
+  unsigned n0 = strnlen (a, 5);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 5 || n1 != 5)
+abort ();
+}
+
+NOIPA void f6 (void)
+{
+  unsigned n0 = strnlen (a, 6);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 5 || n1 != 5)
+abort ();
+}
+
+NOIPA void fx (unsigned n)
+{
+  unsigned n0 = strnlen (a, n);
+  unsigned n1 = strlen (a);
+
+  unsigned min = n < 5 ? n : 5;
+  if (n0 != min || n1 != 5)
+abort ();
+}
+
+NOIPA void g2 (void)
+{
+  strcpy (a, "123");
+  unsigned n0 = strnlen (a, 2);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 2 || n1 != 3)
+abort ();
+}
+
+NOIPA void g7 (void)
+{
+  strcpy (a, "123");
+  unsigned n0 = strnlen (a, 7);
+  unsigned n1 = strlen (a);
+
+  if (n0 != 3 || n1 != 3)
+abort ();
+}
+
+NOIPA void gx (unsigned n)
+{
+  strcpy (a, "123");
+  unsigned n0 = strnlen (a, n);
+  unsigned n1 = strlen (a);
+
+  unsigned min = n < 3 ? n : 3;
+  if (n0 != min || n1 != 3)
+abort ();
+}
+
+int main (void)
+{
+  f0 ();
+  f1 ();
+  f2 ();
+  f3 ();
+  f4 ();
+  f5 ();
+  f6 ();
+  fx (2);
+  fx (7);
+
+  g2 ();
+  g7 ();
+  gx (2);
+  gx (7);
+}
Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 261705)
+++ gcc/tree-ssa-strlen.c	(working copy)
@@ -1270,8 +1270,19 @@ handle_builtin_strlen (gimple_stmt_iterator *gsi)
 	  rhs = unshare_expr (rhs);
 	  if (!useless_type_conversion_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
 	rhs = fold_convert_loc (loc, TREE_TYPE (lhs), rhs);
+
+	  bool bounded = false;
 	  if (bound)
-	rhs = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (rhs), rhs, bound);
+	{
+	  tree new_rhs
+		= fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (rhs), rhs, bound);
+
+	  bounded = (TREE_CODE (new_rhs) != INTEGER_CST
+			 || tree_int_cst_lt (new_rhs, rhs));
+
+	  rhs = new_rhs;
+	}
+
 	  if (!update_call_from_tree (gsi, rhs))
 	gimplify_and_update_call_from_tree (gsi, rhs);
 	  stmt = gsi_stmt (*gsi);
@@ -1281,6 +1292,11 @@ handle_builtin_strlen (gimple_stmt_iterator *gsi)
 	  fprintf (dump_file, "into: ");
 	  print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
 	}
+
+	  /* Avoid storing the length for calls to strnlen().  */
+	  if (bounded)
+	return;
+
 	  if (si != NULL
 	  && TREE_CODE (si->nonzero_chars) != SSA_NAME
 	  && TREE_CODE (si->nonzero_chars) != INTEGER_CST
@@ -1299,6 +1315,7 @@ handle_builtin_strlen (gimple_stmt_iterator *gsi)
 }
   if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
 return;
+
   if (idx == 0)
 idx = new_stridx (src);
   else
@@ -1333,9 +1350,14 @@ handle_builtin_strlen (gimple_stmt_iterator *gsi)
 }
   if (idx)
 {
-  strinfo *si = new_strinfo (src, idx, lhs, true);
-  set_strinfo (idx, si);
-  find_equal_ptrs (src, idx);
+  if (!bound)
+	{
+	  /* Only store the new length information for calls to strlen(),
+	 not for those to strnlen().  */
+	  strinfo *si = new_strinfo (src, idx, lhs, true);
+	  set_strinfo (idx, si);
+	  find_equal_ptrs (src, idx);
+	}
 
   /* For SRC that is an array

Re: [PATCH 2/8] Introduce VECT_SCOPE macro

2018-06-18 Thread David Malcolm

On Fri, 2018-06-15 at 14:11 -0600, Jeff Law wrote:
> On 06/14/2018 02:32 PM, David Malcolm wrote:
> > The vectorizer code has numerous instances of:
> > 
> >   if (dump_enabled_p ())
> > dump_printf_loc (MSG_NOTE, vect_location,
> >  "=== some message ===\n");
> > 
> > In each case, the dump_printf_loc is a MSG_NODE at vect_location.
> > 
> > In almost all cases the message is of the form
> >   "=== foo ===\n"
> > 
> > The exceptions are:
> >   "= analyze_loop_nest =\n"
> > which uses 4 equal signs rather than 3, and
> >   "===vect_slp_analyze_bb===\n"
> > which is missing the spaces.
> > 
> > In most cases (but not always) the message matches the function
> > name.
> > 
> > This patch replaces all of these with a macro, taking the message
> > as an argument (and forcing the use of three dashes and a space).
> > 
> > The idea is to later convert this macro to use an RAII type
> > that pushes and pops scope, so that the nesting structure appears
> > in the dumpfile and -fopt-info logs (and in the remarks and
> > optimization records introduced later in this patch kit).
> > 
> > The message is usually the function name, but not always.
> > Should I split this out into two macros? e.g. a VECT_FUNCTION_SCOPE
> > that uses __FUNCTION__?
> > 
> > Would DUMP_VECT_SCOPE be a better name, perhaps?
> > 
> > gcc/ChangeLog:
> > * tree-vect-data-refs.c (vect_analyze_data_ref_dependences):
> > Replace dump_printf_loc call with VECT_SCOPE.
> > (vect_slp_analyze_instance_dependence): Likewise.
> > (vect_enhance_data_refs_alignment): Likewise.
> > (vect_analyze_data_refs_alignment): Likewise.
> > (vect_slp_analyze_and_verify_instance_alignment
> > (vect_analyze_data_ref_accesses): Likewise.
> > (vect_prune_runtime_alias_test_list): Likewise.
> > (vect_analyze_data_refs): Likewise.
> > * tree-vect-loop-manip.c (vect_update_inits_of_drs): Likewise.
> > * tree-vect-loop.c (vect_determine_vectorization_factor):
> > Likewise.
> > (vect_analyze_scalar_cycles_1): Likewise.
> > (vect_get_loop_niters): Likewise.
> > (vect_analyze_loop_form_1): Likewise.
> > (vect_update_vf_for_slp): Likewise.
> > (vect_analyze_loop_operations): Likewise.
> > (vect_analyze_loop): Likewise.
> > (vectorizable_induction): Likewise.
> > (vect_transform_loop): Likewise.
> > * tree-vect-patterns.c (vect_pattern_recog): Likewise.
> > * tree-vect-slp.c (vect_analyze_slp): Likewise.
> > (vect_make_slp_decision): Likewise.
> > (vect_detect_hybrid_slp): Likewise.
> > (vect_slp_analyze_operations): Likewise.
> > (vect_slp_bb): Likewise.
> > * tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized):
> > Likewise.
> > (vectorizable_bswap): Likewise.
> > (vectorizable_call): Likewise.
> > (vectorizable_simd_clone_call): Likewise.
> > (vectorizable_conversion): Likewise.
> > (vectorizable_assignment): Likewise.
> > (vectorizable_shift): Likewise.
> > (vectorizable_operation): Likewise.
> > * tree-vectorizer.h (VECT_SCOPE): New macro.
> 
> OK.  But rather than using a macro, *consider* just using a normal
> function.  I'm less and less inclined to use macros as I get older :-
> )
> 
> If there's a solid reason to use a macro, then that's fine.

The reason for doing it as a macro is that I'm planning to turn this
into an RAII-style class for pushing and popping scopes, capturing the
nesting.  That wouldn't work if it was a function.

> DUMP_VECT_SCOPE seems better than VEC_SCOPE.

Thanks.  I've committed the DUMP_VECT_SCOPE version of the patch as
r261710 (after usual testing)

Dave

Re: [PATCH], PowerPC long double transistion, patch #2

On Fri, Jun 15, 2018 at 04:00:42PM -0500, Segher Boessenkool wrote:
> On Thu, Jun 14, 2018 at 08:15:51PM -0400, Michael Meissner wrote:
> > On Thu, Jun 14, 2018 at 07:00:52PM -0500, Segher Boessenkool wrote:
> > > Hi Mike,
> > > 
> > > On Wed, Jun 13, 2018 at 05:16:37PM -0400, Michael Meissner wrote:
> > > > This fixes some of the PowerPC tests that had implicit assumptions 
> > > > about the
> > > > long double format.  The fixes involved:
> > > > 
> > > > 1)  Using long double __complex instead of using a KC attribute;
> > > 
> > > Why?  Does KC not work?  It should work.
> > 
> > No KC does not work if long double is IEEE, just like IC does not work if 
> > long
> > double is IBM extended double.  This is part of the __float128/__ibm128 
> > changes
> > that eliminated using separate types all of the time.
> 
> But those aren't types, those are modes.  Why would the modes not work?
> That makes no sense.  Just like the __ieee128 and __ibm128 types work
> always, so should the IF, KF, IC and KC modes.
> 
> So what happens if you try to use KC?

The problem is the infrastructure of the compiler.  The type and builtin system
really, really does not like having the same external name for a library
function.  So if you have a type that uses KFmode and the function resolved to
"__addkf3", and you have another type that uses TFmode, and it too resolves to
"__addkf3" you get an internal error.  Ditto for the name mangling.

So we have to make sure that there are really only two modes being used.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[PATCH] LWG 2989 hide path iostream operators from normal lookup


By only defining these operators as friends (with no namespace-scope
declaration) they can only be found by ADL and do not participate in
overload resolution for arguments of types other than path.

LWG 2989 hide path iostream operators from normal lookup
* include/bits/fs_path.h (operator<<, operator>>): Define inline as
friends.
* testsuite/27_io/filesystem/path/io/dr2989.cc: New.

Tested powerpc64le-linux, commmitted to trunk.


commit 51827611e8aa67b983664bf566d8947bf9a4359a
Author: Jonathan Wakely 
Date:   Mon Jun 18 19:07:16 2018 +0100

LWG 2989 hide path iostream operators from normal lookup

By only defining these operators as friends (with no namespace-scope
declaration) they can only be found by ADL and do not participate in
overload resolution for arguments of types other than path.

LWG 2989 hide path iostream operators from normal lookup
* include/bits/fs_path.h (operator<<, operator>>): Define inline as
friends.
* testsuite/27_io/filesystem/path/io/dr2989.cc: New.

diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index 6eab800ac56..e3938d06d59 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -363,6 +363,26 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 iterator begin() const;
 iterator end() const;
 
+/// Write a path to a stream
+template
+  friend std::basic_ostream<_CharT, _Traits>&
+  operator<<(std::basic_ostream<_CharT, _Traits>& __os, const path& __p)
+  {
+   __os << std::quoted(__p.string<_CharT, _Traits>());
+   return __os;
+  }
+
+/// Read a path from a stream
+template
+  friend std::basic_istream<_CharT, _Traits>&
+  operator>>(std::basic_istream<_CharT, _Traits>& __is, path& __p)
+  {
+   std::basic_string<_CharT, _Traits> __tmp;
+   if (__is >> std::quoted(__tmp))
+ __p = std::move(__tmp);
+   return __is;
+  }
+
 // Create a basic_string by reading until a null character.
 template,
@@ -505,26 +525,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 return __result;
   }
 
-  /// Write a path to a stream
-  template
-basic_ostream<_CharT, _Traits>&
-operator<<(basic_ostream<_CharT, _Traits>& __os, const path& __p)
-{
-  __os << std::quoted(__p.string<_CharT, _Traits>());
-  return __os;
-}
-
-  /// Read a path from a stream
-  template
-basic_istream<_CharT, _Traits>&
-operator>>(basic_istream<_CharT, _Traits>& __is, path& __p)
-{
-  basic_string<_CharT, _Traits> __tmp;
-  if (__is >> std::quoted(__tmp))
-   __p = std::move(__tmp);
-  return __is;
-}
-
   template
 inline auto
 u8path(_InputIterator __first, _InputIterator __last)
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/io/dr2989.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/io/dr2989.cc
new file mode 100644
index 000..b9a1235e1fe
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/io/dr2989.cc
@@ -0,0 +1,35 @@
+// Copyright (C) 2018 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++17" }
+// { dg-do compile { target c++17 } }
+
+#include 
+#include 
+
+using namespace std::filesystem;
+
+struct P {
+  operator path&();
+};
+
+void foo(std::iostream& s) {
+  P p;
+  s << p; // { dg-error "no match" }
+  s >> p; // { dg-error "no match" }
+}
+// { dg-prune-output "no type .* std::enable_if" }

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

2018-06-18 Thread Dimitar Dimitrov

On сряда, 13 юни 2018 г. 19:44:16 EEST Joseph Myers wrote:
> On Wed, 13 Jun 2018, Dimitar Dimitrov wrote:
> > +  error ("__delay_cycles() only takes constant arguments");
> 
> As in documentation, diagnostics should not use () to indicate that a name
> refers to a function (as opposed to referring to a call with no
> arguments).  However, function names, option names and any other literal
> source code text in diagnostics, both this and other diagnostics in the
> port, should be enclosed in %< and %> to quote them in the diagnostic
> output.
> 
> > + error ("__delay_cycles only takes non-negative cycle counts.");
> > 
> > + error ("__delay_cycles is limited to 32-bit loop counts.");
> 
> No '.' at end of diagnostics (and use %<__delay_cycles%>, as above).

Thank you for the prompt review. I'll fix and resend patch v2.

Regards,
Dimitar

[PATCH][PR other/86198] Libacktrace and ".note.gnu.build-id" section.

2018-06-18 Thread Denis Khalikov

Hello,
this is a patch for PR other/86198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198
Thanks.
From: Denis Khalikov 
Date: Mon, 18 Jun 2018 20:46:39 +0300
Subject: [PATCH] PR other/86198

* elf.c (elf_add): Increase ".note.gnu.build-id" section size
checking up to 36 bytes.
---
 libbacktrace/ChangeLog | 6 ++
 libbacktrace/elf.c | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/libbacktrace/ChangeLog b/libbacktrace/ChangeLog
index c01c7d8..2cc31bf 100644
--- a/libbacktrace/ChangeLog
+++ b/libbacktrace/ChangeLog
@@ -1,3 +1,9 @@
+2018-06-18 Denis Khalikov 
+
+	PR other/86198
+	* elf.c (elf_add): Increase ".note.gnu.build-id" section size
+	checking up to 36 bytes.
+
 2018-04-24  H.J. Lu  
 
 	* configure: Regenerated.
diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
index 0fd5e6f..f4863f0 100644
--- a/libbacktrace/elf.c
+++ b/libbacktrace/elf.c
@@ -2868,7 +2868,7 @@ elf_add (struct backtrace_state *state, const char *filename, int descriptor,
 	  if (note->type == NT_GNU_BUILD_ID
 	  && note->namesz == 4
 	  && strncmp (note->name, "GNU", 4) == 0
-	  && shdr->sh_size < 12 + ((note->namesz + 3) & ~ 3) + note->descsz)
+	  && shdr->sh_size <= 12 + ((note->namesz + 3) & ~ 3) + note->descsz)
 	{
 	  buildid_data = >name[0] + ((note->namesz + 3) & ~ 3);
 	  buildid_size = note->descsz;
-- 
1.9.1

C++ PATCH for c++/86171, ICE with recursive alias instantiation

Here, instantiating B requires instantiating A, which
requires instantiating B.  Previously, that resulted in
creating two separate TYPE_DECLS for B and trying to combine
them in register_specialization.  Better, I think, to check for this
situation sooner.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit f82ab957170984838b0bf4d9f7ef5d254eec28c3
Author: Jason Merrill 
Date:   Mon Jun 18 11:53:39 2018 -0400

PR c++/86171 - ICE with recursive alias instantiation.

* pt.c (tsubst_decl): Handle recursive alias instantiation.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4ee84b201e9..6e590d4d342 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13639,7 +13639,6 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
 	  }
 
 	/* Create a new node for the specialization we need.  */
-	r = copy_decl (t);
 	if (type == NULL_TREE)
 	  {
 	if (is_typedef_decl (t))
@@ -13664,7 +13663,16 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
 		  sub_args = strip_innermost_template_args (args, extra);
 	  }
 	type = tsubst (type, sub_args, complain, in_decl);
+	/* Substituting the type might have recursively instantiated this
+	   same alias (c++/86171).  */
+	if (gen_tmpl && DECL_ALIAS_TEMPLATE_P (gen_tmpl)
+		&& (spec = retrieve_specialization (gen_tmpl, argvec, hash)))
+	  {
+		r = spec;
+		break;
+	  }
 	  }
+	r = copy_decl (t);
 	if (VAR_P (r))
 	  {
 	DECL_INITIALIZED_P (r) = 0;
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-65.C b/gcc/testsuite/g++.dg/cpp0x/alias-decl-65.C
new file mode 100644
index 000..e320f3eedd0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-65.C
@@ -0,0 +1,10 @@
+// PR c++/86171
+// { dg-do compile { target c++11 } }
+
+template  struct A;
+template  using B = typename A::X;
+template  struct A {
+  typedef int X;
+  typedef B U;
+};
+B b;

Re: [PATCH v2] C/C++: Add -Waddress-of-packed-member

On Mon, Jun 18, 2018 at 11:59 AM, Joseph Myers  wrote:
> On Mon, 18 Jun 2018, Jason Merrill wrote:
>
>> > +  if (TREE_CODE (rhs) == COND_EXPR)
>> > +{
>> > +  /* Check the THEN path first.  */
>> > +  tree op1 = TREE_OPERAND (rhs, 1);
>> > +  context = check_address_of_packed_member (type, op1);
>>
>> This should handle the GNU extension of re-using operand 0 if operand
>> 1 is omitted.
>
> Doesn't that just use a SAVE_EXPR?

Hmm, I suppose it does, but many places in the compiler seem to expect
that it produces a COND_EXPR with TREE_OPERAND 1 as NULL_TREE.
Perhaps that code is obsolete.  Never mind it here, then.

Jason

[PATCH] LWG 3050 Fix cv-qualification of convertibility constraints


This issue hasn't been voted into the working draft yet, but it's been
approved by LWG and is obviously correct.

* include/std/chrono (duration, operator*, operator/, operator%): Use
const-qualified type as source type in is_convertible constraints.
* testsuite/20_util/duration/arithmetic/dr3050.cc: New.
* testsuite/20_util/duration/cons/dr3050.cc: New.
* testsuite/20_util/duration/literals/range.cc: Rename to...
* testsuite/20_util/duration/literals/range_neg.cc: Here. Adjust
dg-error lineno.

Tested powerpc64le-linux, committed to trunk.


commit c34782c185f06d10d64625e64ea70dd9819de10c
Author: Jonathan Wakely 
Date:   Mon Jun 18 17:56:11 2018 +0100

LWG 3050 Fix cv-qualification of convertibility constraints

LWG 3050 Fix cv-qualification of convertibility constraints
* include/std/chrono (duration, operator*, operator/, operator%): 
Use
const-qualified type as source type in is_convertible constraints.
* testsuite/20_util/duration/arithmetic/dr3050.cc: New.
* testsuite/20_util/duration/cons/dr3050.cc: New.
* testsuite/20_util/duration/literals/range.cc: Rename to...
* testsuite/20_util/duration/literals/range_neg.cc: Here. Adjust
dg-error lineno.

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index b3a0cb2087d..d6d9dcae411 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -325,8 +325,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
duration(const duration&) = default;
 
+   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+   // 3050. Conversion specification problem in chrono::duration
template,
+is_convertible,
 __or_<__is_float, __not_<__is_float<_Rep2>
  constexpr explicit duration(const _Rep2& __rep)
  : __r(static_cast(__rep)) { }
@@ -471,10 +473,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 // SFINAE helper to obtain common_type<_Rep1, _Rep2> only if _Rep2
 // is implicitly convertible to it.
+// _GLIBCXX_RESOLVE_LIB_DEFECTS
+// 3050. Conversion specification problem in chrono::duration constructor
 template::type>
-  using __common_rep_t
-   = typename enable_if::value, _CRep>::type;
+  using __common_rep_t = typename
+   enable_if::value, _CRep>::type;
 
 template
   constexpr duration<__common_rep_t<_Rep1, _Rep2>, _Period>
diff --git a/libstdc++-v3/testsuite/20_util/duration/cons/dr3050.cc 
b/libstdc++-v3/testsuite/20_util/duration/cons/dr3050.cc
new file mode 100644
index 000..a4f57a38c30
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/duration/cons/dr3050.cc
@@ -0,0 +1,24 @@
+// 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 compile { target c++11 } }
+
+#include 
+
+struct X { operator int64_t() /* not const */; };
+static_assert(!std::is_constructible::value,
+ "LWG 3050");
diff --git a/libstdc++-v3/testsuite/20_util/duration/literals/range.cc 
b/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc
similarity index 94%
rename from libstdc++-v3/testsuite/20_util/duration/literals/range.cc
rename to libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc
@@ -26,6 +26,6 @@ test01()
 
   // std::numeric_limits::max() == 9223372036854775807;
   auto h = 9223372036854775808h;
-  // { dg-error "cannot be represented" "" { target *-*-* } 894 }
+  // { dg-error "cannot be represented" "" { target *-*-* } 898 }
 }
 // { dg-prune-output "in constexpr expansion" } // needed for -O0

Re: [tree.c] Replace cast to (char *) by const_cast

On Mon, Jun 18, 2018 at 1:51 PM, Jakub Jelinek  wrote:
> On Mon, Jun 18, 2018 at 01:48:05PM -0400, Jason Merrill wrote:
>> On Mon, Jun 18, 2018 at 12:41 PM, Jakub Jelinek  wrote:
>> > On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
>> >> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
>> >> > On 18 June 2018 at 19:28, Nick Clifton  wrote:
>> >> >> Hi Prathamesh,
>> >> >>
>> >> >>> I am getting the following build error with trunk:
>> >> >>> ../../gcc/gcc/tree.c: In member function ‘void
>> >> >>> escaped_string::escape(const char*)’:
>> >> >>> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
>> >> >>> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
>> >> >>>m_str = (char *) unescaped;
>> >> >>> ^
>> >> >>> I think this is caused by r261697 in tree.c:
>> >> >>>   m_str = (char *) unescaped;
>> >> >>>
>> >> >>> The patch changes it to const_cast (unescaped) which fixes the
>> >> >>> build for me.
>> >> >>
>> >> >> I cannot approve this patch, but I can say thanks very much for 
>> >> >> catching
>> >> >> this problem and proposing a fix.  I guess that I must be using an old
>> >> >> version of g++ for my testing as this error did not show up. :-(
>> >> > Hi Nick,
>> >> > Thanks for confirming. I went ahead and committed the patch in r261700
>> >> > since I guess it's trivial enough to fit under the "obvious" rule.
>> >> Yes.
>> >>
>> >> Thanks for taking care of it.
>> >
>> > Shouldn't we use
>> >   m_str = CONST_CAST (char *, unescaped);
>> > instead?  That is what most similar spots use.
>>
>> That macro seems obsolete now that we compile as C++.
>
> But shouldn't we then remove/poison those macros and replace all uses?
> I don't care much if we use CONST_CAST or const_cast, but care about
> consistency.

That would make sense.

Jason

Re: Incremental LTO linking part 2: lto-plugin support

2018-06-18 Thread Sandra Loosemore


On 06/18/2018 11:37 AM, Jan Hubicka wrote:


It is exactly the warning newly added by this patch.

/scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld:
warning: incremental linking of LTO and non-LTO objects; using
-flinker-output=nolto-rel which will bypass whole program optimization

I built a completely fresh arm-none-eabi toolchain with a brand-new
binutils-gdb trunk checkout, so this isn't a problem with an old binutils.


This is different issue. Perhaps it is because we normaly link in shared lib 
but now
we bring -fno-lto object into LTO incremental link.
What object files are being linked together here?


The exact commands being used to build one of the test cases are:

arm-none-eabi-g++ -fno-diagnostics-show-caret -fdiagnostics-color=never 
-fmessage-length=0 -fPIC -flto -Wno-return-type -c -o 
cp_lto_20091002-1_0.o 
/scratch/sandra/arm-eabi-upstream/src/gcc-mainline/gcc/testsuite/g++.dg/lto/20091002-1_0.C


arm-none-eabi-g++ cp_lto_20091002-1_0.o g++_tg.o 
-fno-diagnostics-show-caret -fdiagnostics-color=never 
-fmessage-length=0 -fPIC -flto -Wno-return-type -fPIC -r -nostdlib 
  -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort-o 
g++-dg-lto-20091002-1-01.exe


The target here is the GDB ARM simulator, BTW.

-Sandra

Re: RFA: Sanitize deprecation messages (PR 84195)

On Fri, Feb 16, 2018 at 11:19 AM, Martin Sebor  wrote:
> On 02/16/2018 05:43 AM, Nick Clifton wrote:
>>
>> Hi David,
>>
>>   Attached is a revised version of the patch which I hope addresses all
>>   of your (very helpful) comments on the v3 patch.
>>
>>   OK to apply once the sources are back on stage 1 ?
>
>
> Thanks (also) for adding the documentation!
>
> I have just one minor observation/suggestion for the escaped_string
> class.  Feel free not to change anything, it's just a possible gotcha
> if the class were to become more widely used than it is now.
>
> Since the class manages a resource it should ideally make sure it
> doesn't try to release the same resource multiple times.  I.e., its
> copy constructor and assignment operators should either "do the right
> thing" (whatever you think that is) or be made inaccessible (or declared
> deleted in C++ 11).
>
> For example:
>
>   {
> escaped_string a;
> a.escape ("foo\nbar");
>
> escaped_string b (a);
> // b destroys its m_str
> // double free in a's destructor here
>   }
>
> (Some day GCC will have a warning to help detect this pitfall.)

-Wdeprecated-copy, which I recently added to -Wall, will warn if such
a class is actually copied.  Though I'm not sure it will stay in
-Wall, or keep that name.

Jason

Re: [tree.c] Replace cast to (char *) by const_cast

2018-06-18 Thread Jakub Jelinek

On Mon, Jun 18, 2018 at 01:48:05PM -0400, Jason Merrill wrote:
> On Mon, Jun 18, 2018 at 12:41 PM, Jakub Jelinek  wrote:
> > On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
> >> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
> >> > On 18 June 2018 at 19:28, Nick Clifton  wrote:
> >> >> Hi Prathamesh,
> >> >>
> >> >>> I am getting the following build error with trunk:
> >> >>> ../../gcc/gcc/tree.c: In member function ‘void
> >> >>> escaped_string::escape(const char*)’:
> >> >>> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
> >> >>> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
> >> >>>m_str = (char *) unescaped;
> >> >>> ^
> >> >>> I think this is caused by r261697 in tree.c:
> >> >>>   m_str = (char *) unescaped;
> >> >>>
> >> >>> The patch changes it to const_cast (unescaped) which fixes the
> >> >>> build for me.
> >> >>
> >> >> I cannot approve this patch, but I can say thanks very much for catching
> >> >> this problem and proposing a fix.  I guess that I must be using an old
> >> >> version of g++ for my testing as this error did not show up. :-(
> >> > Hi Nick,
> >> > Thanks for confirming. I went ahead and committed the patch in r261700
> >> > since I guess it's trivial enough to fit under the "obvious" rule.
> >> Yes.
> >>
> >> Thanks for taking care of it.
> >
> > Shouldn't we use
> >   m_str = CONST_CAST (char *, unescaped);
> > instead?  That is what most similar spots use.
> 
> That macro seems obsolete now that we compile as C++.

But shouldn't we then remove/poison those macros and replace all uses?
I don't care much if we use CONST_CAST or const_cast, but care about
consistency.

Jakub

Re: [tree.c] Replace cast to (char *) by const_cast

On Mon, Jun 18, 2018 at 12:41 PM, Jakub Jelinek  wrote:
> On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
>> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
>> > On 18 June 2018 at 19:28, Nick Clifton  wrote:
>> >> Hi Prathamesh,
>> >>
>> >>> I am getting the following build error with trunk:
>> >>> ../../gcc/gcc/tree.c: In member function ‘void
>> >>> escaped_string::escape(const char*)’:
>> >>> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
>> >>> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
>> >>>m_str = (char *) unescaped;
>> >>> ^
>> >>> I think this is caused by r261697 in tree.c:
>> >>>   m_str = (char *) unescaped;
>> >>>
>> >>> The patch changes it to const_cast (unescaped) which fixes the
>> >>> build for me.
>> >>
>> >> I cannot approve this patch, but I can say thanks very much for catching
>> >> this problem and proposing a fix.  I guess that I must be using an old
>> >> version of g++ for my testing as this error did not show up. :-(
>> > Hi Nick,
>> > Thanks for confirming. I went ahead and committed the patch in r261700
>> > since I guess it's trivial enough to fit under the "obvious" rule.
>> Yes.
>>
>> Thanks for taking care of it.
>
> Shouldn't we use
>   m_str = CONST_CAST (char *, unescaped);
> instead?  That is what most similar spots use.

That macro seems obsolete now that we compile as C++.

Jason

Re: Incremental LTO linking part 2: lto-plugin support

2018-06-18 Thread Jan Hubicka

> 
> It is exactly the warning newly added by this patch.
> 
> /scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld:
> warning: incremental linking of LTO and non-LTO objects; using
> -flinker-output=nolto-rel which will bypass whole program optimization
> 
> I built a completely fresh arm-none-eabi toolchain with a brand-new
> binutils-gdb trunk checkout, so this isn't a problem with an old binutils.

This is different issue. Perhaps it is because we normaly link in shared lib 
but now 
we bring -fno-lto object into LTO incremental link.
What object files are being linked together here?

Honza
> 
> -Sandra

Re: [PATCH, alpha] PR target/85095

On 05/24/2018 04:34 PM, co...@sdf.org wrote:
> On Thu, May 24, 2018 at 01:32:17PM -0600, Jeff Law wrote:
>> On 05/24/2018 01:17 PM, co...@sdf.org wrote:
>>> On Thu, May 24, 2018 at 12:48:22PM -0600, Jeff Law wrote:
 On 05/24/2018 07:54 AM, Maya Rashish wrote:
> Move linux-specific specfile definitions to linux.h
> gcc/config/alpha/linux.h (STARTFILE_SPEC, ENDFILE_SPEC) move from 
> alpha/elf.h
> ---
>  gcc/config/alpha/elf.h   | 26 --
>  gcc/config/alpha/linux.h | 26 ++
>  2 files changed, 26 insertions(+), 26 deletions(-)
 So is there going to be some kind of follow-up to fix freebsd, netbsd
 and openbsd which currently get their STARTFILE/ENDFILE from elf.h?

 jeff
>>>
>>> I can try to fix openbsd soon, but freebsd dropped alpha in 2009.
>>> How does gcc feel about me picking up patches from openbsd ports, their
>>> package manager, that weren't written by myself?
>> So ISTM we should deprecate freebsd alpha.
>>
>> WRT picking up bits from others.  It'd really depend on their size and
>> complexity -- I'd have to see them to be able to judge.  I'll review if
>> you extract the necessary bits and submit them.
>>
>> Jeff
> 
> - With the original patch
> - Attached patch to update the specfile for openbsd from openbsd ports
> (It is here: 
> https://github.com/openbsd/ports/blob/master/lang/gcc/6/patches/patch-gcc_config_alpha_openbsd_h
>  )
> - Attached patch to recognise cross compilation for openbsd (from me)
> - A violent hack of "borrowing" stdatomic.h from a newer GCC
> - Disabling libssp
> 
> I can build trunk for openbsd--alpha.
> 
Thanks.  I've created a ChangeLog and applied your first patch as well
as this one.

Jeff

Re: [PATCH v3] Change default to -fno-math-errno

On Mon, 18 Jun 2018, Jeff Law wrote:

> So do we need to set or check math_errhandling & MATH_ERRNO at all?  Or

That's a matter for libc (glibc currently sets it based on __FAST_MATH__ / 
__NO_MATH_ERRNO__, but fails to avoid including MATH_ERREXCEPT in the 
definition for configurations not supporting exceptions).

> WRT library behavior, I thought it was only complex arithmetic that had
> the option of setting errno.  I thought float/double math functions had
> a requirement to set errno?

For complex.h functions it's always optional.  For math.h functions at 
least one of errno and exceptions must be set, as indicated in the 
definition of math_errhandling (and if math_errhandling is defined to just 
one of MATH_ERRNO and MATH_ERREXCEPT, functions then may or may not also 
indicate errors in the other way).  Hence the question of whether a 
-fno-math-errno default should be different for (mainly soft-float) 
configurations not supporting floating-point exceptions, for which errno 
is the only way they have available to indicate errors.

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

Re: RFC: What should go in our header?


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

On 17 June 2018 at 19:49, Ed Smith-Rowland <3dw...@verizon.net> wrote:

On 06/15/2018 11:52 AM, Jonathan Wakely wrote:


C++20 adds a  header, which should define all the library
feature test macros, as well as implementation-specific macros like
_GLIBCXX_RELEASE and __GLIBCXX__.

We should decide whether to implement  by simply including
 and then adding the feature test macros, or if we
should keep it minimal and *only* define _GLIBCXX_RELEASE and
__GLIBCXX__ and the feature tests (and then have 
include ?)

I think I prefer to make  just include .

I think we should define the feature-test macros in both  and
the relevant header (e.g. __cpp_string_view in ). We
could make everything include  and then every header would
define every feature test macro, but I don't think that's good for
portability.

My preference is implemented by the attached patch.


This is pretty much what I was looking at doing.  I say go!


+1 looks reasonable to me.


Here's what I've committed, which adds tests and also defines
__STDCPP_MATH_SPEC_FUNCS__ in .

I've also added this and the new C++17 headers to the 
precompiled header.


commit af8c87bcb7341e6bf0d4faec17c30df29748d4df
Author: Jonathan Wakely 
Date:   Fri Jun 15 15:35:38 2018 +0100

P0754R2  header

* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/c++config: Change doxygen comment to suggest 
instead of .
* include/precompiled/stdc++.h: Include  and 
unconditionally.  Add C++17 and C++20 headers.
* include/std/version: New header.
* testsuite/17_intro/headers/c++2017/all_attributes.cc: New.
* testsuite/17_intro/headers/c++2017/all_no_exceptions.cc: New.
* testsuite/17_intro/headers/c++2017/all_no_rtti.cc: New.
* testsuite/17_intro/headers/c++2017/all_pedantic_errors.cc: New.
* testsuite/17_intro/headers/c++2017/operator_names.cc: New.
* testsuite/17_intro/headers/c++2017/stdc++.cc: New.
* testsuite/17_intro/headers/c++2017/stdc++_multiple_inclusion.cc:
New.
* testsuite/17_intro/headers/c++2020/all_attributes.cc: New.
* testsuite/17_intro/headers/c++2020/all_no_exceptions.cc: New.
* testsuite/17_intro/headers/c++2020/all_no_rtti.cc: New.
* testsuite/17_intro/headers/c++2020/all_pedantic_errors.cc: New.
* testsuite/17_intro/headers/c++2020/operator_names.cc: New.
* testsuite/17_intro/headers/c++2020/stdc++.cc: New.
* testsuite/17_intro/headers/c++2020/stdc++_multiple_inclusion.cc:
New.
* testsuite/18_support/headers/version/macros.cc: New.
* testsuite/18_support/headers/version/macros.cc: New.

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 77e6dc2f6be..f91907df325 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -80,7 +80,8 @@ std_headers = \
 	${std_srcdir}/utility \
 	${std_srcdir}/valarray \
 	${std_srcdir}/variant \
-	${std_srcdir}/vector
+	${std_srcdir}/vector \
+	${std_srcdir}/version
 
 bits_srcdir = ${glibcxx_srcdir}/include/bits
 bits_builddir = ./bits
diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config
index 4a096a198db..c0b89f481d8 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -24,7 +24,7 @@
 
 /** @file bits/c++config.h
  *  This is an internal header file, included by other library headers.
- *  Do not attempt to use it directly. @headername{iosfwd}
+ *  Do not attempt to use it directly. @headername{version}
  */
 
 #ifndef _GLIBCXX_CXX_CONFIG_H
diff --git a/libstdc++-v3/include/precompiled/stdc++.h b/libstdc++-v3/include/precompiled/stdc++.h
index adcd7bf312c..9b056bb3467 100644
--- a/libstdc++-v3/include/precompiled/stdc++.h
+++ b/libstdc++-v3/include/precompiled/stdc++.h
@@ -47,6 +47,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #if __cplusplus >= 201103L
 #include 
@@ -57,8 +59,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #endif
 
 // C++
@@ -123,6 +123,19 @@
 #endif
 
 #if __cplusplus >= 201703L
+#include 
 #include 
+// #include 
 #include 
+#include 
+// #include 
+#include 
+#include 
+#endif
+
+#if __cplusplus > 201703L
+// #include 
+// #include 
+// #include 
+#include 
 #endif
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
new file mode 100644
index 000..08036ff63f2
--- /dev/null
+++ b/libstdc++-v3/include/std/version
@@ -0,0 +1,134 @@
+// -*- C++ -*- Libstdc++ version details header.
+
+// 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

Re: [tree.c] Replace cast to (char *) by const_cast

2018-06-18 Thread Jakub Jelinek

On Mon, Jun 18, 2018 at 08:34:28AM -0600, Jeff Law wrote:
> On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
> > On 18 June 2018 at 19:28, Nick Clifton  wrote:
> >> Hi Prathamesh,
> >>
> >>> I am getting the following build error with trunk:
> >>> ../../gcc/gcc/tree.c: In member function ‘void
> >>> escaped_string::escape(const char*)’:
> >>> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
> >>> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
> >>>m_str = (char *) unescaped;
> >>> ^
> >>> I think this is caused by r261697 in tree.c:
> >>>   m_str = (char *) unescaped;
> >>>
> >>> The patch changes it to const_cast (unescaped) which fixes the
> >>> build for me.
> >>
> >> I cannot approve this patch, but I can say thanks very much for catching
> >> this problem and proposing a fix.  I guess that I must be using an old
> >> version of g++ for my testing as this error did not show up. :-(
> > Hi Nick,
> > Thanks for confirming. I went ahead and committed the patch in r261700
> > since I guess it's trivial enough to fit under the "obvious" rule.
> Yes.
> 
> Thanks for taking care of it.

Shouldn't we use
  m_str = CONST_CAST (char *, unescaped);
instead?  That is what most similar spots use.

Jakub

Re: [PATCH] add support for strnlen (PR 81384)


On 06/12/2018 03:11 PM, Jeff Law wrote:

On 06/05/2018 03:43 PM, Martin Sebor wrote:

The attached patch adds basic support for handling strnlen
as a built-in function.  It touches the strlen pass where
it folds constant results of the function, and builtins.c
to add simple support for expanding strnlen calls with known
results.  It also changes calls.c to detect excessive bounds
to the function and unsafe calls with arguments declared
attribute nonstring.

A side-effect of the strlen change I should call out is that
strlen() calls to all zero-length arrays that aren't considered
flexible array members (i.e., internal members or non-members)
are folded into zero.  No warning is issued for such invalid
uses of zero-length arrays but based on the responses to my
question Re: aliasing between internal zero-length-arrays and
other members(*) it sounds like one would be appropriate.
I will see about adding one in a separate patch.

Martin

[*] https://gcc.gnu.org/ml/gcc/2018-06/msg00046.html

gcc-81384.diff


PR tree-optimization/81384 - built-in form of strnlen missing

gcc/ChangeLog:

PR tree-optimization/81384
* builtin-types.def (BT_FN_SIZE_CONST_STRING_SIZE): New.
* builtins.c (expand_builtin_strnlen): New function.
(expand_builtin): Call it.
(fold_builtin_n): Avoid setting TREE_NO_WARNING.
* builtins.def (BUILT_IN_STRNLEN): New.
* calls.c (maybe_warn_nonstring_arg): Handle BUILT_IN_STRNLEN.
Warn for bounds in excess of maximum object size.
* tree-ssa-strlen.c (maybe_set_strlen_range): Return tree representing
single-value ranges.  Handle strnlen.
(handle_builtin_strlen): Handle strnlen.
(strlen_check_and_optimize_stmt): Same.

gcc/testsuite/ChangeLog:

PR tree-optimization/81384
* gcc.c-torture/execute/builtins/lib/strnlen.c: New test.
* gcc.c-torture/execute/builtins/strnlen-lib.c: New test.
* gcc.c-torture/execute/builtins/strnlen.c: New test.
* gcc.dg/attr-nonstring-2.c: New test.
* gcc.dg/attr-nonstring-3.c: New test.
* gcc.dg/attr-nonstring-4.c: New test.
* gcc.dg/strlenopt-44.c: New test.
* gcc.dg/strlenopt.h (strnlen):  Declare.

diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index 5365bef..1f15350 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -322,6 +322,8 @@ DEF_FUNCTION_TYPE_2 (BT_FN_STRING_CONST_STRING_INT,
 BT_STRING, BT_CONST_STRING, BT_INT)
 DEF_FUNCTION_TYPE_2 (BT_FN_STRING_CONST_STRING_SIZE,
 BT_STRING, BT_CONST_STRING, BT_SIZE)
+DEF_FUNCTION_TYPE_2 (BT_FN_SIZE_CONST_STRING_SIZE,
+BT_SIZE, BT_CONST_STRING, BT_SIZE)
 DEF_FUNCTION_TYPE_2 (BT_FN_INT_CONST_STRING_FILEPTR,
 BT_INT, BT_CONST_STRING, BT_FILEPTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_INT_INT_FILEPTR,

I believe Jakub already suggested these change and you ack'd that.

You have some hunks which will need updating now that the CHKP/MPX bits
are gone.

So OK after the cleanups noted above and a fresh bootstrap & regression
test cycle.



Done.  I also added documentation for the built-in, reran GCC
and Glibc tests with no regressions, and committed 261705.

Martin

[PATCH, rs6000] Fix implementation of vec_packsu (vector unsigned long long, vector unsigned long long) built-in function

2018-06-18 Thread Kelvin Nilsen



This patch fixes an error in the code generation for vec_packsu (vector 
unsigned long long, vector unsigned long long).  As previously implemented, 
this built-in function translates to the vpksdus instruction.

This patch causes vec_packsu (vector unsigned long long, vector unsigned long 
long) to behave the same as vec_packs (vector unsigned long long, vector 
unsigned long long) for the same type signature, producing the vpkudus 
instruction.

This patch has bootstrapped and tested without regressions on 
powerpc64le-unknown-linux (both P8 and P9) and on powerpc-linux (P8 big-endian, 
both -m32 and -m64).

Is this ok for the trunk?

gcc/ChangeLog:

2018-06-18  Kelvin Nilsen  

* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Change
behavior of vec_packsu (vector unsigned long long, vector unsigned
long long) to match behavior of vec_packs with same signature.

gcc/testsuite/ChangeLog:

2018-06-18  Kelvin Nilsen  

* gcc.target/powerpc/builtins-1.c: Adjust dg directives to scan
for vpkudus in place of vpksdus.
* gcc.target/powerpc/builtins-3-p8.c: Likewise.

Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 261599)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -2544,7 +2544,7 @@ const struct altivec_builtin_types altivec_overloa
 RS6000_BTI_unsigned_V8HI, RS6000_BTI_V4SI, RS6000_BTI_V4SI, 0 },
   { ALTIVEC_BUILTIN_VEC_PACKSU, P8V_BUILTIN_VPKSDUS,
 RS6000_BTI_unsigned_V4SI, RS6000_BTI_V2DI, RS6000_BTI_V2DI, 0 },
-  { ALTIVEC_BUILTIN_VEC_PACKSU, P8V_BUILTIN_VPKSDUS,
+  { ALTIVEC_BUILTIN_VEC_PACKSU, P8V_BUILTIN_VPKUDUS,
 RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V2DI, 
RS6000_BTI_unsigned_V2DI, 0 },
   { ALTIVEC_BUILTIN_VEC_VPKSWUS, ALTIVEC_BUILTIN_VPKSWUS,
 RS6000_BTI_unsigned_V8HI, RS6000_BTI_V4SI, RS6000_BTI_V4SI, 0 },
Index: gcc/testsuite/gcc.target/powerpc/builtins-1.c
===
--- gcc/testsuite/gcc.target/powerpc/builtins-1.c   (revision 261599)
+++ gcc/testsuite/gcc.target/powerpc/builtins-1.c   (working copy)
@@ -297,7 +297,7 @@ int main ()
vec_mul mulld | mullw, mulhwu
vec_nor xxlnor
vec_or  xxlor
-   vec_packsu  vpksdus
+   vec_packsu  vpkudus (matches twice due to -dp option)
vec_perm vperm
vec_round xvrdpi
vec_sel xxsel
@@ -335,7 +335,11 @@ int main ()
 /* { dg-final { scan-assembler-times "xxlnor" 6 } } */
 /* { dg-final { scan-assembler-times "xxlor" 11 { target { ilp32 } } } } */
 /* { dg-final { scan-assembler-times "xxlor" 7  { target { lp64 } } } } */
-/* { dg-final { scan-assembler-times "vpksdus" 2 } } */
+
+/* A single vpkudus matches twice because this is compiled with -dp,
+   causing diagnostic comments to appear in the resulting .s file, one
+   of which matches vpkudus.  */
+/* { dg-final { scan-assembler-times "vpkudus" 2 } } */
 /* { dg-final { scan-assembler-times "vperm" 4 } } */
 /* { dg-final { scan-assembler-times "xvrdpi" 2 } } */
 /* { dg-final { scan-assembler-times "xxsel" 10 } } */
Index: gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c
===
--- gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c(revision 261599)
+++ gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c(working copy)
@@ -219,6 +219,8 @@ test_neg_double (vector double x)
  test_vui_packs_vull_vull  1 vpkudus
  test_vui_packs_vssi_vssi  1 vpkshss
  test_vsi_packsu_vssi_vssi 1 vpkshus
+ test_vsi_packsu_vsll_vsll 1 vpksdus
+ test_vsi_packsu_vull_vull 1 vpkudus
  test_unsigned_char_popcnt_signed_char 1 vpopcntb
  test_unsigned_char_popcnt_unsigned_char   1 vpopcntb
  test_unsigned_short_popcnt_signed_short   1 vpopcnth
@@ -241,11 +243,11 @@ test_neg_double (vector double x)
 /* { dg-final { scan-assembler-times "vcmpequd" 1 } } */
 /* { dg-final { scan-assembler-times "vpkudum"  1 } } */
 /* { dg-final { scan-assembler-times "vpksdss"  1 } } */
-/* { dg-final { scan-assembler-times "vpkudus"  1 } } */  
+/* { dg-final { scan-assembler-times "vpkudus"  2 } } */  
 /* { dg-final { scan-assembler-times "vpkuhus"  2 } } */
 /* { dg-final { scan-assembler-times "vpkshss"  1 } } */  
 /* { dg-final { scan-assembler-times "vpkshus"  1 } } */  
-/* { dg-final { scan-assembler-times "vpksdus"  2 } } */  
+/* { dg-final { scan-assembler-times "vpksdus"  1 } } */  
 /* { dg-final { scan-assembler-times "vpkuwus"  2 } } */  
 /* { dg-final { scan-assembler-times "vpopcntb" 2 } } */
 /* { dg-final { scan-assembler-times "vpopcnth" 2 } } */

Re: RFA: Sanitize deprecation messages (PR 84195)

2018-06-18 Thread Nick Clifton

Hi Martin,

> I'm getting a bootstrap failure:

*sigh* yes - my bad.  Fortunately a patch has already been posted:

  https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01039.html

And I think that it has now been approved.

Cheers
  Nick

Re: [PATCH v3] Change default to -fno-math-errno

On 06/18/2018 08:01 AM, Wilco Dijkstra wrote:
> GCC currently defaults to -fmath-errno.  This generates code assuming math
> functions set errno and the application checks errno.  Few applications
> test errno and various systems and math libraries no longer set errno since it
> is optional.  GCC generates much faster code for simple math functions with
> -fno-math-errno such as sqrt and lround (avoiding a call and PLT redirection).
> Therefore it is reasonable to change the default to -fno-math-errno.  This is
> already the case for non-C languages.  Only change the default for C99 and
> later.
> 
> long f(float x) { return lroundf(x) + 1; }
> 
> by default:
> 
> f:
>   str x30, [sp, -16]!
>   bl  lroundf
>   add x0, x0, 1
>   ldr x30, [sp], 16
>   ret
> 
> With -fno-math-errno:
> 
> f:
>   fcvtas  x0, s0
>   add x0, x0, 1
>   ret
> 
> Passes regress on AArch64. OK for commit?
> 
> ChangeLog:
> 2018-06-18  Wilco Dijkstra  
> 
>   * common.opt (fmath-errno): Change default to 0.
>   * opts.c (set_fast_math_flags): Force -fno-math-errno with -ffast-math.
>   * c-family/c-opts.c (c_common_init_options_struct): Set flag_errno_math
>   to special value.
>   (c_common_post_options): Set flag_errno_math default based on language.
> 
> doc/
>   * invoke.texi (-fmath-errno) Update documentation.
> 
> testsuite/
> 
>   * gcc.dg/errno-1.c: Add -fmath-errno.
>   * gcc.dg/torture/pr68264.c: Likewise.
>   * gcc.dg/tree-ssa/ssa-dse-15.c: Likewise.
>   * gcc.target/aarch64/no-inline-lrint_1.c: Likewise.
So do we need to set or check math_errhandling & MATH_ERRNO at all?  Or
are those really meant for the user to test?  (which I think just
indicates we need to make sure they're set correctly).

WRT library behavior, I thought it was only complex arithmetic that had
the option of setting errno.  I thought float/double math functions had
a requirement to set errno?

While I would love to see us drop the need to ensure errno is set as it
allows us to exploit processor capabilities, I want to make sure that we
stay conformant with the relevant standards.

jeff

>

Re: [patch] Remove redundant intrinsics

On 06/14/2018 05:44 AM, Koval, Julia wrote:
> Hi,
> 
> This patch should fix the issue. Ok for trunk?
> 
> gcc/testsuite/
>   * gcc.target/i386/avx512vl-vpclmulqdq-2.c: Remove 128bit version.
OK.
jeff

Re: [PATCH] PR libstdc++/78870 support std::filesystem on Windows


On 16/06/18 20:56 -0600, Sandra Loosemore wrote:

On 06/16/2018 05:05 PM, Jonathan Wakely wrote:

Oops, that message got bounced from the lists and was the wrong
version of the patch anyway - this is the one I meant to attach.

On Sun, 17 Jun 2018 at 00:00, Jonathan Wakely  wrote:


Here's what I wanted to test, which removes the new AC_CHECK_FUNCS (replacing 
them with GLIBCXX_COMPILE_OR_LINK tests that shouldn't even get run on bare 
metal ).


This patch worked for me, or at least I got successful builds now.  
I'm testing the new C-SKY port and built both csky-elf and 
csky-linux-gnu. (I expect to be submitting the port within the next 
few weeks.)


Here's what I've committed (it's the same apart from some comments and
re-indenting).

Tested x86_64-linux and powerpc64le-linux, committed to trunk.


commit 6857313ff08786cf66f1e1200d4e480b764937ef
Author: Jonathan Wakely 
Date:   Mon Jun 18 16:43:36 2018 +0100

Fix bootstrap failure for bare metal due to autoconf link tests

The AC_CHECK_FUNCS tests cause the build to fail for bare metal cross
compilers, where link tests are not allowed. Replace them with
GCC_TRY_COMPILE_OR_LINK tests instead. Skip all the Filesystem
dependency checks if not building the filesystem library.

* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Only check when
enable_libstdcxx_filesystem_ts = yes. Check for link, readlink and
symlink.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove AC_CHECK_FUNCS for link, readlink and symlink.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 4f37b6a6498..6c855b6c7e5 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4309,143 +4309,194 @@ AC_DEFUN([GLIBCXX_ENABLE_FILESYSTEM_TS], [
 ])
 
 dnl
-dnl Check whether the library calls required by the Filesystem TS are present
-dnl and define _GLIBCXX_USE_REALPATH and _GLIBCXX_USE_UTIMENSAT.
+dnl Check whether the library calls required by the Filesystem TS are present.
+dnl Defines:
+dnl  HAVE_STRUCT_DIRENT_D_TYPE
+dnl  _GLIBCXX_USE_REALPATH
+dnl  _GLIBCXX_USE_UTIMENSAT
+dnl  _GLIBCXX_USE_ST_MTIM
+dnl  _GLIBCXX_USE_FCHMOD
+dnl  _GLIBCXX_USE_FCHMODAT
+dnl  _GLIBCXX_USE_SENDFILE
+dnl  HAVE_LINK
+dnl  HAVE_READLINK
+dnl  HAVE_SYMLINK
 dnl
 AC_DEFUN([GLIBCXX_CHECK_FILESYSTEM_DEPS], [dnl
 dnl
-  AC_LANG_SAVE
-  AC_LANG_CPLUSPLUS
-  ac_save_CXXFLAGS="$CXXFLAGS"
-  CXXFLAGS="$CXXFLAGS -fno-exceptions"
+  if test $enable_libstdcxx_filesystem_ts = yes; then
+AC_LANG_SAVE
+AC_LANG_CPLUSPLUS
+ac_save_CXXFLAGS="$CXXFLAGS"
+CXXFLAGS="$CXXFLAGS -fno-exceptions"
 dnl
-  AC_MSG_CHECKING([for struct dirent.d_type])
-  AC_CACHE_VAL(glibcxx_cv_dirent_d_type, [dnl
-GCC_TRY_COMPILE_OR_LINK(
-  [#include ],
-  [
-   struct dirent d;
-   if (sizeof d.d_type) return 0;
-  ],
-  [glibcxx_cv_dirent_d_type=yes],
-  [glibcxx_cv_dirent_d_type=no])
-  ])
-  if test $glibcxx_cv_dirent_d_type = yes; then
-AC_DEFINE(HAVE_STRUCT_DIRENT_D_TYPE, 1, [Define to 1 if `d_type' is a member of `struct dirent'.])
+AC_MSG_CHECKING([for struct dirent.d_type])
+AC_CACHE_VAL(glibcxx_cv_dirent_d_type, [dnl
+  GCC_TRY_COMPILE_OR_LINK(
+[#include ],
+[
+ struct dirent d;
+ if (sizeof d.d_type) return 0;
+],
+[glibcxx_cv_dirent_d_type=yes],
+[glibcxx_cv_dirent_d_type=no])
+])
+if test $glibcxx_cv_dirent_d_type = yes; then
+  AC_DEFINE(HAVE_STRUCT_DIRENT_D_TYPE, 1, [Define to 1 if `d_type' is a member of `struct dirent'.])
+fi
+AC_MSG_RESULT($glibcxx_cv_dirent_d_type)
+dnl
+AC_MSG_CHECKING([for realpath])
+AC_CACHE_VAL(glibcxx_cv_realpath, [dnl
+  GCC_TRY_COMPILE_OR_LINK(
+[
+ #include 
+ #include 
+ #include 
+],
+[
+ #if _XOPEN_VERSION < 500
+ #error
+ #elif _XOPEN_VERSION >= 700 || defined(PATH_MAX)
+ char *tmp = realpath((const char*)NULL, (char*)NULL);
+ #else
+ #error
+ #endif
+],
+[glibcxx_cv_realpath=yes],
+[glibcxx_cv_realpath=no])
+])
+if test $glibcxx_cv_realpath = yes; then
+  AC_DEFINE(_GLIBCXX_USE_REALPATH, 1, [Define if usable realpath is available in .])
+fi
+AC_MSG_RESULT($glibcxx_cv_realpath)
+dnl
+AC_MSG_CHECKING([for utimensat])
+AC_CACHE_VAL(glibcxx_cv_utimensat, [dnl
+  GCC_TRY_COMPILE_OR_LINK(
+[
+  #include 
+  #include 
+],
+[
+  struct timespec ts[2] = { { 0, UTIME_OMIT }, { 1, 1 } };
+  int i = utimensat(AT_FDCWD, "path", ts, 0);
+],
+[glibcxx_cv_utimensat=yes],
+[glibcxx_cv_utimensat=no])
+])
+if test $glibcxx_cv_utimensat = yes; then
+  AC_DEFINE(_GLIBCXX_USE_UTIMENSAT, 1, [Define if utimensat and UTIME_OMIT are available in  and AT_FDCWD in .])
+

Re: [PATCH v2] C/C++: Add -Waddress-of-packed-member

On Mon, 18 Jun 2018, Jason Merrill wrote:

> > +  if (TREE_CODE (rhs) == COND_EXPR)
> > +{
> > +  /* Check the THEN path first.  */
> > +  tree op1 = TREE_OPERAND (rhs, 1);
> > +  context = check_address_of_packed_member (type, op1);
> 
> This should handle the GNU extension of re-using operand 0 if operand
> 1 is omitted.

Doesn't that just use a SAVE_EXPR?

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

Re: [patch] Test Fortran part of libgomp with check-fortran

On 06/18/2018 02:00 AM, Eric Botcazou wrote:
> Hi,
> 
> that's already done for C++ so it seems consistent to do it for Fortran too.
> 
> Tested on x86-64/Linux, OK for the mainline?
> 
> 
> 2018-06-18  Eric Botcazou  
> 
>   * Makefile.def (fortran): Add check-target-libgomp-fortran.
>   * Makefile.tpl (check-target-libgomp-fortran): New phony target.
>   * Makefile.in: Regenerate.
> 
Yes yes, please :-)

jeff

Re: [PATCH] Add initial version of rtl.vim syntax file.

On 06/15/2018 08:28 AM, Martin Liška wrote:
> On 06/15/2018 07:08 AM, Alexander Monakov wrote:
>> On Tue, 12 Jun 2018, Martin Liška wrote:
>>
>>> This is equivalent of gimple.vim file. I'm aware of not full coverage of RTL
>>> instructions, but hope it's a good start point.
>>
>> I think this is nice to have and hope you'll get an OK for both this and
>> the gimple.vim patch.
> 
> Hi.
> 
> Well, it's sitting in contrib, thus I'm planning to install that eventually
> if there will be not response.
> 
> 
>>
>> One nit-pick: unlike "GIMPLE", "RTL" is not a GCC-specific abbreviation.
>> I'd prefer to use gcc-rtl.vim to avoid possible clashes.
> 
> Good idea, let me fix that.
> 
>>
>> Do you use it quite literally as described in gimple.vim, i.e. with
>> editing ftdetect.vim by hand? I made a plugin for gcc/match.pd syntax
>> highlighting, and I opted to use a common plugin file layout for it.
>> That way, I only need to symlink the plugin directory under .vim/bundle.
> 
> I use it as follows:
> 
> vimrc:
> 
> au BufRead,BufNewFile *.[0-2][0-9][0-9][ti].* set filetype=gimple
> au BufRead,BufNewFile *.[2-3][0-9][0-9]r.* set filetype=rtl
> 
> Then I copied these .vim files into syntax folder. I know it's not ideal.
> For all other vim extensions I use plugin system (Dein) that installs plugins
> from github repos.
> 
> So you prefer to come up with a plugin folder with the *.vim files?
Whatever works best in terms of ease of use for someone that wants to
use the RTL (or gimple) modes.  If that means they need to be in a
subdir, that's fine with me.

jeff

Re: [PATCH] More rtx to rtx_insn * cleanups

On 06/14/2018 02:10 PM, David Malcolm wrote:
> These are mostly pre-approved, but there are some slightly non-trivial
> cases in frv.c and mips.c.
They looked pretty trivial to me :-)

> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> 
> Successfully built "cc1" binaries on all 197 configurations in
> contrib/config-list.mk.
> 
> OK for trunk?
> 
> gcc/ChangeLog:
>   * config/frv/frv-protos.h (frv_ifcvt_modify_insn): Strengthen 3rd
>   param from rtx to rtx_insn *.
>   * config/frv/frv.c (frv_ifcvt_add_insn): Likewise for "insn"
>   param.
>   (frv_ifcvt_modify_insn): Likwise.
>   (frv_ifcvt_modify_final): Likwise for local "existing_insn",
>   adding an as_a  cast.  Likewise for local "insn".
>   * config/mips/mips.c (r10k_insert_cache_barriers): Add an
>   as_a  cast to local "unprotected_region" once
>   it's been established that it's not NULL or pc_rtx.
>   * config/nds32/nds32-relax-opt.c (nds32_group_insns): Strengthen
>   param "sethi" from rtx to rtx_insn *.
>   (nds32_group_float_insns): Likewise for param "insn".
>   * config/vax/vax-protos.h (vax_output_int_add): Likewise for 1st
>   param.
>   (vax_output_int_subtract): Likewise.
>   * config/vax/vax.c (vax_output_int_add): Likewise for param
>   "insn".
>   (vax_output_int_subtract): Likewise.
>   * emit-rtl.c (set_insn_deleted): Likewise, removing cast.
>   (emit_pattern_after): Likewise for param "after".
>   (emit_insn_after): Likewise.
>   (emit_jump_insn_after): Likewise.
>   (emit_call_insn_after): Likewise.
>   (emit_debug_insn_after): Likewise.
>   (emit_pattern_before): Likewise for param "before".
>   (emit_insn_before): Likewise.
>   (emit_jump_insn_before): Likewise.
>   * final.c (get_insn_template): Likewise for param "insn", removing
>   a cast.
>   * output.h (get_insn_template): Likewise for 2nd param.
>   * rtl.h (emit_insn_before): Likewise.
>   (emit_jump_insn_before): Likewise.
>   (emit_debug_insn_before_noloc): Likewise.
>   (emit_insn_after): Likewise.
>   (emit_jump_insn_after): Likewise.
>   (emit_call_insn_after): Likewise.
>   (emit_debug_insn_after): Likewise.
>   (set_insn_deleted): Likewise for param.
OK.  Note the tester doesn't test the vax port.  It will test nds32-elf
(big and little endian), mips and frv though.

jeff

[PATCH] LWG 3035. std::allocator's constructors should be constexpr


* include/bits/allocator.h (allocator): Add constexpr to constructors
for C++2a. Replace dynamic exception specifications with NOTHROW
macro.
(allocator, operator==, operator!=): Replace USE_NOEXCEPT macro with
NOTHROW.
* include/bits/c++config (_GLIBCXX20_CONSTEXPR): Define.
* include/ext/malloc_allocator.h (malloc_allocator): Add constexpr
to constructors for C++2a.
* include/ext/new_allocator.h (new_allocator): Likewise.

Tested powerpc64le-linux, committed to trunk.


commit 09e0651249e65064ff4fd1181939c4318e64c9eb
Author: Jonathan Wakely 
Date:   Mon Jun 18 15:41:02 2018 +0100

LWG 3035. std::allocator's constructors should be constexpr

LWG 3035. std::allocator's constructors should be constexpr
* include/bits/allocator.h (allocator): Add constexpr to 
constructors
for C++2a. Replace dynamic exception specifications with NOTHROW
macro.
(allocator, operator==, operator!=): Replace USE_NOEXCEPT macro with
NOTHROW.
* include/bits/c++config (_GLIBCXX20_CONSTEXPR): Define.
* include/ext/malloc_allocator.h (malloc_allocator): Add constexpr
to constructors for C++2a.
* include/ext/new_allocator.h (new_allocator): Likewise.

diff --git a/libstdc++-v3/include/bits/allocator.h 
b/libstdc++-v3/include/bits/allocator.h
index 2da499f1498..c4e3a4b9c15 100644
--- a/libstdc++-v3/include/bits/allocator.h
+++ b/libstdc++-v3/include/bits/allocator.h
@@ -128,19 +128,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef true_type is_always_equal;
 #endif
 
-  allocator() throw() { }
+  // _GLIBCXX_RESOLVE_LIB_DEFECTS
+  // 3035. std::allocator's constructors should be constexpr
+  _GLIBCXX20_CONSTEXPR
+  allocator() _GLIBCXX_NOTHROW { }
 
-  allocator(const allocator& __a) throw()
+  _GLIBCXX20_CONSTEXPR
+  allocator(const allocator& __a) _GLIBCXX_NOTHROW
   : __allocator_base<_Tp>(__a) { }
+
 #if __cplusplus >= 201103L
   // Avoid implicit deprecation.
   allocator& operator=(const allocator&) = default;
 #endif
 
   template
-   allocator(const allocator<_Tp1>&) throw() { }
+   _GLIBCXX20_CONSTEXPR
+   allocator(const allocator<_Tp1>&) _GLIBCXX_NOTHROW { }
 
-  ~allocator() throw() { }
+  ~allocator() _GLIBCXX_NOTHROW { }
 
   // Inherit everything else.
 };
@@ -148,25 +154,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 inline bool
 operator==(const allocator<_T1>&, const allocator<_T2>&)
-_GLIBCXX_USE_NOEXCEPT
+_GLIBCXX_NOTHROW
 { return true; }
 
   template
 inline bool
 operator==(const allocator<_Tp>&, const allocator<_Tp>&)
-_GLIBCXX_USE_NOEXCEPT
+_GLIBCXX_NOTHROW
 { return true; }
 
   template
 inline bool
 operator!=(const allocator<_T1>&, const allocator<_T2>&)
-_GLIBCXX_USE_NOEXCEPT
+_GLIBCXX_NOTHROW
 { return false; }
 
   template
 inline bool
 operator!=(const allocator<_Tp>&, const allocator<_Tp>&)
-_GLIBCXX_USE_NOEXCEPT
+_GLIBCXX_NOTHROW
 { return false; }
 
   // Invalid allocator partial specializations.
diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 838afc59dfb..4a096a198db 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -122,15 +122,23 @@
 #endif
 
 #ifndef _GLIBCXX17_CONSTEXPR
-# if __cplusplus > 201402L
+# if __cplusplus >= 201703L
 #  define _GLIBCXX17_CONSTEXPR constexpr
 # else
 #  define _GLIBCXX17_CONSTEXPR
 # endif
 #endif
 
+#ifndef _GLIBCXX20_CONSTEXPR
+# if __cplusplus > 201703L
+#  define _GLIBCXX20_CONSTEXPR constexpr
+# else
+#  define _GLIBCXX20_CONSTEXPR
+# endif
+#endif
+
 #ifndef _GLIBCXX17_INLINE
-# if __cplusplus > 201402L
+# if __cplusplus >= 201703L
 #  define _GLIBCXX17_INLINE inline
 # else
 #  define _GLIBCXX17_INLINE
diff --git a/libstdc++-v3/include/ext/malloc_allocator.h 
b/libstdc++-v3/include/ext/malloc_allocator.h
index 75a74a39cef..8739c1fdaa3 100644
--- a/libstdc++-v3/include/ext/malloc_allocator.h
+++ b/libstdc++-v3/include/ext/malloc_allocator.h
@@ -75,11 +75,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef std::true_type propagate_on_container_move_assignment;
 #endif
 
+  _GLIBCXX20_CONSTEXPR
   malloc_allocator() _GLIBCXX_USE_NOEXCEPT { }
 
+  _GLIBCXX20_CONSTEXPR
   malloc_allocator(const malloc_allocator&) _GLIBCXX_USE_NOEXCEPT { }
 
   template
+   _GLIBCXX20_CONSTEXPR
 malloc_allocator(const malloc_allocator<_Tp1>&)
_GLIBCXX_USE_NOEXCEPT { }
 
diff --git a/libstdc++-v3/include/ext/new_allocator.h 
b/libstdc++-v3/include/ext/new_allocator.h
index 78e2019a0b3..19e7ad02e75 100644
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -76,11 +76,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef std::true_type

[PATCH][Middle-end]3rd patch of PR78809

2018-06-18 Thread Qing Zhao

Hi,

this is the 3rd (and the last) patch for PR78809:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Inline strcmp with small constant strings

The design doc for PR78809 is at:
https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html

this patch is for the third part of change of PR78809.

C. for strcmp (s1, s2), strncmp (s1, s2, n), and memcmp (s1, s2, n)
   if the result is NOT used to do simple equality test against zero, one of
"s1" or "s2" is a small constant string, n is a constant, and the Min value of
the length of the constant string and "n" is smaller than a predefined
threshold T,
   inline the call by a byte-to-byte comparision sequence to avoid calling
overhead.

adding test case strcmpopt_5.c into gcc.dg for part C of PR78809.

bootstraped and tested on both X86 and Aarch64. no regression.

I have done some experiments to check the run-time performance impact 
and code-size impact from such inlining with different threshold for the
length of the constant string to inline, the data were recorded in the 
attachments of 
PR78809:

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

and finally decide that the default value of the threshold is 3. 
this value of the threshold can be adjusted by the new option:

--param builtin-string-cmp-inline-length=

The following is the patch.

thanks.

Qing

gcc/ChangeLog:

+2018-06-18  Qing Zhao  
+
+   PR middle-end/78809
+   * builtins.c (expand_builtin_memcmp): Inline the calls first
+   when result_eq is false.
+   (expand_builtin_strcmp): Inline the calls first.
+   (expand_builtin_strncmp): Likewise.
+   (inline_string_cmp): New routine. Expand a string compare 
+   call by using a sequence of char comparison.
+   (inline_expand_builtin_string_cmp): New routine. Inline expansion
+   a call to str(n)cmp/memcmp.
+   * doc/invoke.texi (--param builtin-string-cmp-inline-length): New 
option.
+   * params.def (BUILTIN_STRING_CMP_INLINE_LENGTH): New.
+

gcc/testsuite/ChangeLog:

+2018-06-18  Qing Zhao  
+
+   PR middle-end/78809
+   * gcc.dg/strcmpopt_5.c: New test.
+




0001-3nd-Patch-for-PR78009.patch
Description: Binary data

Re: Incremental LTO linking part 2: lto-plugin support

2018-06-18 Thread Sandra Loosemore

On 06/18/2018 02:45 AM, Jan Hubicka wrote:

On 05/08/2018 09:14 AM, Jan Hubicka wrote:

Hi,
with lto, incremental linking can be meaninfuly done in three ways:
1) read LTO file and produce non-LTO .o file
this is current behaviour of gcc -r or ld -r with plugin
2) read LTO files and merge section for later LTO
this is current behaviour of ld -r w/o plugin
3) read LTO files into the compiler, link them and produce
incrementaly linked LTO object.

3 makes most sense and I am maing it new default for gcc -r. For testing
purposes
and perhaps in order to have tool to turn LTO object into real object, we want
to have 1) available as well. GCC currently have -flinker-output option that
decides between modes that is decided by linker plugin and can be overwritten
by user (I have forgot to document this).

I am targeting for -flinker-output=rel to be incremental linking into LTO
and adding -flinker-output=nolto-rel for 1).

The main limitation of 2 and 3 is that you can not link LTO and non-LTO
object files theger. For 2 HJ's binutils patchset has support and I think
it can be extended to handle 3 as well. But with default binutils we want
to warn users. This patch implements the warning (and prevents linker plugin
to add redundat linker-ouptut options.

This patch seems to have caused a lot of LTO tests in the G++ testsuite to
fail on bare-metal targets because of the new warning.
[snip]

I wonder what warning you get? There was PR about older binutils incorrectly
complaining about object file needing a plugin when IR object file is passed
after incremental link.
I do not think there is a way to silence this warning from GCC side.
We could use -flinker-output=nonlto-rel to avoid incremental linking in those
tests but eventually we will want some test coverage :)

It is exactly the warning newly added by this patch.

/scratch/sandra/arm-eabi-upstream/install/lib/gcc/arm-none-eabi/9.0.0/../../../../arm-none-eabi/bin/ld:
warning: incremental linking of LTO and non-LTO objects; using
-flinker-output=nolto-rel which will bypass whole program optimization

I built a completely fresh arm-none-eabi toolchain with a brand-new
binutils-gdb trunk checkout, so this isn't a problem with an old binutils.

-Sandra

[10/n] PR85694: Split out check for vectorizable associative reductions

This patch adds an overload of vect_reassociating_reduction_p
that checks for a vectorizable associative reduction,
since the check was duplicated in three functions.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-patterns.c (vect_reassociating_reduction_p): New function.
(vect_recog_dot_prod_pattern, vect_recog_sad_pattern)
(vect_recog_widen_sum_pattern): Use it.

Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-18 15:44:05.522927566 +0100
+++ gcc/tree-vect-patterns.c2018-06-18 15:44:24.922756050 +0100
@@ -242,6 +242,36 @@ vect_reassociating_reduction_p (stmt_vec
  : REDUC_GROUP_FIRST_ELEMENT (stmt_vinfo) != NULL);
 }
 
+/* As above, but also require it to have code CODE and to be a reduction
+   in the outermost loop.  When returning true, store the operands in
+   *OP0_OUT and *OP1_OUT.  */
+
+static bool
+vect_reassociating_reduction_p (stmt_vec_info stmt_info, tree_code code,
+   tree *op0_out, tree *op1_out)
+{
+  loop_vec_info loop_info = STMT_VINFO_LOOP_VINFO (stmt_info);
+  if (!loop_info)
+return false;
+
+  gassign *assign = dyn_cast  (stmt_info->stmt);
+  if (!assign || gimple_assign_rhs_code (assign) != code)
+return false;
+
+  /* We don't allow changing the order of the computation in the inner-loop
+ when doing outer-loop vectorization.  */
+  struct loop *loop = LOOP_VINFO_LOOP (loop_info);
+  if (loop && nested_in_vect_loop_p (loop, assign))
+return false;
+
+  if (!vect_reassociating_reduction_p (stmt_info))
+return false;
+
+  *op0_out = gimple_assign_rhs1 (assign);
+  *op1_out = gimple_assign_rhs2 (assign);
+  return true;
+}
+
 /* Function vect_recog_dot_prod_pattern
 
Try to find the following pattern:
@@ -296,26 +326,9 @@ vect_recog_dot_prod_pattern (vec *s
   stmt_vec_info stmt_vinfo = vinfo_for_stmt (last_stmt);
   vec_info *vinfo = stmt_vinfo->vinfo;
   tree half_type;
-  loop_vec_info loop_info = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
-  struct loop *loop;
   bool promotion;
 
-  if (!loop_info)
-return NULL;
-
-  loop = LOOP_VINFO_LOOP (loop_info);
-
-  /* We don't allow changing the order of the computation in the inner-loop
- when doing outer-loop vectorization.  */
-  if (loop && nested_in_vect_loop_p (loop, last_stmt))
-return NULL;
-
-  if (!is_gimple_assign (last_stmt))
-return NULL;
-
-  tree sum_type = gimple_expr_type (last_stmt);
-
   /* Look for the following pattern
   DX = (TYPE1) X;
   DY = (TYPE1) Y;
@@ -520,19 +513,15 @@ vect_recog_sad_pattern (vec *s
   /* Starting from LAST_STMT, follow the defs of its uses in search
  of the above pattern.  */
 
-  if (gimple_assign_rhs_code (last_stmt) != PLUS_EXPR)
-return NULL;
-
-  tree plus_oprnd0, plus_oprnd1;
-
   if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
 return NULL;
 
-  if (!vect_reassociating_reduction_p (stmt_vinfo))
+  tree plus_oprnd0, plus_oprnd1;
+  if (!vect_reassociating_reduction_p (stmt_vinfo, PLUS_EXPR,
+  _oprnd0, _oprnd1))
 return NULL;
 
-  plus_oprnd0 = gimple_assign_rhs1 (last_stmt);
-  plus_oprnd1 = gimple_assign_rhs2 (last_stmt);
+  tree sum_type = gimple_expr_type (last_stmt);
 
   /* The type conversion could be promotion, demotion,
  or just signed -> unsigned.  */
@@ -1136,26 +1125,12 @@ vect_recog_widen_sum_pattern (vec

[9/n] PR85694: Add a vect_look_through_pattern helper

When following the definitions of SSA names, some recognisers
already cope with statements that have been replaced by patterns.
This patch makes that happen automatically for users of
type_conversion_p and vect_get_internal_def.  It also adds
a vect_look_through_pattern helper that can be used directly.

The reason for doing this is that the main patch for PR85694
makes over_widening handle more general cases.  These over-widened
patterns can still be useful when matching later statements;
e.g. an overwidened MULT_EXPR could be the input to a DOT_PROD_EXPR.

The patch doesn't do anything with the STMT_VINFO_IN_PATTERN_P checks
in vect_recog_over_widening_pattern or vect_recog_widen_shift_pattern
since later patches rewrite them anyway.

Doing this fixed an XFAIL in vect-reduc-dot-u16b.c.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vectorizer.h (vect_look_through_pattern): New function.
* tree-vect-patterns.c (vect_get_internal_def): Use it.
(type_conversion_p): Likewise.
(vect_recog_rotate_pattern): Likewise.
(vect_recog_dot_prod_pattern): Check directly for a WIDEN_MULT_EXPR.
(vect_recog_vector_vector_shift_pattern): Don't check
STMT_VINFO_IN_PATTERN_P.

gcc/testsuite/
* gcc.dg/vect/vect-reduc-dot-u16b.c: Remove xfail and update the
test for vectorization along the lines described in the comment.

Index: gcc/tree-vectorizer.h
===
--- gcc/tree-vectorizer.h   2018-06-18 15:43:52.951038712 +0100
+++ gcc/tree-vectorizer.h   2018-06-18 15:44:05.522927566 +0100
@@ -1422,6 +1422,19 @@ vect_get_scalar_dr_size (struct data_ref
   return tree_to_uhwi (TYPE_SIZE_UNIT (TREE_TYPE (DR_REF (dr;
 }
 
+/* STMT is a statement that we're thinking about vectorizing.
+   If it has been replaced by a pattern statement, return that
+   pattern statement, otherwise return STMT itself.  */
+
+inline gimple *
+vect_look_through_pattern (gimple *stmt)
+{
+  stmt_vec_info vinfo = vinfo_for_stmt (stmt);
+  if (STMT_VINFO_IN_PATTERN_P (vinfo))
+stmt = STMT_VINFO_RELATED_STMT (vinfo);
+  return stmt;
+}
+
 /* Source location */
 extern source_location vect_location;
 
Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-18 15:43:52.951038712 +0100
+++ gcc/tree-vect-patterns.c2018-06-18 15:44:05.522927566 +0100
@@ -164,7 +164,7 @@ vect_get_internal_def (vec_info *vinfo,
   || dt != vect_internal_def)
 return NULL;
 
-  return vinfo_for_stmt (def_stmt);
+  return vinfo_for_stmt (vect_look_through_pattern (def_stmt));
 }
 
 /* Check whether NAME, an ssa-name used in USE_STMT,
@@ -195,12 +195,7 @@ type_conversion_p (tree name, gimple *us
 return false;
 
   if (dt == vect_internal_def)
-{
-  stmt_vec_info def_vinfo = vinfo_for_stmt (*def_stmt);
-  if (STMT_VINFO_IN_PATTERN_P (def_vinfo))
-   return false;
-}
-
+*def_stmt = vect_look_through_pattern (*def_stmt);
   if (!is_gimple_assign (*def_stmt))
 return false;
 
@@ -384,20 +379,11 @@ vect_recog_dot_prod_pattern (vec (mult_vinfo->stmt);
-  if (!mult || gimple_assign_rhs_code (mult) != MULT_EXPR)
+  if (!mult)
 return NULL;
-  if (STMT_VINFO_IN_PATTERN_P (mult_vinfo))
+  if (gimple_assign_rhs_code (mult) == WIDEN_MULT_EXPR)
 {
   /* Has been detected as a widening multiplication?  */
-
-  mult = dyn_cast  (STMT_VINFO_RELATED_STMT (mult_vinfo));
-  if (!mult || gimple_assign_rhs_code (mult) != WIDEN_MULT_EXPR)
-return NULL;
-  STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo)
-   = STMT_VINFO_PATTERN_DEF_SEQ (mult_vinfo);
-  mult_vinfo = vinfo_for_stmt (mult);
-  gcc_assert (mult_vinfo);
-  gcc_assert (STMT_VINFO_DEF_TYPE (mult_vinfo) == vect_internal_def);
   oprnd00 = gimple_assign_rhs1 (mult);
   oprnd01 = gimple_assign_rhs2 (mult);
 }
@@ -407,6 +393,9 @@ vect_recog_dot_prod_pattern (vec
   && dt != vect_external_def)
 return NULL;
 
+  if (dt == vect_internal_def)
+def_stmt = vect_look_through_pattern (def_stmt);
+
   vectype = get_vectype_for_scalar_type (type);
   if (vectype == NULL_TREE)
 return NULL;
@@ -2051,9 +2043,7 @@ vect_recog_vector_vector_shift_pattern (
 
   tree def = NULL_TREE;
   gassign *def_stmt = dyn_cast  (def_vinfo->stmt);
-  if (!STMT_VINFO_IN_PATTERN_P (def_vinfo)
-  && def_stmt
-  && gimple_assign_cast_p (def_stmt))
+  if (def_stmt && gimple_assign_cast_p (def_stmt))
 {
   tree rhs1 = gimple_assign_rhs1 (def_stmt);
   if (TYPE_MODE (TREE_TYPE (rhs1)) == TYPE_MODE (TREE_TYPE (oprnd0))
Index: gcc/testsuite/gcc.dg/vect/vect-reduc-dot-u16b.c
===
--- gcc/testsuite/gcc.dg/vect/vect-reduc-dot-u16b.c 2016-11-11 
17:07:36.588798042 +
+++

[8/n] PR85694: Make patterns check for target support

This patch makes pattern recognisers do their own checking for vector
types and target support.  Previously some recognisers did this
themselves and some left it to vect_pattern_recog_1.

Doing this means we can get rid of the type_in argument, which was
ignored if the recogniser did its own checking.  It also means
we create fewer junk statements.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vectorizer.h (NUM_PATTERNS, vect_recog_func_ptr): Move to
tree-vect-patterns.c.
* tree-vect-patterns.c (vect_supportable_direct_optab_p): New function.
(vect_recog_dot_prod_pattern): Use it.  Remove the type_in argument.
(vect_recog_sad_pattern): Likewise.
(vect_recog_widen_sum_pattern): Likewise.
(vect_recog_pow_pattern): Likewise.  Check for a null vectype.
(vect_recog_widen_shift_pattern): Remove the type_in argument.
(vect_recog_rotate_pattern): Likewise.
(vect_recog_mult_pattern): Likewise.
(vect_recog_vector_vector_shift_pattern): Likewise.
(vect_recog_divmod_pattern): Likewise.
(vect_recog_mixed_size_cond_pattern): Likewise.
(vect_recog_bool_pattern): Likewise.
(vect_recog_mask_conversion_pattern): Likewise.
(vect_try_gather_scatter_pattern): Likewise.
(vect_recog_widen_mult_pattern): Likewise.  Check for a null vectype.
(vect_recog_over_widening_pattern): Likewise.
(vect_recog_gather_scatter_pattern): Likewise.
(vect_recog_func_ptr): Move from tree-vectorizer.h
(vect_vect_recog_func_ptrs): Move further down the file.
(vect_recog_func): Likewise.  Remove the third argument.
(NUM_PATTERNS): Define based on vect_vect_recog_func_ptrs.
(vect_pattern_recog_1): Expect the pattern function to do any
necessary target tests.  Also expect it to provide a vector type.
Remove the type_in handling.

Index: gcc/tree-vectorizer.h
===
--- gcc/tree-vectorizer.h   2018-06-14 12:27:34.104084473 +0100
+++ gcc/tree-vectorizer.h   2018-06-18 15:43:52.951038712 +0100
@@ -1616,8 +1616,6 @@ extern int vect_get_place_in_interleavin
 /* Pattern recognition functions.
Additional pattern recognition functions can (and will) be added
in the future.  */
-typedef gimple *(* vect_recog_func_ptr) (vec *, tree *, tree *);
-#define NUM_PATTERNS 15
 void vect_pattern_recog (vec_info *);
 
 /* In tree-vectorizer.c.  */
Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-18 15:43:52.0 +0100
+++ gcc/tree-vect-patterns.c2018-06-18 15:43:52.951038712 +0100
@@ -47,66 +47,6 @@ Software Foundation; either version 3, o
 #include "omp-simd-clone.h"
 #include "predict.h"
 
-/* Pattern recognition functions  */
-static gimple *vect_recog_widen_sum_pattern (vec *, tree *,
-   tree *);
-static gimple *vect_recog_widen_mult_pattern (vec *, tree *,
-tree *);
-static gimple *vect_recog_dot_prod_pattern (vec *, tree *,
-  tree *);
-static gimple *vect_recog_sad_pattern (vec *, tree *,
- tree *);
-static gimple *vect_recog_pow_pattern (vec *, tree *, tree *);
-static gimple *vect_recog_over_widening_pattern (vec *, tree *,
- tree *);
-static gimple *vect_recog_widen_shift_pattern (vec *,
-   tree *, tree *);
-static gimple *vect_recog_rotate_pattern (vec *, tree *, tree *);
-static gimple *vect_recog_vector_vector_shift_pattern (vec *,
- tree *, tree *);
-static gimple *vect_recog_divmod_pattern (vec *,
-tree *, tree *);
-
-static gimple *vect_recog_mult_pattern (vec *,
-  tree *, tree *);
-
-static gimple *vect_recog_mixed_size_cond_pattern (vec *,
- tree *, tree *);
-static gimple *vect_recog_bool_pattern (vec *, tree *, tree *);
-static gimple *vect_recog_mask_conversion_pattern (vec *, tree *, 
tree *);
-static gimple *vect_recog_gather_scatter_pattern (vec *, tree *,
- tree *);
-
-struct vect_recog_func
-{
-  vect_recog_func_ptr fn;
-  const char *name;
-};
-
-/* Note that ordering matters - the first pattern matching on a stmt
-   is taken which means usually the more complex one needs to preceed
-   the less comples onex (widen_sum only after dot_prod or sad for example).  
*/
-static vect_recog_func vect_vect_recog_func_ptrs[NUM_PATTERNS] = {
-  { vect_recog_widen_mult_pattern, "widen_mult" },
-  { vect_recog_dot_prod_pattern,

[7/n] PR85694: Add a vect_pattern_detected helper

This message is a long write-up for a patch that simply adds a common
routine for printing the "vector_foo_pattern: detected:" messages.

The reason for doing this is that some routines check for target support
themselves and some leave it to vect_pattern_recog_1.  Those that leave
it to vect_pattern_recog_1 currently print these "detected:" messages if
the statements have the right form, even if the pattern is eventually
discarded.  IMO that's useful, and a lot of existing scan tests rely on it.

However, a later patch makes patterns do their own testing, and stops
them creating pattern statements until the tests have passed.  This means
(a) they need to print the "detected:" message earlier and (b) the pattern
statement won't be around to print.

The patch therefore makes all routines print the original statement
rather than the pattern one.  That information isn't obvious otherwise,
whereas vect_pattern_recog_1 already prints the pattern statement
in the case of a successful match.  This also avoids the previous
situation in which a routine could print "detected:" and then
silently bail out before saying what had been detected.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-patterns.c (vect_pattern_detected): New function.
(vect_recog_dot_prod_patternm, vect_recog_sad_pattern)
(vect_recog_widen_mult_pattern, vect_recog_widen_sum_pattern)
(vect_recog_over_widening_pattern, vect_recog_widen_shift_pattern
(vect_recog_rotate_pattern, vect_recog_vector_vector_shift_pattern)
(vect_recog_mult_pattern, vect_recog_divmod_pattern)
(vect_recog_mixed_size_cond_pattern, vect_recog_bool_pattern)
(vect_recog_mask_conversion_pattern)
(vect_try_gather_scatter_pattern): Likewise.

Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-18 15:41:33.332272879 +0100
+++ gcc/tree-vect-patterns.c2018-06-18 15:43:18.327344801 +0100
@@ -107,6 +107,19 @@ static vect_recog_func vect_vect_recog_f
   {vect_recog_mask_conversion_pattern, "mask_conversion" }
 };
 
+/* Report that we've found an instance of pattern PATTERN in
+   statement STMT.  */
+
+static void
+vect_pattern_detected (const char *name, gimple *stmt)
+{
+  if (dump_enabled_p ())
+{
+  dump_printf_loc (MSG_NOTE, vect_location, "%s: detected: ", name);
+  dump_gimple_stmt (MSG_NOTE, TDF_SLIM, stmt, 0);
+}
+}
+
 static inline void
 append_pattern_def_seq (stmt_vec_info stmt_info, gimple *stmt)
 {
@@ -432,22 +445,16 @@ vect_recog_dot_prod_pattern (vec *s
   || TYPE_PRECISION (sum_type) < TYPE_PRECISION (half_type0) * 2)
 return NULL;
 
+  vect_pattern_detected ("vect_recog_sad_pattern", last_stmt);
+
   *type_in = TREE_TYPE (sad_oprnd0);
   *type_out = sum_type;
 
-  /* Pattern detected. Create a stmt to be used to replace the pattern: */
   tree var = vect_recog_temp_ssa_var (sum_type, NULL);
   gimple *pattern_stmt = gimple_build_assign (var, SAD_EXPR, sad_oprnd0,
  sad_oprnd1, plus_oprnd1);
 
-  if (dump_enabled_p ())
-{
-  dump_printf_loc (MSG_NOTE, vect_location,
-   "vect_recog_sad_pattern: detected: ");
-  dump_gimple_stmt (MSG_NOTE, TDF_SLIM, pattern_stmt, 0);
-}
-
   return pattern_stmt;
 }
 
@@ -919,9 +920,7 @@ vect_recog_widen_mult_pattern (vecsafe_push (last_stmt);
   return pattern_stmt;
 }
@@ -1230,20 +1226,15 @@ vect_recog_widen_sum_pattern (veclast ());
 
   return pattern_stmt;
 }
@@ -1740,9 +1726,7 @@ vect_recog_widen_shift_pattern (vecsafe_push (last_stmt);
   return pattern_stmt;
 }
@@ -2010,17 +1991,12 @@ vect_recog_rotate_pattern (vec
   append_pattern_def_seq (stmt_vinfo, def_stmt);
 
   /* Pattern detected.  */
-  if (dump_enabled_p ())
-dump_printf_loc (MSG_NOTE, vect_location,
-"vect_recog_rotate_pattern: detected:\n");
+  vect_pattern_detected ("vect_recog_rotate_pattern", last_stmt);
 
   /* Pattern supported.  Create a stmt to be used to replace the pattern.  */
   var = vect_recog_temp_ssa_var (type, NULL);
   pattern_stmt = gimple_build_assign (var, BIT_IOR_EXPR, var1, var2);
 
-  if (dump_enabled_p ())
-dump_gimple_stmt_loc (MSG_NOTE, vect_location, TDF_SLIM, pattern_stmt, 0);
-
   stmts->safe_push (last_stmt);
   return pattern_stmt;
 }
@@ -2153,17 +2129,12 @@ vect_recog_vector_vector_shift_pattern (
 }
 
   /* Pattern detected.  */
-  if (dump_enabled_p ())
-dump_printf_loc (MSG_NOTE, vect_location,
- "vect_recog_vector_vector_shift_pattern: detected:\n");
+  vect_pattern_detected ("vect_recog_vector_vector_shift_pattern", last_stmt);
 
   /* Pattern supported.  Create a stmt to be used to replace the pattern.  */
   var = vect_recog_temp_ssa_var (TREE_TYPE (oprnd0), NULL);
   pattern_stmt = gimple_build_assign (var, rhs_code,

[6/n] PR85694: Add a vect_get_internal_def helper

This patch adds a helper for pattern code that wants to find an
internal (vectorisable) definition of an SSA name.

A later patch will make more use of this, and alter the definition.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-patterns.c (vect_get_internal_def): New function.
(vect_recog_dot_prod_pattern, vect_recog_sad_pattern)
(vect_recog_vector_vector_shift_pattern, check_bool_pattern)
(search_type_for_mask_1): Use it.

Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-18 15:41:33.0 +0100
+++ gcc/tree-vect-patterns.c2018-06-18 15:41:33.332272879 +0100
@@ -155,6 +155,22 @@ vect_single_imm_use (gimple *def_stmt)
   return use_stmt;
 }
 
+/* If OP is defined by a statement that's being considered for vectorization,
+   return information about that statement, otherwise return NULL.  */
+
+static stmt_vec_info
+vect_get_internal_def (vec_info *vinfo, tree op)
+{
+  vect_def_type dt;
+  gimple *def_stmt;
+  if (TREE_CODE (op) != SSA_NAME
+  || !vect_is_simple_use (op, vinfo, _stmt, )
+  || dt != vect_internal_def)
+return NULL;
+
+  return vinfo_for_stmt (def_stmt);
+}
+
 /* Check whether NAME, an ssa-name used in USE_STMT,
is a result of a type promotion, such that:
  DEF_STMT: NAME = NOP (name0)
@@ -288,6 +304,7 @@ vect_recog_dot_prod_pattern (vecvinfo;
   tree type, half_type;
   gimple *pattern_stmt;
   tree prod_type;
@@ -367,36 +384,29 @@ vect_recog_dot_prod_pattern (vec (mult_vinfo->stmt);
+  if (!mult || gimple_assign_rhs_code (mult) != MULT_EXPR)
 return NULL;
-  stmt_vinfo = vinfo_for_stmt (stmt);
-  gcc_assert (stmt_vinfo);
-  if (STMT_VINFO_DEF_TYPE (stmt_vinfo) != vect_internal_def)
-return NULL;
-  if (gimple_assign_rhs_code (stmt) != MULT_EXPR)
-return NULL;
-  if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
+  if (STMT_VINFO_IN_PATTERN_P (mult_vinfo))
 {
   /* Has been detected as a widening multiplication?  */
 
-  stmt = STMT_VINFO_RELATED_STMT (stmt_vinfo);
-  if (gimple_assign_rhs_code (stmt) != WIDEN_MULT_EXPR)
+  mult = dyn_cast  (STMT_VINFO_RELATED_STMT (mult_vinfo));
+  if (!mult || gimple_assign_rhs_code (mult) != WIDEN_MULT_EXPR)
 return NULL;
-  STMT_VINFO_PATTERN_DEF_SEQ (vinfo_for_stmt (last_stmt))
-   = STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo);
-  stmt_vinfo = vinfo_for_stmt (stmt);
-  gcc_assert (stmt_vinfo);
-  gcc_assert (STMT_VINFO_DEF_TYPE (stmt_vinfo) == vect_internal_def);
-  oprnd00 = gimple_assign_rhs1 (stmt);
-  oprnd01 = gimple_assign_rhs2 (stmt);
+  STMT_VINFO_PATTERN_DEF_SEQ (stmt_vinfo)
+   = STMT_VINFO_PATTERN_DEF_SEQ (mult_vinfo);
+  mult_vinfo = vinfo_for_stmt (mult);
+  gcc_assert (mult_vinfo);
+  gcc_assert (STMT_VINFO_DEF_TYPE (mult_vinfo) == vect_internal_def);
+  oprnd00 = gimple_assign_rhs1 (mult);
+  oprnd01 = gimple_assign_rhs2 (mult);
 }
   else
 {
@@ -404,14 +414,14 @@ vect_recog_dot_prod_pattern (vec *s
   gimple *last_stmt = (*stmts)[0];
   tree sad_oprnd0, sad_oprnd1;
   stmt_vec_info stmt_vinfo = vinfo_for_stmt (last_stmt);
+  vec_info *vinfo = stmt_vinfo->vinfo;
   tree half_type;
   loop_vec_info loop_info = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
   struct loop *loop;
@@ -567,23 +578,16 @@ vect_recog_sad_pattern (vec *s
 return NULL;
 
   tree abs_type = half_type;
-  gimple *abs_stmt = SSA_NAME_DEF_STMT (plus_oprnd0);
-
-  /* It could not be the sad pattern if the abs_stmt is outside the loop.  */
-  if (!gimple_bb (abs_stmt) || !flow_bb_inside_loop_p (loop, gimple_bb 
(abs_stmt)))
+  stmt_vec_info abs_stmt_vinfo = vect_get_internal_def (vinfo, plus_oprnd0);
+  if (!abs_stmt_vinfo)
 return NULL;
 
   /* FORNOW.  Can continue analyzing the def-use chain when this stmt in a phi
  inside the loop (in case we are analyzing an outer-loop).  */
-  if (!is_gimple_assign (abs_stmt))
-return NULL;
-
-  stmt_vec_info abs_stmt_vinfo = vinfo_for_stmt (abs_stmt);
-  gcc_assert (abs_stmt_vinfo);
-  if (STMT_VINFO_DEF_TYPE (abs_stmt_vinfo) != vect_internal_def)
-return NULL;
-  if (gimple_assign_rhs_code (abs_stmt) != ABS_EXPR
-  && gimple_assign_rhs_code (abs_stmt) != ABSU_EXPR)
+  gassign *abs_stmt = dyn_cast  (abs_stmt_vinfo->stmt);
+  if (!abs_stmt
+  || (gimple_assign_rhs_code (abs_stmt) != ABS_EXPR
+ && gimple_assign_rhs_code (abs_stmt) != ABSU_EXPR))
 return NULL;
 
   tree abs_oprnd = gimple_assign_rhs1 (abs_stmt);
@@ -595,23 +599,14 @@ vect_recog_sad_pattern (vec *s
   if (TREE_CODE (abs_oprnd) != SSA_NAME)
 return NULL;
 
-  gimple *diff_stmt = SSA_NAME_DEF_STMT (abs_oprnd);
-
-  /* It could not be the sad pattern if the diff_stmt is outside the loop.  */
-  if (!gimple_bb (diff_stmt)
-  || !flow_bb_inside_loop_p (loop, gimple_bb (diff_stmt)))
+  stmt_vec_info

[5/n] PR85694: Remove dead WIDEN_SUM handling

vect_recog_dot_prod_pattern and vect_recog_sad_pattern both checked
whether the statement passed in had already been recognised as a
WIDEN_SUM_EXPR pattern.  That isn't possible (any more?), since the
first recognised pattern wins, and since vect_recog_widen_sum_pattern
never matches a later statement than the one it's given.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Remove
redundant WIDEN_SUM_EXPR handling.
(vect_recog_sad_pattern): Likewise.

Index: gcc/tree-vect-patterns.c
===
*** gcc/tree-vect-patterns.c2018-06-18 15:56:12.908496017 +0100
--- gcc/tree-vect-patterns.c2018-06-18 15:56:12.904496052 +0100
*** vect_recog_dot_prod_pattern (vec *s
*** 553,586 
tree plus_oprnd0, plus_oprnd1;
  
if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
! {
!   /* Has been detected as widening-summation?  */
  
!   gimple *stmt = STMT_VINFO_RELATED_STMT (stmt_vinfo);
!   sum_type = gimple_expr_type (stmt);
!   if (gimple_assign_rhs_code (stmt) != WIDEN_SUM_EXPR)
! return NULL;
!   plus_oprnd0 = gimple_assign_rhs1 (stmt);
!   plus_oprnd1 = gimple_assign_rhs2 (stmt);
!   half_type = TREE_TYPE (plus_oprnd0);
! }
!   else
! {
!   gimple *def_stmt;
  
!   if (!vect_reassociating_reduction_p (stmt_vinfo))
!   return NULL;
!   plus_oprnd0 = gimple_assign_rhs1 (last_stmt);
!   plus_oprnd1 = gimple_assign_rhs2 (last_stmt);
  
!   /* The type conversion could be promotion, demotion,
!  or just signed -> unsigned.  */
!   if (type_conversion_p (plus_oprnd0, last_stmt, false,
!  _type, _stmt, ))
! plus_oprnd0 = gimple_assign_rhs1 (def_stmt);
!   else
! half_type = sum_type;
! }
  
/* So far so good.  Since last_stmt was detected as a (summation) reduction,
   we know that plus_oprnd1 is the reduction variable (defined by a 
loop-header
--- 541,562 
tree plus_oprnd0, plus_oprnd1;
  
if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
! return NULL;
  
!   if (!vect_reassociating_reduction_p (stmt_vinfo))
! return NULL;
  
!   plus_oprnd0 = gimple_assign_rhs1 (last_stmt);
!   plus_oprnd1 = gimple_assign_rhs2 (last_stmt);
  
!   /* The type conversion could be promotion, demotion,
!  or just signed -> unsigned.  */
!   gimple *def_stmt;
!   if (type_conversion_p (plus_oprnd0, last_stmt, false,
!_type, _stmt, ))
! plus_oprnd0 = gimple_assign_rhs1 (def_stmt);
!   else
! half_type = sum_type;
  
/* So far so good.  Since last_stmt was detected as a (summation) reduction,
   we know that plus_oprnd1 is the reduction variable (defined by a 
loop-header
*** vect_recog_sad_pattern (vec *s
*** 639,645 
  return NULL;
  
tree half_type0, half_type1;
-   gimple *def_stmt;
  
tree minus_oprnd0 = gimple_assign_rhs1 (diff_stmt);
tree minus_oprnd1 = gimple_assign_rhs2 (diff_stmt);
--- 615,620

[4/n] PR85694:Remove redundant calls to types_compatible_p

tree-vect-patterns.c checked that operands to primitive arithmetic ops
are compatible with each other and with the result.  The checks date
back years and have long been redundant with verify_gimple_stmt.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Remove
redundant check that the types of a PLUS_EXPR or MULT_EXPR agree.
(vect_recog_sad_pattern): Likewise PLUS_EXPR, ABS_EXPR and MINUS_EXPR.
(vect_recog_widen_mult_pattern): Likewise MULT_EXPR.
(vect_recog_widen_sum_pattern): Likewise PLUS_EXPR.

Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-18 15:24:21.001379616 +0100
+++ gcc/tree-vect-patterns.c2018-06-18 15:24:49.829125450 +0100
@@ -358,9 +358,6 @@ vect_recog_dot_prod_pattern (vec *s
return NULL;
   plus_oprnd0 = gimple_assign_rhs1 (last_stmt);
   plus_oprnd1 = gimple_assign_rhs2 (last_stmt);
-  if (!types_compatible_p (TREE_TYPE (plus_oprnd0), sum_type)
- || !types_compatible_p (TREE_TYPE (plus_oprnd1), sum_type))
-return NULL;
 
   /* The type conversion could be promotion, demotion,
  or just signed -> unsigned.  */
@@ -620,8 +611,6 @@ vect_recog_sad_pattern (vec *s
 return NULL;
 
   tree abs_oprnd = gimple_assign_rhs1 (abs_stmt);
-  if (!types_compatible_p (TREE_TYPE (abs_oprnd), abs_type))
-return NULL;
   if (TYPE_UNSIGNED (abs_type))
 return NULL;
 
@@ -655,9 +644,6 @@ vect_recog_sad_pattern (vec *s
   tree minus_oprnd0 = gimple_assign_rhs1 (diff_stmt);
   tree minus_oprnd1 = gimple_assign_rhs2 (diff_stmt);
 
-  if (!types_compatible_p (TREE_TYPE (minus_oprnd0), abs_type)
-  || !types_compatible_p (TREE_TYPE (minus_oprnd1), abs_type))
-return NULL;
   if (!type_conversion_p (minus_oprnd0, diff_stmt, false,
   _type0, _stmt, )
   || !promotion)
@@ -862,9 +848,6 @@ vect_recog_widen_mult_pattern (vec

[3/n] PR85694: Fix dummy assignment handling in vectorizable_call

vectorizable_call stubs out the original scalar statement with
a dummy assignment to the same lhs, so that we don't leave any bogus
scalar calls around.  If the call is actually a pattern statement,
the code rightly took the lhs of the original bb statement:

  if (is_pattern_stmt_p (stmt_info))
lhs = gimple_call_lhs (STMT_VINFO_RELATED_STMT (stmt_info));
  else
lhs = gimple_call_lhs (stmt);

But it then associated the new statement with the stmt_vec_info of the
pattern statement rather than the bb statement, which meant we had two
stmt_vec_infos assigning to the same lhs.  This seems to be latent at
the moment but caused problems further into the series.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-stmts.c (vectorizable_call): Make sure that we
use the stmt_vec_info of the original bb statement for the
new zero assignment, even if the call is part of a pattern.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   2018-06-18 15:24:21.005379580 +0100
+++ gcc/tree-vect-stmts.c   2018-06-18 15:24:35.165254737 +0100
@@ -3611,13 +3611,12 @@ vectorizable_call (gimple *gs, gimple_st
 
   type = TREE_TYPE (scalar_dest);
   if (is_pattern_stmt_p (stmt_info))
-lhs = gimple_call_lhs (STMT_VINFO_RELATED_STMT (stmt_info));
-  else
-lhs = gimple_call_lhs (stmt);
+stmt_info = vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info));
+  lhs = gimple_get_lhs (stmt_info->stmt);
 
   new_stmt = gimple_build_assign (lhs, build_zero_cst (type));
   set_vinfo_for_stmt (new_stmt, stmt_info);
-  set_vinfo_for_stmt (stmt, NULL);
+  set_vinfo_for_stmt (stmt_info->stmt, NULL);
   STMT_VINFO_STMT (stmt_info) = new_stmt;
   gsi_replace (gsi, new_stmt, false);

[2/n] PR85694: Attach a DEF_SEQ only to the original statement

A pattern's PATTERN_DEF_SEQ was attached to both the original statement
and the main pattern statement, which made it harder to update later.
This patch attaches it to just the original statement.  In practice,
anything that cared had ready access to both.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-loop.c (vect_determine_vf_for_stmt): Take the
PATTERN_DEF_SEQ from the original statement rather than
the main pattern statement.
* tree-vect-stmts.c (free_stmt_vec_info): Likewise.
* tree-vect-patterns.c (vect_recog_dot_prod_pattern): Likewise.
(vect_mark_pattern_stmts): Don't copy the PATTERN_DEF_SEQ.

Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c2018-06-18 15:24:10.457472575 +0100
+++ gcc/tree-vect-loop.c2018-06-18 15:24:21.001379616 +0100
@@ -224,10 +224,10 @@ vect_determine_vf_for_stmt (stmt_vec_inf
   if (STMT_VINFO_IN_PATTERN_P (stmt_info)
   && STMT_VINFO_RELATED_STMT (stmt_info))
 {
+  gimple *pattern_def_seq = STMT_VINFO_PATTERN_DEF_SEQ (stmt_info);
   stmt_info = vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info));
 
   /* If a pattern statement has def stmts, analyze them too.  */
-  gimple *pattern_def_seq = STMT_VINFO_PATTERN_DEF_SEQ (stmt_info);
   for (gimple_stmt_iterator si = gsi_start (pattern_def_seq);
   !gsi_end_p (si); gsi_next ())
{
@@ -2259,10 +2259,10 @@ vect_analyze_loop_2 (loop_vec_info loop_
  STMT_SLP_TYPE (stmt_info) = loop_vect;
  if (STMT_VINFO_IN_PATTERN_P (stmt_info))
{
+ gimple *pattern_def_seq = STMT_VINFO_PATTERN_DEF_SEQ (stmt_info);
  stmt_info = vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info));
  STMT_SLP_TYPE (stmt_info) = loop_vect;
- for (gimple_stmt_iterator pi
-= gsi_start (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info));
+ for (gimple_stmt_iterator pi = gsi_start (pattern_def_seq);
   !gsi_end_p (pi); gsi_next ())
{
  gimple *pstmt = gsi_stmt (pi);
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   2018-06-18 15:24:10.461472540 +0100
+++ gcc/tree-vect-stmts.c   2018-06-18 15:24:21.005379580 +0100
@@ -9892,29 +9892,26 @@ free_stmt_vec_info (gimple *stmt)
  too.  */
   if (STMT_VINFO_IN_PATTERN_P (stmt_info))
 {
+  if (gimple_seq seq = STMT_VINFO_PATTERN_DEF_SEQ (stmt_info))
+   for (gimple_stmt_iterator si = gsi_start (seq);
+!gsi_end_p (si); gsi_next ())
+ {
+   gimple *seq_stmt = gsi_stmt (si);
+   gimple_set_bb (seq_stmt, NULL);
+   tree lhs = gimple_get_lhs (seq_stmt);
+   if (lhs && TREE_CODE (lhs) == SSA_NAME)
+ release_ssa_name (lhs);
+   free_stmt_vec_info (seq_stmt);
+ }
   stmt_vec_info patt_info
= vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info));
   if (patt_info)
{
- gimple_seq seq = STMT_VINFO_PATTERN_DEF_SEQ (patt_info);
  gimple *patt_stmt = STMT_VINFO_STMT (patt_info);
  gimple_set_bb (patt_stmt, NULL);
  tree lhs = gimple_get_lhs (patt_stmt);
  if (lhs && TREE_CODE (lhs) == SSA_NAME)
release_ssa_name (lhs);
- if (seq)
-   {
- gimple_stmt_iterator si;
- for (si = gsi_start (seq); !gsi_end_p (si); gsi_next ())
-   {
- gimple *seq_stmt = gsi_stmt (si);
- gimple_set_bb (seq_stmt, NULL);
- lhs = gimple_get_lhs (seq_stmt);
- if (lhs && TREE_CODE (lhs) == SSA_NAME)
-   release_ssa_name (lhs);
- free_stmt_vec_info (seq_stmt);
-   }
-   }
  free_stmt_vec_info (patt_stmt);
}
 }
Index: gcc/tree-vect-patterns.c
===
--- gcc/tree-vect-patterns.c2018-06-18 15:22:36.898297310 +0100
+++ gcc/tree-vect-patterns.c2018-06-18 15:24:21.001379616 +0100
@@ -405,13 +405,13 @@ vect_recog_dot_prod_pattern (vec

[1/n] PR85694: Allow pattern definition statements to be reused

This patch is the first part of a series to fix to PR85694.
Later patches can make the pattern for a statement S2 reuse the
results of a PATTERN_DEF_SEQ statement attached to an earlier
statement S1.  Although vect_mark_stmts_to_be_vectorized handled
this fine, vect_analyze_stmt and vect_transform_loop both skipped the
PATTERN_DEF_SEQ for S1 if S1's main pattern wasn't live or relevant.

I couldn't wrap my head around the flow in vect_transform_loop,
so ended up moving the per-statement handling into a subroutine.
That makes the patch look bigger than it actually is.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-06-18  Richard Sandiford  

gcc/
* tree-vect-stmts.c (vect_analyze_stmt): Move the handling of pattern
definition statements before the early exit for statements that aren't
live or relevant.
* tree-vect-loop.c (vect_transform_loop_stmt): New function,
split out from...
(vect_transform_loop): ...here.  Process pattern definition
statements without first checking whether the main pattern
statement is live or relevant.

Index: gcc/tree-vect-stmts.c
===
*** gcc/tree-vect-stmts.c   2018-06-18 15:50:55.607303415 +0100
--- gcc/tree-vect-stmts.c   2018-06-18 15:50:55.603303451 +0100
*** vect_analyze_stmt (gimple *stmt, bool *n
*** 9409,9414 
--- 9409,9442 
return false;
  }
  
+   if (STMT_VINFO_IN_PATTERN_P (stmt_info)
+   && node == NULL
+   && (pattern_def_seq = STMT_VINFO_PATTERN_DEF_SEQ (stmt_info)))
+ {
+   gimple_stmt_iterator si;
+ 
+   for (si = gsi_start (pattern_def_seq); !gsi_end_p (si); gsi_next ())
+   {
+ gimple *pattern_def_stmt = gsi_stmt (si);
+ if (STMT_VINFO_RELEVANT_P (vinfo_for_stmt (pattern_def_stmt))
+ || STMT_VINFO_LIVE_P (vinfo_for_stmt (pattern_def_stmt)))
+   {
+ /* Analyze def stmt of STMT if it's a pattern stmt.  */
+ if (dump_enabled_p ())
+   {
+ dump_printf_loc (MSG_NOTE, vect_location,
+  "==> examining pattern def statement: ");
+ dump_gimple_stmt (MSG_NOTE, TDF_SLIM, pattern_def_stmt, 0);
+   }
+ 
+ if (!vect_analyze_stmt (pattern_def_stmt,
+ need_to_vectorize, node, node_instance,
+ cost_vec))
+   return false;
+   }
+   }
+ }
+ 
/* Skip stmts that do not need to be vectorized. In loops this is expected
   to include:
   - the COND_EXPR which is the loop exit condition
*** vect_analyze_stmt (gimple *stmt, bool *n
*** 9469,9502 
  return false;
 }
  
-   if (is_pattern_stmt_p (stmt_info)
-   && node == NULL
-   && (pattern_def_seq = STMT_VINFO_PATTERN_DEF_SEQ (stmt_info)))
- {
-   gimple_stmt_iterator si;
- 
-   for (si = gsi_start (pattern_def_seq); !gsi_end_p (si); gsi_next ())
-   {
- gimple *pattern_def_stmt = gsi_stmt (si);
- if (STMT_VINFO_RELEVANT_P (vinfo_for_stmt (pattern_def_stmt))
- || STMT_VINFO_LIVE_P (vinfo_for_stmt (pattern_def_stmt)))
-   {
- /* Analyze def stmt of STMT if it's a pattern stmt.  */
- if (dump_enabled_p ())
-   {
- dump_printf_loc (MSG_NOTE, vect_location,
-"==> examining pattern def statement: ");
- dump_gimple_stmt (MSG_NOTE, TDF_SLIM, pattern_def_stmt, 0);
-   }
- 
- if (!vect_analyze_stmt (pattern_def_stmt,
- need_to_vectorize, node, node_instance,
- cost_vec))
-   return false;
-   }
-   }
- }
- 
switch (STMT_VINFO_DEF_TYPE (stmt_info))
  {
case vect_internal_def:
--- 9497,9502 
Index: gcc/tree-vect-loop.c
===
*** gcc/tree-vect-loop.c2018-06-18 15:50:55.607303415 +0100
--- gcc/tree-vect-loop.c2018-06-18 15:50:55.603303451 +0100
*** scale_profile_for_vect_loop (struct loop
*** 8306,8311 
--- 8306,8381 
  scale_bbs_frequencies (>latch, 1, exit_l->probability / prob);
  }
  
+ /* Vectorize STMT if relevant, inserting any new instructions before GSI.
+When vectorizing STMT as a store, set *SEEN_STORE to its stmt_vec_info.
+*SLP_SCHEDULE is a running record of whether we have called
+vect_schedule_slp.  */
+ 
+ static void
+ vect_transform_loop_stmt (loop_vec_info loop_vinfo, gimple *stmt,
+ gimple_stmt_iterator *gsi,
+ stmt_vec_info *seen_store, bool *slp_scheduled)
+ {
+   struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+   poly_uint64 vf =

Re: [tree.c] Replace cast to (char *) by const_cast

On 06/18/2018 08:08 AM, Prathamesh Kulkarni wrote:
> On 18 June 2018 at 19:28, Nick Clifton  wrote:
>> Hi Prathamesh,
>>
>>> I am getting the following build error with trunk:
>>> ../../gcc/gcc/tree.c: In member function ‘void
>>> escaped_string::escape(const char*)’:
>>> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
>>> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
>>>m_str = (char *) unescaped;
>>> ^
>>> I think this is caused by r261697 in tree.c:
>>>   m_str = (char *) unescaped;
>>>
>>> The patch changes it to const_cast (unescaped) which fixes the
>>> build for me.
>>
>> I cannot approve this patch, but I can say thanks very much for catching
>> this problem and proposing a fix.  I guess that I must be using an old
>> version of g++ for my testing as this error did not show up. :-(
> Hi Nick,
> Thanks for confirming. I went ahead and committed the patch in r261700
> since I guess it's trivial enough to fit under the "obvious" rule.
Yes.

Thanks for taking care of it.

jeff

Re: [PATCH v2] C/C++: Add -Waddress-of-packed-member

On Fri, May 18, 2018 at 7:36 AM, H.J. Lu  wrote:
> On Thu, May 17, 2018 at 10:32:56AM -0700, H.J. Lu wrote:
>> On Mon, May 14, 2018 at 8:00 PM, Martin Sebor  wrote:
>> > On 05/14/2018 01:10 PM, H.J. Lu wrote:
>> >>
>> >> On Mon, May 14, 2018 at 10:40 AM, H.J. Lu  wrote:
>> >>
>> >> $ cat c.i
>> >> struct B { int i; };
>> >> struct C { struct B b; } __attribute__ ((packed));
>> >>
>> >> long* g8 (struct C *p) { return p; }
>> >> $ gcc -O2 -S c.i -Wno-incompatible-pointer-types
>> >> c.i: In function ‘g8’:
>> >> c.i:4:33: warning: taking value of packed 'struct C *' may result in
>> >> an
>> >> unaligned pointer value [-Waddress-of-packed-member]
>> 
>> 
>>   ^
>>  That should read "taking address" (not value) but...
>> >>>
>> >>>
>> >>> The value of 'struct C *' is an address. There is no address taken here.
>> >>>
>>  ...to help explain the problem I would suggest to mention the expected
>>  and actual alignment in the warning message.  E.g.,
>> 
>>    storing the address of a packed 'struct C' in 'struct C *' increases
>>  the
>>  alignment of the pointer from 1 to 4.
>> >>>
>> >>>
>> >>> I will take a look.
>> >>>
>>  (IIUC, the source type and destination type need not be the same so
>>  including both should be helpful in those cases.)
>> 
>>  Adding a note pointing to the declaration of either the struct or
>>  the member would help users find it if it's a header far removed
>>  from the point of use.
>> >>>
>> >>>
>> >>> I will see what I can do.
>> >>
>> >>
>> >> How about this
>> >>
>> >> [hjl@gnu-skx-1 pr51628]$ cat n9.i
>> >> struct B { int i; };
>> >> struct C { struct B b; } __attribute__ ((packed));
>> >>
>> >> long* g8 (struct C *p) { return p; }
>> >> [hjl@gnu-skx-1 pr51628]$
>> >> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
>> >> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n9.i
>> >> n9.i: In function ‘g8’:
>> >> n9.i:4:33: warning: returning ‘struct C *’ from a function with
>> >> incompatible return type ‘long int *’ [-Wincompatible-pointer-types]
>> >>  long* g8 (struct C *p) { return p; }
>> >>  ^
>> >> n9.i:4:33: warning: taking value of packed ‘struct C *’ increases the
>> >> alignment of the pointer from 1 to 8 [-Waddress-of-packed-member]
>> >> n9.i:2:8: note: defined here
>> >>  struct C { struct B b; } __attribute__ ((packed));
>> >
>> >
>> > Mentioning the alignments looks good.
>> >
>> > I still find the "taking value" phrasing odd.  I think we would
>> > describe what's going on as "converting a pointer to a packed C
>> > to a pointer to C (with an alignment of 8)" so I'd suggest to
>> > use the term converting instead.
>>
>> How about this?
>>
>> [hjl@gnu-skx-1 pr51628]$ cat n12.i
>> struct B { int i; };
>> struct C { struct B b; } __attribute__ ((packed));
>>
>> struct B* g8 (struct C *p) { return p; }
>> [hjl@gnu-skx-1 pr51628]$ make n12.s
>> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
>> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n12.i
>> n12.i: In function ‘g8’:
>> n12.i:4:37: warning: returning ‘struct C *’ from a function with
>> incompatible return type ‘struct B *’ [-Wincompatible-pointer-types]
>>  struct B* g8 (struct C *p) { return p; }
>>  ^
>> n12.i:4:37: warning: converting a pointer to packed ‘struct C *’
>> increases the alignment of the pointer to ‘struct B *’ from 1 to 4
>> [-Waddress-of-packed-member]
>> n12.i:2:8: note: defined here
>>  struct C { struct B b; } __attribute__ ((packed));
>> ^
>> n12.i:1:8: note: defined here
>>  struct B { int i; };
>> ^
>> [hjl@gnu-skx-1 pr51628]$
>>
>> > I also think mentioning both the source and the destination types
>> > is useful irrespective of -Wincompatible-pointer-types because
>> > the latter is often suppressed using a cast, as in:
>> >
>> >   struct __attribute__ ((packed)) A { int i; };
>> >   struct B {
>> > struct A a;
>> >   } b;
>> >
>> >   long *p = (long*)   // -Waddress-of-packed-member
>> >   int *q = (int*)   // missing warning
>> >
>> > If the types above were obfuscated by macros, typedefs, or in
>> > C++ template parameters, it could be difficult to figure out
>> > what the type of the member is because neither it nor the name
>> > of the member appears in the message.
>>
>> How about this
>>
>> [hjl@gnu-skx-1 pr51628]$ cat n13.i
>> struct __attribute__ ((packed)) A { int i; };
>> struct B {
>>   struct A a;
>> } b;
>>
>> long *p = (long*)
>> int *q = (int*)
>> [hjl@gnu-skx-1 pr51628]$ make n13.s
>> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
>> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2 -S n13.i
>> n13.i:6:18: warning: taking address of packed member of ‘struct A’ may
>> result in an unaligned pointer value [-Waddress-of-packed-member]
>>  long *p = (long*)
>>   ^~
>>

Re: [tree.c] Replace cast to (char *) by const_cast

2018-06-18 Thread Prathamesh Kulkarni

On 18 June 2018 at 19:28, Nick Clifton  wrote:
> Hi Prathamesh,
>
>> I am getting the following build error with trunk:
>> ../../gcc/gcc/tree.c: In member function ‘void
>> escaped_string::escape(const char*)’:
>> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
>> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
>>m_str = (char *) unescaped;
>> ^
>> I think this is caused by r261697 in tree.c:
>>   m_str = (char *) unescaped;
>>
>> The patch changes it to const_cast (unescaped) which fixes the
>> build for me.
>
> I cannot approve this patch, but I can say thanks very much for catching
> this problem and proposing a fix.  I guess that I must be using an old
> version of g++ for my testing as this error did not show up. :-(
Hi Nick,
Thanks for confirming. I went ahead and committed the patch in r261700
since I guess it's trivial enough to fit under the "obvious" rule.

Thanks,
Prathamesh
>
> Cheers
>   Nick
>
>

Re: RFA: Sanitize deprecation messages (PR 84195)

2018-06-18 Thread Martin Jambor

Hi Nick,

On Fri, Feb 16 2018, Nick Clifton wrote:
> Hi David,
>
>   Attached is a revised version of the patch which I hope addresses all 
>   of your (very helpful) comments on the v3 patch.
>
>   OK to apply once the sources are back on stage 1 ?
>
> Cheers
>   Nick
>
> gcc/ChangeLog
> 2018-02-09  Nick Clifton  
>
>   PR 84195
>   * tree.c (escaped_string): New class.  Converts an unescaped
>   string into its escaped equivalent.
>   (warn_deprecated_use): Use the new class to convert the
>   deprecation message, if present.
>   (test_escaped_strings): New self test.
>   (test_c_tests): Add test_escaped_strings.
>   * doc/extend.texi (deprecated): Add a note that the
>   deprecation message is affected by the -fmessage-length
>   option, and that control characters will be escaped.
>   (#pragma GCC error): Document this pragma.
>   (#pragma GCC warning): Likewise.
>   * doc/invoke.texi (-fmessage-length): Document this option's
>   effect on the #warning and #error preprocessor directives and
>   the deprecated attribute.
>   

I'm getting a bootstrap failure:

/home/mjambor/gcc/trunk/src/gcc/tree.c:12457:20: error: cast from type ‘const 
char*’ to type ‘char*’ casts away qualifiers [-Werror=cast-qual]
   m_str = (char *) unescaped;

that I believe is caused by this patch, because the warning complains
about the newly added code:

> --- gcc/tree.c(revision 257653)
> +++ gcc/tree.c(working copy)
> @@ -12416,11 +12416,101 @@
> 

...

> 
> +/* PR 84195: Replace control characters in "unescaped" with their
> +   escaped equivalents.  Allow newlines if -fmessage-length has
> +   been set to a non-zero value.  This is done here, rather than
> +   where the attribute is recorded as the message length can
> +   change between these two locations.  */
> +
> +void
> +escaped_string::escape (const char * unescaped)
> +{
> +  char *escaped;
> +  size_t i, new_i, len;
> +
> +  if (m_owned)
> +free (m_str);
> +
> +  m_str = (char *) unescaped;

specifically about the line above, and the complaint seems quite valid.

Sorry for bad news,

Martin

[PATCH v3] Change default to -fno-math-errno

2018-06-18 Thread Wilco Dijkstra

GCC currently defaults to -fmath-errno.  This generates code assuming math
functions set errno and the application checks errno.  Few applications
test errno and various systems and math libraries no longer set errno since it
is optional.  GCC generates much faster code for simple math functions with
-fno-math-errno such as sqrt and lround (avoiding a call and PLT redirection).
Therefore it is reasonable to change the default to -fno-math-errno.  This is
already the case for non-C languages.  Only change the default for C99 and
later.

long f(float x) { return lroundf(x) + 1; }

by default:

f:
str x30, [sp, -16]!
bl  lroundf
add x0, x0, 1
ldr x30, [sp], 16
ret

With -fno-math-errno:

f:
fcvtas  x0, s0
add x0, x0, 1
ret

Passes regress on AArch64. OK for commit?

ChangeLog:
2018-06-18  Wilco Dijkstra  

* common.opt (fmath-errno): Change default to 0.
* opts.c (set_fast_math_flags): Force -fno-math-errno with -ffast-math.
* c-family/c-opts.c (c_common_init_options_struct): Set flag_errno_math
to special value.
(c_common_post_options): Set flag_errno_math default based on language.

doc/
* invoke.texi (-fmath-errno) Update documentation.

testsuite/

* gcc.dg/errno-1.c: Add -fmath-errno.
* gcc.dg/torture/pr68264.c: Likewise.
* gcc.dg/tree-ssa/ssa-dse-15.c: Likewise.
* gcc.target/aarch64/no-inline-lrint_1.c: Likewise.
--

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 
bbcb1bb1a9c606a262a1aa362471388987629d06..b13fc122f8baf6aae0b47010be92ffd961b0147a
 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -208,6 +208,9 @@ c_common_init_options_struct (struct gcc_options *opts)
 
   /* By default, C99-like requirements for complex multiply and divide.  */
   opts->x_flag_complex_method = 2;
+
+  /* Use a special value so the default can be set after option parsing.  */
+  opts->x_flag_errno_math = 2;
 }
 
 /* Common initialization before calling option handlers.  */
@@ -831,6 +834,11 @@ c_common_post_options (const char **pfilename)
   else if (!flag_gnu89_inline && !flag_isoc99)
 error ("-fno-gnu89-inline is only supported in GNU99 or C99 mode");
 
+  /* If -fmath-errno isn't set (or implied by another math option),
+ set the default to -fno-math-errno for C99 and later.  */
+  if (flag_errno_math == 2)
+flag_errno_math = !flag_isoc99 || c_dialect_objc ();
+
   /* Default to ObjC sjlj exception handling if NeXT runtime.  */
   if (flag_objc_sjlj_exceptions < 0)
 flag_objc_sjlj_exceptions = flag_next_runtime;
diff --git a/gcc/common.opt b/gcc/common.opt
index 
d54e8e5601698c73d2c2bc8f354b55f3889a9186..e6fe11d1dcdbb39016242299dd3d76233e2bd976
 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1855,7 +1855,7 @@ Common Report Var(flag_lto_report_wpa) Init(0)
 Report various link-time optimization statistics for WPA only.
 
 fmath-errno
-Common Report Var(flag_errno_math) Init(1) Optimization SetByCombined
+Common Report Var(flag_errno_math) Init(0) Optimization SetByCombined
 Set errno after built-in math functions.
 
 fmax-errors=
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 
42832c5a50013d776dff47c6d347f5bc4dbef2d8..aeda219ba0dbe169d9fb2b4358950f2ba32b5c78
 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9783,24 +9783,16 @@ that depend on an exact implementation of IEEE or ISO 
rules/specifications
 for math functions. It may, however, yield faster code for programs
 that do not require the guarantees of these specifications.
 
-@item -fno-math-errno
-@opindex fno-math-errno
-Do not set @code{errno} after calling math functions that are executed
-with a single instruction, e.g., @code{sqrt}.  A program that relies on
-IEEE exceptions for math error handling may want to use this flag
-for speed while maintaining IEEE arithmetic compatibility.
+@item -fmath-errno
+@opindex fmath-errno
+Generate code that assumes math functions may set errno.  This disables
+inlining of simple math functions like @code{sqrt} and @code{lround}.
 
-This option is not turned on by any @option{-O} option since
-it can result in incorrect output for programs that depend on
-an exact implementation of IEEE or ISO rules/specifications for
-math functions. It may, however, yield faster code for programs
-that do not require the guarantees of these specifications.
-
-The default is @option{-fmath-errno}.
+A program which relies on math functions setting errno may need to
+use this flag.  However note various systems and math libraries never
+set errno.
 
-On Darwin systems, the math library never sets @code{errno}.  There is
-therefore no reason for the compiler to consider the possibility that
-it might, and @option{-fno-math-errno} is the default.
+The default is @option{-fno-math-errno} except in ISO C90 and C++98 modes.
 
 @item -funsafe-math-optimizations
 @opindex funsafe-math-optimizations
@@

Re: [tree.c] Replace cast to (char *) by const_cast

2018-06-18 Thread Nick Clifton

Hi Prathamesh,

> I am getting the following build error with trunk:
> ../../gcc/gcc/tree.c: In member function ‘void
> escaped_string::escape(const char*)’:
> ../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
> type ‘char*’ casts away qualifiers [-Werror=cast-qual]
>m_str = (char *) unescaped;
> ^
> I think this is caused by r261697 in tree.c:
>   m_str = (char *) unescaped;
> 
> The patch changes it to const_cast (unescaped) which fixes the
> build for me.

I cannot approve this patch, but I can say thanks very much for catching
this problem and proposing a fix.  I guess that I must be using an old
version of g++ for my testing as this error did not show up. :-(

Cheers
  Nick

[tree.c] Replace cast to (char *) by const_cast

2018-06-18 Thread Prathamesh Kulkarni

Hi,
I am getting the following build error with trunk:
../../gcc/gcc/tree.c: In member function ‘void
escaped_string::escape(const char*)’:
../../gcc/gcc/tree.c:12457:20: error: cast from type ‘const char*’ to
type ‘char*’ casts away qualifiers [-Werror=cast-qual]
   m_str = (char *) unescaped;
^
I think this is caused by r261697 in tree.c:
  m_str = (char *) unescaped;

The patch changes it to const_cast (unescaped) which fixes the
build for me.
OK to commit ?

Thanks,
Prathamesh
diff --git a/gcc/tree.c b/gcc/tree.c
index 6728f1c..889d88c 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -12454,7 +12454,7 @@ escaped_string::escape (const char *unescaped)
   if (m_owned)
 free (m_str);
 
-  m_str = (char *) unescaped;
+  m_str = const_cast (unescaped);
   m_owned = false;
 
   if (unescaped == NULL || *unescaped == 0)

[PATCH] [aarch64] Remove obsolete comment about X30

2018-06-18 Thread Siddhesh Poyarekar

r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.

Siddhesh

* config/aarch64/aarch64.h: Remove obsolete comment.
---
 gcc/config/aarch64/aarch64.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 976f9afae54..df9fb31aa64 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -303,15 +303,6 @@ extern unsigned aarch64_architecture_version;
register.  GCC internally uses the poly_int variable aarch64_sve_vg
instead.  */
 
-/* Note that we don't mark X30 as a call-clobbered register.  The idea is
-   that it's really the call instructions themselves which clobber X30.
-   We don't care what the called function does with it afterwards.
-
-   This approach makes it easier to implement sibcalls.  Unlike normal
-   calls, sibcalls don't clobber X30, so the register reaches the
-   called function intact.  EPILOGUE_USES says that X30 is useful
-   to the called function.  */
-
 #define FIXED_REGISTERS\
   {\
 0, 0, 0, 0,   0, 0, 0, 0,  /* R0 - R7 */   \
-- 
2.14.4

Re: [C++ Patch] Tidy duplicate_decls locations

OK.

On Fri, Jun 15, 2018 at 10:16 AM, Paolo Carlini
 wrote:
> Hi,
>
> these bits started when I realized that in the error messages about
> redefined default arguments we were using DECL_SOURCE_LOCATION for the
> olddecl and just input_location for newdecl: in the future we'll able to
> point at the specific default argument but for the time being we can as well
> be consistent and point at the function name for the newdecl too instead of
> the meaningless closing parenthesis. Then I realized that in the rather
> large duplicate_decls we were using a mix of DECL_SOURCE_LOCATION (olddecl)
> and newdecl - lots - and '+' in a rather inconsistent way.
>
> Tested x86_64-linux.
>
> Thanks, Paolo.
>
> /
>

Re: [patch, fortran] PR25829 Asynchronous I/O (patch version 2.0)

2018-06-18 Thread Rainer Orth

Hi Nicolas,

> Here is the next version of the async I/O patch. It adds the documentation,
> renames the testcases, uses "gthr.h", follows the style guidelines and has
> been regression tested cleanly.
>
> As for adding additional flags, I think it would be better to follow ifort
> to minimize complexity.
>
> The benchmark (not for the test suite) should also run on systems with
> small stack sizes.

I didn't look at the code this time, just bootstrapped with the patch
included on i386-pc-solaris2.11 and sparc-sun-solaris2.11.  There are
still problems:

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

on both 32 and 64-bit sparc and x86.  The test always fails with

STOP 3

FAIL: libgomp.fortran/async_io_1.f90   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test

on 64-bit Solaris/x86 only (STOP 2).

Also on 32-bit Solaris/x86, I had an instance of f2003_inquire_1.exe
hang for 1 1/2 hours, although it should have been aborted by runtest
after the usual 300 s timeout:

+FAIL: gfortran.dg/f2003_inquire_1.f03   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+WARNING: program timed out.

Looks like a deadlock:

4036:   ./f2003_inquire_1.exe
  lwp# 1 / thread# 1  ---
 fd9b9db9 lwp_park (0, 0, 0)
 fd9b2f05 cond_wait_queue (80656a0, 8065688, 0, fd9b3433) + 60
 fd9b34b4 __cond_wait (80656a0, 8065688, feff4e58, fd9b34f6) + 8f
 fd9b3504 cond_wait (80656a0, 8065688, feff4eb8, fd9b3534) + 24
 fd9b3549 pthread_cond_wait (80656a0, 8065688, 583e6a5, fd9a4655) + 21
 fddf3355 _gfortrani_async_wait (feff4fac, 8065640, feff4f2f, feff4fac) + 125
 fddd0e38 _gfortran_st_close (feff4fac, feff4f61, 5, 8050f0b, feff50a8, 
feff5050) + 58
 080514db MAIN__   (20202020, 20202020, 20202020, 20202020, 4f525020, 53534543) 
+ 2cb
 20202038  ()
  lwp# 2 / thread# 2  ---
 fd9b9db9 lwp_park (0, 0, 0)
 fd9b2f05 cond_wait_queue (8065674, 806565c, 0, fd9b3433) + 60
 fd9b34b4 __cond_wait (8065674, 806565c, fd7fef38, fd9b34f6) + 8f
 fd9b3504 cond_wait (8065674, 806565c, fd7fef58, fd9b3534) + 24
 fd9b3549 pthread_cond_wait (8065674, 806565c, fd7fefa8, fddf0d96) + 21
 fddf131d async_io (80631d0, fda08000, fd7fefc8, fd9b9a27) + 5cd (async.c:102)
 fd9b9a79 _thrp_setup (fdab0240) + 99
 fd9b9d60 _lwp_start (0, 0, 0, 0, 0, 0)

Rainer

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

[COMMITTED][testsuite] Add target pthread to pr86076.c

2018-06-18 Thread Wilco Dijkstra

Add missing target pthread to ensure test doesn't fail on bare-metal
targets. Committed as obvious.

ChangeLog:
2018-06-18  Wilco Dijkstra  

PR tree-optimization/86076
* gcc.dg/pr86076.c: Add target pthread for bare-metal targets.
--

diff --git a/gcc/testsuite/gcc.dg/pr86076.c b/gcc/testsuite/gcc.dg/pr86076.c
index 
019ced3cbf5969e477b2e4b696f26c8afc9457c5..390ca47ba12481e4f9587a11a8c46de0c74de0d8
 100644
--- a/gcc/testsuite/gcc.dg/pr86076.c
+++ b/gcc/testsuite/gcc.dg/pr86076.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target pthread } }  */
 /* { dg-options "-O2 -ftree-parallelize-loops=2 -fno-tree-dce -fno-tree-pre 
-fno-tree-vrp --param max-loop-header-insns=1" } */
 
 int __attribute__ ((noinline))

Re: RFC: What should go in our header?

2018-06-18 Thread Ville Voutilainen

On 17 June 2018 at 19:49, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 06/15/2018 11:52 AM, Jonathan Wakely wrote:
>>
>> C++20 adds a  header, which should define all the library
>> feature test macros, as well as implementation-specific macros like
>> _GLIBCXX_RELEASE and __GLIBCXX__.
>>
>> We should decide whether to implement  by simply including
>>  and then adding the feature test macros, or if we
>> should keep it minimal and *only* define _GLIBCXX_RELEASE and
>> __GLIBCXX__ and the feature tests (and then have 
>> include ?)
>>
>> I think I prefer to make  just include .
>>
>> I think we should define the feature-test macros in both  and
>> the relevant header (e.g. __cpp_string_view in ). We
>> could make everything include  and then every header would
>> define every feature test macro, but I don't think that's good for
>> portability.
>>
>> My preference is implemented by the attached patch.
>>
> This is pretty much what I was looking at doing.  I say go!

+1 looks reasonable to me.

Re: RFC: What should go in our header?

On Sun, 17 Jun 2018 at 17:49, Ed Smith-Rowland wrote:
>
> On 06/15/2018 11:52 AM, Jonathan Wakely wrote:
> > My preference is implemented by the attached patch.
> >
> This is pretty much what I was looking at doing.  I say go!

Thanks for the feedback, I'll add  later today.

> > While on the subject, should we just delete some of this autoconf-junk
> > from our c++config.h headers?
> >
> > /* Name of package */
> > /* #undef _GLIBCXX_PACKAGE */
> >
> > /* Define to the address where bug reports for this package should be
> > sent. */
> > #define _GLIBCXX_PACKAGE_BUGREPORT ""
> >
> > /* Define to the full name of this package. */
> > #define _GLIBCXX_PACKAGE_NAME "package-unused"
> >
> > /* Define to the full name and version of this package. */
> > #define _GLIBCXX_PACKAGE_STRING "package-unused version-unused"
> >
> > /* Define to the one symbol short name of this package. */
> > #define _GLIBCXX_PACKAGE_TARNAME "libstdc++"
> >
> > /* Define to the home page for this package. */
> > #define _GLIBCXX_PACKAGE_URL ""
> >
> > /* Define to the version of this package. */
> > #define _GLIBCXX_PACKAGE__GLIBCXX_VERSION "version-unused"
> >
> I don't have an opinion here except if this is unused cruft let's lose
> it.  I think we *are* supposed to have some project and version
> identification.  We have _GLIBCXX_* everywhere.  The folks that use
> libstdc++ *outside* of g++ might have some opinions about this too.

I think they're more likely to use _GLIBCXX_RELEASE (and maybe
__GLIBCXX__ although that's not very useful) as documented at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html

The PACKAGE_* macros are defined by autoconf for the package's own
use, typically for the output of "cmd --version" and for naming
tarballs. Libstdc++ isn't a standalone package, doesn't have a
--version option, and isn't distributed in its own tarball.

[COMMITTED][testsuite] Remove xfail from vect-abs-compile.c

2018-06-18 Thread Wilco Dijkstra

Since PR64946 has been fixed, we can remove the xfail from this test.
Committed as obvious.

ChangeLog:
2018-06-18  Wilco Dijkstra  

PR tree-optimization/64946
* gcc.target/aarch64/vect-abs-compile.c: Remove xfail.
--

diff --git a/gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c 
b/gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c
index 
856e7a738e5efbdc79b5b6200c1048ea1d6583b9..19082d73ea8530a277013fec252a88e8bd1dcc4b
 100644
--- a/gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c
+++ b/gcc/testsuite/gcc.target/aarch64/vect-abs-compile.c
@@ -6,8 +6,7 @@
 
 #include "vect-abs.x"
 
-/* XFAIL due to PR tree-optimization/64946.  */
-/* { dg-final { scan-assembler "abs\\tv\[0-9\]+\.16b" { xfail *-*-* } } } */
-/* { dg-final { scan-assembler "abs\\tv\[0-9\]+\.8h" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler "abs\\tv\[0-9\]+\.16b" } } */
+/* { dg-final { scan-assembler "abs\\tv\[0-9\]+\.8h" } } */
 /* { dg-final { scan-assembler "abs\\tv\[0-9\]+\.4s" } } */
 /* { dg-final { scan-assembler "abs\\tv\[0-9\]+\.2d" } } */

[AArch64][PATCH 2/2] Combine AES instructions with xor and zero operands

Hi,

This patch teaches the AArch64 backend that AES instructions with a XOR and 
zero operands can be simplified by replacing the operands of the AES with XOR's 
thus eliminating the XOR. This is OK because the AES instruction XORs the input 
operands.

This will improve code-generation when dealing with code like:
static const uint8x16_t zero = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

uint8x16_t test0 (uint8x16_t a, uint8x16_t b)
{
  uint8x16_t result = vaeseq_u8 (a ^ b, zero);
  result = vaesdq_u8 (result ^ a, zero);
  return result;
}

Whereas this would lead to the generation of an unnecessary 'eor' instructions:
test0:
moviv2.4s, 0
eor v1.16b, v0.16b, v1.16b
aesev1.16b, v2.16b
eor v0.16b, v0.16b, v1.16b
aesdv0.16b, v2.16b
ret

Whereas with this patch we get:
test0:
aesev1.16b, v0.16b
aesdv0.16b, v1.16b
ret

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

Is this OK for trunk?

Cheers,
Andre

gcc
2018-06-18  Andre Vieira  


* config/aarch64/aarch64-simd.md 
(*aarch64_crypto_aesv16qi_xor_combine):
New.

gcc/testsuite
2018-06-18  Andre Vieira  

* gcc.target/aarch64/aes_xor_combine.c: New test.

aes-2.patch
Description: aes-2.patch

[AArch64][PATCH 1/2] Make AES unspecs commutative

Hi,

This patch teaches the AArch64 backend that the AESE and AESD unspecs are 
commutative (which correspond to the vaeseq_u8 and vaesdq_u8 intrinsics). This 
improves register allocation around their corresponding instructions avoiding 
unnecessary moves.

For instance, with the old patterns code such as:

uint8x16_t
test0 (uint8x16_t a, uint8x16_t b)
{
  uint8x16_t result;
  result = vaeseq_u8 (a, b);
  result = vaeseq_u8 (result, a);
  return result;
}

would lead to suboptimal register allocation such as:
test0:
mov v2.16b, v0.16b
aesev2.16b, v1.16b
mov v1.16b, v2.16b
aesev1.16b, v0.16b
mov v0.16b, v1.16b
ret

whereas with the new patterns we see:
aesev1.16b, v0.16b
aesev0.16b, v1.16b
ret


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

Is this OK for trunk?

Cheers,
Andre


gcc
2018-06-18  Andre Vieira  


* config/aarch64/aarch64-simd.md (aarch64_crypto_aesv16qi):
Make operands of the unspec commutative.

gcc/testsuite
2018-06-18 Andre Vieira  

* gcc/target/aarch64/aes_2.c: New test.

aes-1.patch
Description: aes-1.patch

[AArch64][PATCH 0/2] Improve codegen for AES instructions

Hi,

This patch series aims to improve codegen for the AArch64 AES instructions by 
doing two things.

The first is to make the AES unspecs commutative and by consequence make the 
corresponding intrinsics commutative, since the instructions themselves are 
commutative in the input.
This will improve register allocation around these instructions. The second 
step is to combine AES instructions with the following format 'AES (XOR (a,b), 
0)' into 'AES (a, b)'.

Andre Vieira (2):
Make AES unspecs commutative
Combine AES instructions with xor and zero operands


Cheers,
Andre

RFA: Restore ability to build zlib in a srcdir == builddir

2018-06-18 Thread Nick Clifton

Hi Guys,

  The patch below allows the zlib library to be built when the build
  directory is the same as the source directory.  This patch has been in
  the binutils/gdb sources for a while now, but unfortunately was never
  copied to gcc.  So I am trying to right that mistake now.

  OK to apply ?

Cheers
  Nick

./ChangeLog
* zlib/configure.ac: Restore old behaviour of only enabling
multilibs when a target subdirectory is defined.  This allows
building with srcdir == builddir.
* zlib/configure: Regenerate.

diff --git a/zlib/configure.ac b/zlib/configure.ac
index fb8d943905..57d6fa56b6 100644
--- a/zlib/configure.ac
+++ b/zlib/configure.ac
@@ -4,7 +4,9 @@ AC_PREREQ(2.64)
 AC_INIT
 AC_CONFIG_SRCDIR([zlib.h])
 
-AM_ENABLE_MULTILIB(, ..)
+if test -n "${with_target_subdir}"; then
+  AM_ENABLE_MULTILIB(, ..)
+fi
 
 AC_CANONICAL_SYSTEM

Re: [PATCH 2/8] Introduce VECT_SCOPE macro

2018-06-18 Thread Richard Biener

On Fri, Jun 15, 2018 at 10:11 PM Jeff Law  wrote:
>
> On 06/14/2018 02:32 PM, David Malcolm wrote:
> > The vectorizer code has numerous instances of:
> >
> >   if (dump_enabled_p ())
> > dump_printf_loc (MSG_NOTE, vect_location,
> >  "=== some message ===\n");
> >
> > In each case, the dump_printf_loc is a MSG_NODE at vect_location.
> >
> > In almost all cases the message is of the form
> >   "=== foo ===\n"
> >
> > The exceptions are:
> >   "= analyze_loop_nest =\n"
> > which uses 4 equal signs rather than 3, and
> >   "===vect_slp_analyze_bb===\n"
> > which is missing the spaces.
> >
> > In most cases (but not always) the message matches the function name.
> >
> > This patch replaces all of these with a macro, taking the message
> > as an argument (and forcing the use of three dashes and a space).
> >
> > The idea is to later convert this macro to use an RAII type
> > that pushes and pops scope, so that the nesting structure appears
> > in the dumpfile and -fopt-info logs (and in the remarks and
> > optimization records introduced later in this patch kit).
> >
> > The message is usually the function name, but not always.
> > Should I split this out into two macros? e.g. a VECT_FUNCTION_SCOPE
> > that uses __FUNCTION__?
> >
> > Would DUMP_VECT_SCOPE be a better name, perhaps?
> >
> > gcc/ChangeLog:
> >   * tree-vect-data-refs.c (vect_analyze_data_ref_dependences):
> >   Replace dump_printf_loc call with VECT_SCOPE.
> >   (vect_slp_analyze_instance_dependence): Likewise.
> >   (vect_enhance_data_refs_alignment): Likewise.
> >   (vect_analyze_data_refs_alignment): Likewise.
> >   (vect_slp_analyze_and_verify_instance_alignment
> >   (vect_analyze_data_ref_accesses): Likewise.
> >   (vect_prune_runtime_alias_test_list): Likewise.
> >   (vect_analyze_data_refs): Likewise.
> >   * tree-vect-loop-manip.c (vect_update_inits_of_drs): Likewise.
> >   * tree-vect-loop.c (vect_determine_vectorization_factor): Likewise.
> >   (vect_analyze_scalar_cycles_1): Likewise.
> >   (vect_get_loop_niters): Likewise.
> >   (vect_analyze_loop_form_1): Likewise.
> >   (vect_update_vf_for_slp): Likewise.
> >   (vect_analyze_loop_operations): Likewise.
> >   (vect_analyze_loop): Likewise.
> >   (vectorizable_induction): Likewise.
> >   (vect_transform_loop): Likewise.
> >   * tree-vect-patterns.c (vect_pattern_recog): Likewise.
> >   * tree-vect-slp.c (vect_analyze_slp): Likewise.
> >   (vect_make_slp_decision): Likewise.
> >   (vect_detect_hybrid_slp): Likewise.
> >   (vect_slp_analyze_operations): Likewise.
> >   (vect_slp_bb): Likewise.
> >   * tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized): Likewise.
> >   (vectorizable_bswap): Likewise.
> >   (vectorizable_call): Likewise.
> >   (vectorizable_simd_clone_call): Likewise.
> >   (vectorizable_conversion): Likewise.
> >   (vectorizable_assignment): Likewise.
> >   (vectorizable_shift): Likewise.
> >   (vectorizable_operation): Likewise.
> >   * tree-vectorizer.h (VECT_SCOPE): New macro.
> OK.  But rather than using a macro, *consider* just using a normal
> function.  I'm less and less inclined to use macros as I get older :-)
>
> If there's a solid reason to use a macro, then that's fine.
>
> DUMP_VECT_SCOPE seems better than VEC_SCOPE.

Agreed on DUMP_VECT_SCOPE, using a function would somewhat
defeat the purpose of the dump_enabled_p () check.

Richard.

> Jeff

Re: [PATCH] i386; Add -mmanual-endbr and cf_check function attribute

2018-06-18 Thread Richard Biener

On Fri, Jun 15, 2018 at 2:59 PM H.J. Lu  wrote:
>
> Currently GCC inserts ENDBR instruction at entries of all non-static
> functions, unless LTO compilation is used.  Marking all functions,
> which are not called indirectly with nocf_check attribute, is not
> ideal since 99% of functions in a program may be of this kind.
>
> This patch adds -mmanual-endbr and cf_check function attribute.  They
> can be used together with -fcf-protection such that ENDBR instruction
> is inserted only at entries of functions with cf_check attribute.  It
> can limit number of ENDBR instructions to reduce program size.
>
> OK for trubk?

I wonder if the linker could assist with ENDBR creation by
redirecting all non-direct call relocs to a linker-generated
stub with ENBR and a direct branch?

Richard.

> H.J.
> -
> gcc/
>
> * config/i386/i386.c (rest_of_insert_endbranch): Insert ENDBR
> at the function entry only when -mmanual-endbr isn't used or
> there is cf_check function attribute.
> (ix86_attribute_table): Add cf_check.
> * config/i386/i386.opt: Add -mmanual-endbr.
> * doc/extend.texi: Document cf_check attribute.
> * doc/invoke.texi: Document -mmanual-endbr.
>
> gcc/testsuite/
>
> * gcc.target/i386/cf_check-1.c: New test.
> * gcc.target/i386/cf_check-2.c: Likewise.
> * gcc.target/i386/cf_check-3.c: Likewise.
> * gcc.target/i386/cf_check-4.c: Likewise.
> * gcc.target/i386/cf_check-5.c: Likewise.
> ---
>  gcc/config/i386/i386.c |  5 +
>  gcc/config/i386/i386.opt   |  5 +
>  gcc/doc/extend.texi|  7 +++
>  gcc/doc/invoke.texi|  9 -
>  gcc/testsuite/gcc.target/i386/cf_check-1.c | 11 +++
>  gcc/testsuite/gcc.target/i386/cf_check-2.c | 11 +++
>  gcc/testsuite/gcc.target/i386/cf_check-3.c | 11 +++
>  gcc/testsuite/gcc.target/i386/cf_check-4.c | 10 ++
>  gcc/testsuite/gcc.target/i386/cf_check-5.c |  9 +
>  9 files changed, 77 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-3.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-4.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/cf_check-5.c
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 95cfa05ce61..d356e0e7acd 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2604,6 +2604,9 @@ rest_of_insert_endbranch (void)
>
>if (!lookup_attribute ("nocf_check",
>  TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl)))
> +  && (!flag_manual_endbr
> + || lookup_attribute ("cf_check",
> +  DECL_ATTRIBUTES (cfun->decl)))
>&& !cgraph_node::get (cfun->decl)->only_called_directly_p ())
>  {
>cet_eb = gen_nop_endbr ();
> @@ -45896,6 +45899,8 @@ static const struct attribute_spec 
> ix86_attribute_table[] =
>  ix86_handle_fndecl_attribute, NULL },
>{ "function_return", 1, 1, true, false, false, false,
>  ix86_handle_fndecl_attribute, NULL },
> +  { "cf_check", 0, 0, true, false, false, false,
> +ix86_handle_fndecl_attribute, NULL },
>
>/* End element.  */
>{ NULL, 0, 0, false, false, false, false, NULL, NULL }
> diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
> index a34d4acf1a2..aebc023420b 100644
> --- a/gcc/config/i386/i386.opt
> +++ b/gcc/config/i386/i386.opt
> @@ -1016,6 +1016,11 @@ Target Report Undocumented Var(flag_cet_switch) Init(0)
>  Turn on CET instrumentation for switch statements that use a jump table and
>  an indirect jump.
>
> +mmanual-endbr
> +Target Report Var(flag_manual_endbr) Init(0)
> +Insert ENDBR instruction at function entry only via cf_check attribute
> +for CET instrumentation.
> +
>  mforce-indirect-call
>  Target Report Var(flag_force_indirect_call) Init(0)
>  Make all function calls indirect.
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index e0a84b8b3c5..5fd4a1b22b0 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -5864,6 +5864,13 @@ foo (void)
>  @}
>  @end smallexample
>
> +@item cf_check
> +@cindex @code{cf_check} function attribute, x86
> +
> +The @code{cf_check} attribute on a function is used to inform the
> +compiler that ENDBR instruction should be placed at the function
> +entry when @option{-fcf-protection=branch} is enabled.
> +
>  @end table
>
>  On the x86, the inliner does not inline a
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 940b84697fa..7ec4267b7b1 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1250,7 +1250,7 @@ See RS/6000 and PowerPC Options.
>  -msse4a  -m3dnow  -m3dnowa  -mpopcnt  -mabm  -mbmi  -mtbm  -mfma4  -mxop @gol
>  -mlzcnt  -mbmi2  -mfxsr  -mxsave  -mxsaveopt  -mrtm  -mlwp @gol

Re: Incremental LTO linking part 2: lto-plugin support

2018-06-18 Thread Jan Hubicka

> On 05/08/2018 09:14 AM, Jan Hubicka wrote:
> >Hi,
> >with lto, incremental linking can be meaninfuly done in three ways:
> >  1) read LTO file and produce non-LTO .o file
> > this is current behaviour of gcc -r or ld -r with plugin
> >  2) read LTO files and merge section for later LTO
> > this is current behaviour of ld -r w/o plugin
> >  3) read LTO files into the compiler, link them and produce
> > incrementaly linked LTO object.
> >
> >3 makes most sense and I am maing it new default for gcc -r. For testing 
> >purposes
> >and perhaps in order to have tool to turn LTO object into real object, we 
> >want
> >to have 1) available as well.  GCC currently have -flinker-output option that
> >decides between modes that is decided by linker plugin and can be overwritten
> >by user (I have forgot to document this).
> >
> >I am targeting for -flinker-output=rel to be incremental linking into LTO
> >and adding -flinker-output=nolto-rel for 1).
> >
> >The main limitation of 2 and 3 is that you can not link LTO and non-LTO
> >object files theger.  For 2 HJ's binutils patchset has support and I think
> >it can be extended to handle 3 as well. But with default binutils we want
> >to warn users.  This patch implements the warning (and prevents linker plugin
> >to add redundat linker-ouptut options.
> 
> This patch seems to have caused a lot of LTO tests in the G++ testsuite to
> fail on bare-metal targets because of the new warning.  Here's a list for
> arm-none-eabi:
> 
> FAIL: g++.dg/lto/20091002-1 cp_lto_20091002-1_0.o-cp_lto_20091002-1_0.o
> link, -fPIC -flto -Wno-return-type
> FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3
> -flto
> FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link, -flto
> -std=c++11
> FAIL: g++.dg/lto/pr65193 cp_lto_pr65193_0.o-cp_lto_pr65193_0.o link, -fPIC
> -r -nostdlib -flto -O2 -g -Wno-return-type
> FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto
> -O0 -std=c++11
> FAIL: g++.dg/lto/pr65302 cp_lto_pr65302_0.o-cp_lto_pr65302_1.o link, -flto
> -O2 -Wno-return-type
> FAIL: g++.dg/lto/pr65316 cp_lto_pr65316_0.o-cp_lto_pr65316_1.o link, -flto
> -std=c++11 -g2 -fno-lto-odr-type-merging -O2 -Wno-return-type
> FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link,
> -std=gnu++14 -flto -g -Wno-return-type
> FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link,
> -std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type
> FAIL: g++.dg/lto/pr66180 cp_lto_pr66180_0.o-cp_lto_pr66180_1.o link, -flto
> -std=c++14 -r -nostdlib
> FAIL: g++.dg/lto/pr66705 cp_lto_pr66705_0.o-cp_lto_pr66705_0.o link, -O2
> -flto -flto-partition=max -fipa-pta
> FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0
> -flto -flto-partition=none -fuse-linker-plugin
> FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2
> -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
> FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O0
> -flto -fuse-linker-plugin -fno-fat-lto-objects
> FAIL: g++.dg/lto/pr68057 cp_lto_pr68057_0.o-cp_lto_pr68057_1.o link, -O2
> -flto -fuse-linker-plugin
> FAIL: g++.dg/lto/pr69077 cp_lto_pr69077_0.o-cp_lto_pr69077_1.o link, -O3 -g
> -flto
> FAIL: g++.dg/lto/pr69133 cp_lto_pr69133_0.o-cp_lto_pr69133_1.o link, -flto
> -O2
> FAIL: g++.dg/lto/pr69137 cp_lto_pr69137_0.o-cp_lto_pr69137_0.o link,
> -std=c++11 -g -flto
> FAIL: g++.dg/lto/pr79000 cp_lto_pr79000_0.o-cp_lto_pr79000_1.o link, -flto
> -g
> FAIL: g++.dg/lto/pr81940 cp_lto_pr81940_0.o-cp_lto_pr81940_0.o link,  -O
> -flto
> FAIL: g++.dg/lto/pr85176 cp_lto_pr85176_0.o-cp_lto_pr85176_0.o link, -flto
> -g1
> 
> I got a similar list on the csky-elf port I'm preparing for submission, but
> I didn't see any of these FAILs for csky-linux-gnu.  LTO is a mysterious
> black box to me, but maybe it has something to do with linking with static
> vs shared libraries?  Or some linker script issue? I see part 8 of this
> patch series touched a whole bunch of other test cases, but not these.

I wonder what warning you get? There was PR about older binutils incorrectly
complaining about object file needing a plugin when IR object file is passed
after incremental link.
I do not think there is a way to silence this warning from GCC side.
We could use -flinker-output=nonlto-rel to avoid incremental linking in those
tests but eventually we will want some test coverage :)

Honza
> 
> -Sandra

Re: [AArch64][PATCH 1/2] Fix addressing printing of LDP/STP