Re: C++ PATCH for c++/91678 - wrong error with decltype and location wrapper

[Jason Merrill]

On 12/6/19 7:18 PM, Marek Polacek wrote:

[ Sorry for dropping the ball on this. ]

On Tue, Sep 17, 2019 at 11:59:02PM -0400, Jason Merrill wrote:

On 9/16/19 1:12 PM, Marek Polacek wrote:

On Sun, Sep 15, 2019 at 10:18:29AM -0400, Jason Merrill wrote:

On 9/5/19 9:24 PM, Marek Polacek wrote:

They use
non_lvalue_loc, but that won't create a NON_LVALUE_EXPR wrapper around a 
location
wrapper.


That seems like the bug. maybe_lvalue_p should be true for
VIEW_CONVERT_EXPR.


That makes sense but it breaks in tsubst_* which doesn't expect a
NON_LVALUE_EXPR wrapped around a location wrapper.


Hmm, why would we get that in a template when we don't get NON_LVALUE_EXPR
wrapped around other lvalue nodes?


I just retested the patch without the pt.c hunk and no longer see that problem,
and the fold-const.c hunk still fixes the bogus error.  Yay?

So I think the following should be good to go:

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


OK.


2019-12-06  Marek Polacek  

PR c++/91678 - wrong error with decltype and location wrapper.
* fold-const.c (maybe_lvalue_p): Handle VIEW_CONVERT_EXPR.

* g++.dg/cpp0x/decltype73.C: New test.

--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -2594,6 +2594,7 @@ maybe_lvalue_p (const_tree x)
case TARGET_EXPR:
case COND_EXPR:
case BIND_EXPR:
+  case VIEW_CONVERT_EXPR:
  break;
  
default:

--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/decltype73.C
@@ -0,0 +1,4 @@
+// PR c++/91678 - wrong error with decltype and location wrapper.
+// { dg-do compile { target c++11 } }
+
+float* test(float* c) { return (decltype(c + 0))(float*)c; }

Re: [PATCH 28/49] analyzer: new files: analyzer.{cc|h}

[Eric Gallager]

On 11/15/19, David Malcolm  wrote:
> gcc/ChangeLog:
>   * analyzer/analyzer.cc: New file.
>   * analyzer/analyzer.h: New file.
> ---
>  gcc/analyzer/analyzer.cc | 125
> ++
>  gcc/analyzer/analyzer.h  | 126
> +++
>  2 files changed, 251 insertions(+)
>  create mode 100644 gcc/analyzer/analyzer.cc
>  create mode 100644 gcc/analyzer/analyzer.h
>
> diff --git a/gcc/analyzer/analyzer.cc b/gcc/analyzer/analyzer.cc
> new file mode 100644
> index 000..399925c
> --- /dev/null
> +++ b/gcc/analyzer/analyzer.cc
> @@ -0,0 +1,125 @@
> +/* Utility functions for the analyzer.
> +   Copyright (C) 2019 Free Software Foundation, Inc.
> +   Contributed by David Malcolm .
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify it
> +under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful, but
> +WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3.  If not see
> +.  */
> +
> +#include "config.h"
> +#include "gcc-plugin.h"
> +#include "system.h"
> +#include "coretypes.h"
> +#include "tree.h"
> +#include "gimple.h"
> +#include "diagnostic.h"
> +#include "intl.h"
> +#include "analyzer/analyzer.h"
> +
> +/* Helper function for checkers.  Is the CALL to the given function name?
> */
> +
> +bool
> +is_named_call_p (const gcall *call, const char *funcname)
> +{
> +  gcc_assert (funcname);
> +
> +  tree fndecl = gimple_call_fndecl (call);
> +  if (!fndecl)
> +return false;
> +
> +  return 0 == strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), funcname);
> +}
> +
> +/* Helper function for checkers.  Is the CALL to the given function name,
> +   and with the given number of arguments?  */
> +
> +bool
> +is_named_call_p (const gcall *call, const char *funcname,
> +  unsigned int num_args)
> +{
> +  gcc_assert (funcname);
> +
> +  if (!is_named_call_p (call, funcname))
> +return false;
> +
> +  if (gimple_call_num_args (call) != num_args)
> +return false;
> +
> +  return true;
> +}
> +
> +/* Return true if stmt is a setjmp call.  */
> +
> +bool
> +is_setjmp_call_p (const gimple *stmt)
> +{
> +  /* TODO: is there a less hacky way to check for "setjmp"?  */
> +  if (const gcall *call = dyn_cast  (stmt))
> +if (is_named_call_p (call, "_setjmp", 1))
> +  return true;
> +
> +  return false;
> +}
> +
> +/* Return true if stmt is a longjmp call.  */
> +
> +bool
> +is_longjmp_call_p (const gcall *call)
> +{
> +  /* TODO: is there a less hacky way to check for "longjmp"?  */
> +  if (is_named_call_p (call, "longjmp", 2))
> +return true;
> +
> +  return false;
> +}
> +
> +/* Generate a label_text instance by formatting FMT, using a
> +   temporary clone of the global_dc's printer (thus using its
> +   formatting callbacks).
> +
> +   Colorize if the global_dc supports colorization and CAN_COLORIZE is
> +   true.  */
> +
> +label_text
> +make_label_text (bool can_colorize, const char *fmt, ...)
> +{
> +  pretty_printer *pp = global_dc->printer->clone ();
> +  pp_clear_output_area (pp);
> +
> +  if (!can_colorize)
> +pp_show_color (pp) = false;
> +
> +  text_info ti;
> +  rich_location rich_loc (line_table, UNKNOWN_LOCATION);
> +
> +  va_list ap;
> +
> +  va_start (ap, fmt);
> +
> +  ti.format_spec = _(fmt);
> +  ti.args_ptr = 
> +  ti.err_no = 0;
> +  ti.x_data = NULL;
> +  ti.m_richloc = _loc;
> +
> +  pp_format (pp, );
> +  pp_output_formatted_text (pp);
> +
> +  va_end (ap);
> +
> +  label_text result = label_text::take (xstrdup (pp_formatted_text (pp)));
> +  delete pp;
> +  return result;
> +}
> diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
> new file mode 100644
> index 000..ace8924
> --- /dev/null
> +++ b/gcc/analyzer/analyzer.h
> @@ -0,0 +1,126 @@
> +/* Utility functions for the analyzer.
> +   Copyright (C) 2019 Free Software Foundation, Inc.
> +   Contributed by David Malcolm .
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify it
> +under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful, but
> +WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3.  If not see
> 

Re: [PATCH 01/49] analyzer: user-facing documentation

[David Malcolm]

On Fri, 2019-12-06 at 14:57 -0500, Eric Gallager wrote:
> While I get that this is just the documentation, having a good list
> like this will make it easy to use to respond to the individual items
> it documents, so that's what I'm going to use it for:

Thanks; I'm slowly working though the bugzilla links you provided.

Dave

Re: [PATCH 1/2] pretty-print: support URL escape sequences (PR 87488)

[David Malcolm]

On Sat, 2019-12-07 at 00:41 +0100, Jakub Jelinek wrote:
> On Thu, Oct 10, 2019 at 01:06:13PM -0400, David Malcolm wrote:
> > https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
> > describes an emerging standard for embedding URLs in escape
> > sequences
> > for marking up text output.  This is supported e.g. by recent
> > releases
> > of GNOME Terminal.
> 
> Unfortunately, as reported by several people, the
> OSC 8 ;; URL ST Text OSC 8 ;; ST
> sequence renders badly on recentish konsole5 terminal emulator, which
> is
> something a lot of people use.
> While the above page suggests the use of ST rather than BEL, in
> practice
> that at least currently does better job.
> Tested with
> echo -e '\e]8;;http://example.com\aThis is a link\e]8;;\a\n\e]8;;
> http://example.com\e\\This is a link\e]8;;\e\\\n'
> on various terminals:
> gnome-terminal-3.30.2 both lines the same, URLs work
> konsole5-18.12.3 the first line normal text, the second one wrapped
> in
>between \s, i.e. \This is a link\ , URLs don't work
> xterm-334 both lines the same, normal text, URLs don't work
> rxvt-2.7.10 ditto
> xterm-314 ditto
> konsole5-15.12.1 ditto
> linux kernel 5.0.13 console ditto
> linux kernel 4.4.14 console ditto
> gnome-terminal-3.16.2 prints garbage around and both the URL and the
> text
> are visible, but the line with ST has more
> garbage
> than line with BEL
> 
> BEL instead of ST is also what ls -l --hyperlink prints.

systemd also uses BEL rather than ST.

> Ok for trunk?

OK; please reference PR 87488 in the ChangeLog.


> 2019-12-07  Jakub Jelinek  
> 
>   * pretty-print.c (pp_begin_url, pp_end_url, test_urls): Use BEL
>   instead of ST sequence to terminate OSC 8 strings.
> 
> --- gcc/pretty-print.c.jj 2019-10-11 09:29:15.103953133 +0200
> +++ gcc/pretty-print.c2019-12-07 00:17:00.860500837 +0100
> @@ -2043,7 +2043,10 @@ identifier_to_locale (const char *ident)
> >
> > OSC 8 ; ; ST
> >
> -   > OSC (operating system command) is typically ESC ].  */
> +   > OSC (operating system command) is typically ESC ].
> +
> +   Use BEL instead of ST, as that is currently rendered better in
> some
> +   terminal emulators that don't support OSC 8, like konsole5.  */
>  
>  /* If URL-printing is enabled, write an "open URL" escape sequence
> to PP
> for the given URL.  */
> @@ -2052,7 +2055,7 @@ void
>  pp_begin_url (pretty_printer *pp, const char *url)
>  {
>if (pp->show_urls)
> -pp_printf (pp, "\33]8;;%s\33\\", url);
> +pp_printf (pp, "\33]8;;%s\a", url);
>  }
>  
>  /* If URL-printing is enabled, write a "close URL" escape sequence
> to PP.  */
> @@ -2061,7 +2064,7 @@ void
>  pp_end_url (pretty_printer *pp)
>  {
>if (pp->show_urls)
> -pp_string (pp, "\33]8;;\33\\");
> +pp_string (pp, "\33]8;;\a");
>  }
>  
>  #if CHECKING_P
> @@ -2369,7 +2372,7 @@ test_urls ()
>  pp_begin_url (, "http://example.com;);
>  pp_string (, "This is a link");
>  pp_end_url ();
> -ASSERT_STREQ ("\33]8;;http://example.com\33\\This is a
> link\33]8;;\33\\",
> +ASSERT_STREQ ("\33]8;;http://example.com\aThis is a
> link\33]8;;\a",
> pp_formatted_text ());
>}
>  }
> 
> 
>   Jakub

Re: [PING 3][PATCH] track dynamic allocation in strlen (PR 91582)

[Jakub Jelinek]

On Fri, Dec 06, 2019 at 05:19:36PM -0700, Martin Sebor wrote:
> With part 2 (below) of this work committed, I've rebased the patch
> on the top of trunk and on top of the updated part 1 (also below).
> Attached is the result, retested on x86_64-linux.

> --- a/gcc/tree-ssa-strlen.c
> +++ b/gcc/tree-ssa-strlen.c
> @@ -61,6 +61,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "vr-values.h"
>  #include "gimple-ssa-evrp-analyze.h"
>  
> +#pragma GCC optimize ("0")
>  /* A vector indexed by SSA_NAME_VERSION.  0 means unknown, positive value
> is an index into strinfo vector, negative value stands for
> string length of a string literal (~strlen).  */

Why this?  Some debugging left-over?

Jakub

[PING 3][PATCH] track dynamic allocation in strlen (PR 91582)

[Martin Sebor]

With part 2 (below) of this work committed, I've rebased the patch
on the top of trunk and on top of the updated part 1 (also below).
Attached is the result, retested on x86_64-linux.

[1] include size and offset in -Wstringop-overflow
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00392.html

[2] extend -Wstringop-overflow to allocated objects
(committed in r278983)
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00263.html

On 11/25/19 10:54 AM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00812.html

On 11/18/19 11:23 AM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00812.html

On 11/11/19 6:27 PM, Martin Sebor wrote:

The attached patch extends the strlen pass to detect out-of-bounds
accesses to memory allocated by calls to other allocation functions
besides calloc and malloc, as well as VLAs, and user-defined
functions declared with attribute alloc_size.  There is some
overlap with the _FORTIFY_SOURCE detection but thanks to
the extensive use of ranges, this enhancement detects many more
cases of overflow.

The solution primarily improves warnings but some of the changes
also improve codegen in some cases as a side-effect.  I hope to
take better advantage of the optimization opportunities the dynamic
memory tracking opens up (and also better buffer overflow and array
out-of-bounds detection) in GCC 11.

Although the strlen pass already tracks some dynamic memory calls
(calloc and malloc) rather than extending the same infrastructure
(strinfo::stmt) to others I took the approach of adding a separate
data member for the other calls (strinfo::alloc) and tracking those
independently.  I did this to keep the changes only minimally
intrusive.  In the future (post GCC 10) it might be worth
considering merging both.

Besides introducing the new member and making use of it, the rest
of the changes were prompted by weaknesses exposed by test cases
involving dynamically allocated objects.

The patch is intended to apply on top of the two related patches
posted last week ([1] and [2]).  For all tests to pass also expects
the fix for PR 92412 posted earlier today ([3]).

Martin

[1] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00429.html
[2] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
[3] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00800.html






PR middle-end/91582 - missing heap overflow detection for strcpy

gcc/ChangeLog:

	PR middle-end/91582
	* builtins.c (gimple_call_alloc_size): Add argument.
	* builtins.h (gimple_call_alloc_size): Same.
	* tree-ssa-strlen.c (strinfo::alloc): New member.
	(get_addr_stridx): Add argument.
	(get_stridx): Use ptrdiff_t.  Add argument.
	(new_strinfo): Set new member.
	(get_string_length): Handle alloca and VLA.
	(dump_strlen_info): Dump more state.
	(maybe_invalidate): Print more info.  Decrease indentation.
	(unshare_strinfo): Set new member.
	(valid_builtin_call): Handle alloca and VLA.
	(maybe_warn_overflow): Check and set no-warning bit.  Improve
	handling of offsets.  Print allocated objects.
	(handle_builtin_strlen): Handle strinfo records with null lengths.
	(handle_builtin_strcpy): Add argument.  Call maybe_warn_overflow.
	(is_strlen_related_p): Handle dynamically allocated objects.
	(get_range): Add argument.
	(handle_builtin_malloc): Rename...
	(handle_aalloc): ...to this and handle all allocation functions.
	(handle_builtin_memset): Call maybe_warn_overflow.
	(count_nonzero_bytes): Handle more MEM_REF forms.
	(strlen_check_and_optimize_call): Call handle_alloc_call.  Pass
	arguments to more callees.
	(handle_integral_assign): Add argument.  Create strinfo entries
	for MEM_REF assignments.
	(check_and_optimize_stmt): Handle more MEM_REF forms.

gcc/testsuite/ChangeLog:

	PR middle-end/91582
	* c-c++-common/Wrestrict.c: Adjust expected warnings.
	* gcc.dg/Warray-bounds-46.c: Disable -Wstringop-overflow.
	* gcc.dg/Warray-bounds-47.c: Same.
	* gcc.dg/Warray-bounds-52.c: New test.
	* gcc.dg/Wstringop-overflow-26.c: New test.
	* gcc.dg/Wstringop-overflow-27.c: New test.
	* gcc.dg/Wstringop-overflow-28.c: New test.
	* gcc.dg/attr-alloc_size.c (test): Disable -Warray-bounds.
	* gcc.dg/attr-copy-2.c: Adjust expected warnings.
	* gcc.dg/builtin-stringop-chk-5.c: Adjust text of expected messages.
	* gcc.dg/strlenopt-86.c: Relax test.
	* gcc.target/i386/pr82002-1.c: Prune expected warnings.

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 1ee84f343a3..5db0bd3226c 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "calls.h"
 #include "varasm.h"
 #include "tree-object-size.h"
+#include "tree-ssa-strlen.h"
 #include "realmpfr.h"
 #include "cfgrtl.h"
 #include "except.h"
@@ -3697,10 +3698,12 @@ check_access (tree exp, tree, tree, tree dstwrite,
 }
 
 /* If STMT is a call to an allocation function, returns the size
-   of the object allocated by the call.  */
+   of the object allocated by the call.  If nonnull, set 

Re: C++ PATCH for c++/91678 - wrong error with decltype and location wrapper

[Marek Polacek]

[ Sorry for dropping the ball on this. ]

On Tue, Sep 17, 2019 at 11:59:02PM -0400, Jason Merrill wrote:
> On 9/16/19 1:12 PM, Marek Polacek wrote:
> > On Sun, Sep 15, 2019 at 10:18:29AM -0400, Jason Merrill wrote:
> > > On 9/5/19 9:24 PM, Marek Polacek wrote:
> > > > They use
> > > > non_lvalue_loc, but that won't create a NON_LVALUE_EXPR wrapper around 
> > > > a location
> > > > wrapper.
> > > 
> > > That seems like the bug. maybe_lvalue_p should be true for
> > > VIEW_CONVERT_EXPR.
> > 
> > That makes sense but it breaks in tsubst_* which doesn't expect a
> > NON_LVALUE_EXPR wrapped around a location wrapper.
> 
> Hmm, why would we get that in a template when we don't get NON_LVALUE_EXPR
> wrapped around other lvalue nodes?

I just retested the patch without the pt.c hunk and no longer see that problem,
and the fold-const.c hunk still fixes the bogus error.  Yay?

So I think the following should be good to go:

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

2019-12-06  Marek Polacek  

PR c++/91678 - wrong error with decltype and location wrapper.
* fold-const.c (maybe_lvalue_p): Handle VIEW_CONVERT_EXPR.

* g++.dg/cpp0x/decltype73.C: New test.

--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -2594,6 +2594,7 @@ maybe_lvalue_p (const_tree x)
   case TARGET_EXPR:
   case COND_EXPR:
   case BIND_EXPR:
+  case VIEW_CONVERT_EXPR:
 break;
 
   default:
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/decltype73.C
@@ -0,0 +1,4 @@
+// PR c++/91678 - wrong error with decltype and location wrapper.
+// { dg-do compile { target c++11 } }
+
+float* test(float* c) { return (decltype(c + 0))(float*)c; }

Re: [PATCH] Come up with constructors of symtab_node, cgraph_node and varpool_node.

[Bernhard Reutner-Fischer]

On 5 December 2019 16:24:53 CET, "Martin Liška"  wrote:

-/* Allocate new callgraph node.  */
-
-inline cgraph_node *
-symbol_table::allocate_cgraph_symbol (void)
-{
-  cgraph_node *node;
-
-  node = ggc_cleared_alloc ();
-  node->type = SYMTAB_FUNCTION;
-  node->m_summary_id = -1;
-  node->m_uid = cgraph_max_uid++;
-  return node;
-}

Just because I don't see it in the patch, how is cgraph_max_uid++ maintained 
after that patch?

thanks,

Re: Add a new combine pass

[Oleg Endo]

On Fri, 2019-12-06 at 16:51 -0600, Segher Boessenkool wrote:
> On Wed, Dec 04, 2019 at 07:43:30PM +0900, Oleg Endo wrote:
> > On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> > > > Hmm ... the R0 problem ... SH doesn't override class_likely_spilled
> > > > explicitly, but it's got a R0_REGS class with only one said reg in it. 
> > > > So the default impl of class_likely_spilled should do its thing.
> > > 
> > > Yes, good point.  So what happened here?
> > 
> > "Something, somewhere, went terribly wrong"...
> > 
> > insn 18 wants to do
> > 
> > mov.l @(r4,r6),r0
> > 
> > But it can't because the reg+reg address mode has a R0 constraint
> > itself.  So it needs to be changed to
> > 
> > mov   r4,r0
> > mov.l @(r0,r6),r0
> > 
> > And it can't handle that.  Or only sometimes?  Don't remember.
> > 
> > >   Is it just RA messing things
> > > up, unrelated to the new pass?
> > 
> > Yep, I think so.  The additional pass seems to create "tougher" code so
> > reload passes out earlier than usual.  We've had the same issue when
> > trying address mode selection optimization.  In fact that was one huge
> > showstopper.
> 
> So maybe you should have a define_insn_and_split that allows any two
> regs and replaces one by r0 if neither is (and a move to r0 before the
> load)?  Split after reload of course.
> 
> It may be admitting defeat, but it may even result in better code as
> well ;-)
> 

AFAIR I've tried that already and it was just like running in circles. 
Means it didn't help.  Perhaps if R0_REGS was hidden from RA altogether
it might work.  But that sounds like opening a whole other can of
worms.  Another idea I was entertaining was to do a custom RTL pass to
pre-allocate all R0 constraints before the real full RA.  But then the
whole reload stuff would still have the same issue as above.  So all
the wallpapering is just moot.  Proper fix of the actual problem would
be more appropriate.

Cheers,
Oleg

[committed] Fix up xvalue handling in ?: with omitted middle operand (PR c++/92831)

[Jakub Jelinek]

On Fri, Dec 06, 2019 at 02:31:55PM -0500, Jason Merrill wrote:
> > Note, just to double check g++ doesn't ICE on expr1 ? : expr2 GNU extension,
> > I also wrote the attached testcase, but unlike the testcase included in the
> > patch which behaves the same with patched g++ as does recent clang++, the
> > testcase with expr1 ? : expr2 (omitted second operand) actually never
> > extends the lifetime of any temporary (that is the baz function), unlike
> > clang++ which extends the lifetime of expr2 if expr1 is false, and doesn't
> > extend lifetime of anything if expr1 is true.  This is outside of the scope
> > of the standard, so no idea what is correct, so I'm just asking how it
> > should behave.
> 
> I would expect one or the other to be extended.  I imagine that clang not
> extending expr1 is a bug due to however they avoid evaluating it twice.
> 
> > extend_ref_init_temps_1 is never called in that case when the expression is 
> > COND_EXPR.
> 
> I think the problem is in build_conditional_expr_1, which needs to treat
> xvalues properly in the handling of this extension, i.e.
> 
> > -  if (lvalue_p (arg1))
> > +  if (glvalue_p (arg1))
> > arg2 = arg1 = cp_stabilize_reference (arg1);

Indeed, that fixes it and you've preapproved a patch doing that on IRC, which 
I've
committed to trunk now that it successfully bootstrapped/regtested on
x86_64-linux and i686-linux.  Thanks.

2019-12-07  Jason Merrill  
Jakub Jelinek  

PR c++/92831
* call.c (build_conditional_expr_1): For ?: with omitted middle
operand use cp_stabilize_reference if arg1 is glvalue_p rather than
just if it is lvalue_p.

* g++.dg/ext/temp-extend1.C: New test.

--- gcc/cp/call.c.jj2019-12-06 21:15:48.842199643 +0100
+++ gcc/cp/call.c   2019-12-06 22:01:18.737636630 +0100
@@ -5077,7 +5077,7 @@ build_conditional_expr_1 (const op_locat
warn_for_omitted_condop (loc, arg1);
 
   /* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C.  */
-  if (lvalue_p (arg1))
+  if (glvalue_p (arg1))
arg2 = arg1 = cp_stabilize_reference (arg1);
   else
arg2 = arg1 = cp_save_expr (arg1);
--- gcc/testsuite/g++.dg/ext/temp-extend1.C.jj  2019-12-06 22:10:45.489814074 
+0100
+++ gcc/testsuite/g++.dg/ext/temp-extend1.C 2019-12-06 22:10:09.495374051 
+0100
@@ -0,0 +1,43 @@
+// PR c++/92831
+// { dg-do run { target c++11 } }
+// { dg-options "" }
+
+template using id = T;
+struct S { S () : s (false) { ++c; } S (bool x) : s (x) { ++c; } ~S () { --c; 
}; bool s; static int c; };
+int S::c = 0;
+
+void
+foo (int i)
+{
+  const bool&& a
+= id{false, true, false}[i].s
+  ? id{true, false}[i].s : id{true, false, true, false}[i].s;
+  if (S::c != (i ? 2 : 4))
+__builtin_abort ();
+}
+
+void
+baz (int i)
+{
+  const bool&& a = id{false, true, false}[i].s
+  ? : id{true, false, true, false}[i].s;
+  if (S::c != (i ? 3 : 4))
+__builtin_abort ();
+}
+
+int
+main ()
+{
+  foo (0);
+  if (S::c != 0)
+__builtin_abort ();
+  foo (1);
+  if (S::c != 0)
+__builtin_abort ();
+  baz (0);
+  if (S::c != 0)
+__builtin_abort ();
+  baz (1);
+  if (S::c != 0)
+__builtin_abort ();
+}


Jakub

Re: [PATCH 1/2] pretty-print: support URL escape sequences (PR 87488)

[Jakub Jelinek]

On Thu, Oct 10, 2019 at 01:06:13PM -0400, David Malcolm wrote:
> https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
> describes an emerging standard for embedding URLs in escape sequences
> for marking up text output.  This is supported e.g. by recent releases
> of GNOME Terminal.

Unfortunately, as reported by several people, the
OSC 8 ;; URL ST Text OSC 8 ;; ST
sequence renders badly on recentish konsole5 terminal emulator, which is
something a lot of people use.
While the above page suggests the use of ST rather than BEL, in practice
that at least currently does better job.
Tested with
echo -e '\e]8;;http://example.com\aThis is a 
link\e]8;;\a\n\e]8;;http://example.com\e\\This is a link\e]8;;\e\\\n'
on various terminals:
gnome-terminal-3.30.2 both lines the same, URLs work
konsole5-18.12.3 the first line normal text, the second one wrapped in
 between \s, i.e. \This is a link\ , URLs don't work
xterm-334 both lines the same, normal text, URLs don't work
rxvt-2.7.10 ditto
xterm-314 ditto
konsole5-15.12.1 ditto
linux kernel 5.0.13 console ditto
linux kernel 4.4.14 console ditto
gnome-terminal-3.16.2 prints garbage around and both the URL and the text
  are visible, but the line with ST has more garbage
  than line with BEL

BEL instead of ST is also what ls -l --hyperlink prints.

Ok for trunk?

2019-12-07  Jakub Jelinek  

* pretty-print.c (pp_begin_url, pp_end_url, test_urls): Use BEL
instead of ST sequence to terminate OSC 8 strings.

--- gcc/pretty-print.c.jj   2019-10-11 09:29:15.103953133 +0200
+++ gcc/pretty-print.c  2019-12-07 00:17:00.860500837 +0100
@@ -2043,7 +2043,10 @@ identifier_to_locale (const char *ident)
>
> OSC 8 ; ; ST
>
-   > OSC (operating system command) is typically ESC ].  */
+   > OSC (operating system command) is typically ESC ].
+
+   Use BEL instead of ST, as that is currently rendered better in some
+   terminal emulators that don't support OSC 8, like konsole5.  */
 
 /* If URL-printing is enabled, write an "open URL" escape sequence to PP
for the given URL.  */
@@ -2052,7 +2055,7 @@ void
 pp_begin_url (pretty_printer *pp, const char *url)
 {
   if (pp->show_urls)
-pp_printf (pp, "\33]8;;%s\33\\", url);
+pp_printf (pp, "\33]8;;%s\a", url);
 }
 
 /* If URL-printing is enabled, write a "close URL" escape sequence to PP.  */
@@ -2061,7 +2064,7 @@ void
 pp_end_url (pretty_printer *pp)
 {
   if (pp->show_urls)
-pp_string (pp, "\33]8;;\33\\");
+pp_string (pp, "\33]8;;\a");
 }
 
 #if CHECKING_P
@@ -2369,7 +2372,7 @@ test_urls ()
 pp_begin_url (, "http://example.com;);
 pp_string (, "This is a link");
 pp_end_url ();
-ASSERT_STREQ ("\33]8;;http://example.com\33\\This is a link\33]8;;\33\\",
+ASSERT_STREQ ("\33]8;;http://example.com\aThis is a link\33]8;;\a",
  pp_formatted_text ());
   }
 }


Jakub

Re: [PATCH] rs6000: Fix 2 for PR92661, Do not define builtins that overload disabled builtins

[Segher Boessenkool]

On Thu, Dec 05, 2019 at 08:44:57AM +, Iain Sandoe wrote:
> .. or I can just force a false return from effective_target_dfp as we
>  do for other cases where assembler support does not imply system 
>  support.

That's what I would do, yes.


Segher

Re: PowerPC V9 patches, Add the PCREL_OPT optimization

[Segher Boessenkool]

On Thu, Dec 05, 2019 at 10:14:13AM +1030, Alan Modra wrote:
> On Wed, Dec 04, 2019 at 05:16:05PM -0600, Segher Boessenkool wrote:
> > >  pla 9,ext_symbol@pcrel  # add (0),1 for optional operands
> > 
> > pla does not have optional operands like that?
> 
> It does, just like load/store insns.

That is not what my documentation says?


Segher

Re: Add a new combine pass

[Segher Boessenkool]

On Wed, Dec 04, 2019 at 07:43:30PM +0900, Oleg Endo wrote:
> On Tue, 2019-12-03 at 12:05 -0600, Segher Boessenkool wrote:
> > > Hmm ... the R0 problem ... SH doesn't override class_likely_spilled
> > > explicitly, but it's got a R0_REGS class with only one said reg in it. 
> > > So the default impl of class_likely_spilled should do its thing.
> > 
> > Yes, good point.  So what happened here?
> 
> "Something, somewhere, went terribly wrong"...
> 
> insn 18 wants to do
> 
> mov.l @(r4,r6),r0
> 
> But it can't because the reg+reg address mode has a R0 constraint
> itself.  So it needs to be changed to
> 
> mov   r4,r0
> mov.l @(r0,r6),r0
> 
> And it can't handle that.  Or only sometimes?  Don't remember.
> 
> >   Is it just RA messing things
> > up, unrelated to the new pass?
> 
> Yep, I think so.  The additional pass seems to create "tougher" code so
> reload passes out earlier than usual.  We've had the same issue when
> trying address mode selection optimization.  In fact that was one huge
> showstopper.

So maybe you should have a define_insn_and_split that allows any two
regs and replaces one by r0 if neither is (and a move to r0 before the
load)?  Split after reload of course.

It may be admitting defeat, but it may even result in better code as
well ;-)


Segher

Re: [mid-end] Add notes to dataflow insn info when re-emitting (PR92410)

[Jeff Law]

On Tue, 2019-11-12 at 09:11 +, Matthew Malcomson wrote:
> In scheduling passes, notes are removed with `remove_notes` before
> the
> 
> scheduling is done, and added back in with `reemit_notes` once the
> 
> scheduling has been decided.
> 
> 
> 
> This process leaves the notes in the RTL chain with different insn
> uid's
> 
> than were there before.  Having different UID's (larger than the
> 
> previous ones) means that DF_INSN_INFO_GET(insn) will access outside
> of
> 
> the allocated array.
> 
> 
> 
> This has been seen in the `regstat_bb_compute_calls_crossed`
> function.
> 
> This patch adds an assert to the `regstat_bb_compute_calls_crossed`
> 
> function so that bad accesses here are caught instead of going
> 
> unnoticed, and then avoids the problem.
> 
> 
> 
> We avoid the problem by ensuring that new notes added by
> `reemit_notes` have an
> 
> insn record given to them.  This is done by adding a call to
> 
> `df_insn_create_insn_record` on each note added in `reemit_notes`.
> 
> `df_insn_create_insn_record` leaves this new record zeroed out, which
> appears
> 
> to be fine for notes (e.g. `df_bb_refs_record` already does not set
> 
> anything except the luid for notes, and notes have no dataflow
> information to
> 
> record).
> 
> 
> 
> We add the testcase that Martin found here
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410#c2 .
> 
> This testcase fails with the "regstat.c" change, and then succeeds
> with the
> 
> "haifa-sched.c" change.
> 
> 
> 
> There is a similar problem with labels, that the `gcc_assert` catches
> 
> when running regression tests in gcc.dg/fold-eqandshift-1.c and
> 
> gcc.c-torture/compile/pr32482.c.
> 
> This is due to the `cfg_layout_finalize` call in `bb-reorder.c`
> emitting
> 
> new labels for the start of the newly created basic blocks. These
> labels are
> 
> not given a dataflow df_insn_info member.
> 
> 
> 
> We solve this by manually calling `df_recompute_luids` on each basic
> 
> block once this pass has finished.
> 
> 
> 
> Testing done:
> 
>   Bootstrapped and regression test on aarch64-none-linux-gnu native.
> 
> 
> 
> gcc/ChangeLog:
> 
> 
> 
> 2019-11-12  Matthew Malcomson  
> 
> 
> 
> PR middle-end/92410
> 
> * bb-reorder.c (pass_reorder_blocks::execute): Recompute
> 
> dataflow luids once basic blocks have been reordered.
> 
> * haifa-sched.c (reemit_notes): Create df insn record for
> each
> 
> new note.
> 
> * regstat.c (regstat_bb_compute_calls_crossed): Assert every
> 
> insn has an insn record before trying to use it.
> 
> 
> 
> gcc/testsuite/ChangeLog:
> 
> 
> 
> 2019-11-12  Matthew Malcomson  
> 
> 
> 
> PR middle-end/92410
> 
> * gcc.dg/torture/pr92410.c: New test.
> 
OK
jeff

Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches

[Jeff Law]

On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote:
> 
> I bootstrapped and regression-tested this on x86_64-linux-gnu.  There
> are a few regressions involving these tests:
> 
> gcc.dg/tree-ssa/pr77445-2.c
I believe tihs is another instance of the FSA optimization.  I'd need
to see the before/after dumps to know if it's regressed.  The main
purpose of the test was to verify that we didn't muck up the profile
estimation after the FSA optimization.


> gcc.dg/tree-ssa/ssa-dce-3.c
So I think this one is supposed to collapse into a trivial infinite
loop.  Anything else would be a regression.


> gcc.dg/tree-ssa/ssa-dom-thread-7.c
This is the FSA optimization.  Unfortunately checking for it being done
right is exceedingly painful.  If you pass along the before/after dumps
I can probably help determine whether or not we just need an update to
the scanned bits.

Given how much pressure there was to handle the FSA optimization, I'd
prefer to make sure we're still doing it before moving forward.

jeff

Re: [PATCH 16/49] Add support for in-tree plugins

[Eric Gallager]

On 11/15/19, David Malcolm  wrote:
> This patch adds support for "in-tree" plugins i.e. GCC plugins that live
> in the GCC source tree and are shipped as part of the GCC tarball.

Nick Clifton was asking us to do something like this anyways in his
talk at Cauldron on his annobin plugin; it might be worthwhile to add
support for in-tree plugins regardless of whether the analyzer ends up
being an in-tree plugin itself or not.

>
> The patch adds Makefile/configure machinery for handling in-tree GCC
> plugins, adapted from how we support frontends.
>
> Each in-tree plugin should provide a Make-plugin.in and config-plugin.in,
> analogous to the Make-lang.in and config-lang.in provided by a frontend;
> they can also supply options via a plugin.opt, analogous to a frontend's
> lang.opt.
>
> The patch adds a --enable-plugins=[LIST OF PLUGIN NAMES] configure option,
> analogous to --enable-languages.  The default is for no such plugins to be
> enabled.
>
> ChangeLog:
>   * configure.ac: Handle --enable-plugins.
>
> gcc/ChangeLog:
>   * Makefile.in (CONFIG_PLUGINS): New.
>   (SUBDIRS, subdirs): Generalize to cover plugins as well as
>   languages.
>   (plugin_opt_files): New.
>   (ALL_OPT_FILES): Add plugin_opt_files.
>   (ALL_HOST_PLUGIN_OBJS): New.
>   (ALL_HOST_OBJS): Add ALL_HOST_PLUGIN_OBJS.
>   (plugin_hooks): New.
>   (PLUGIN_MAKEFRAGS): New; include them.
>   (Makefile): Add dependency on PLUGIN_MAKEFRAGS.
>   (all.cross): Add dependency on plugin.all.cross.
>   (start.encap): Add plugin.start.encap.
>   (rest.encap): Add plugin.rest.encap.
>   (SELFTEST_TARGETS): Add selftest_plugins.
>   (info): Add dependency on lang.info.
>   (dvi): Add dependency on plugin.dvi.
>   (pdf): Add dependency on plugin.pdf.
>   (HTMLS_BUILD): Add plugin.html.
>   (man): Add plugin.man.
>   (mostlyclean): Add plugin.mostlyclean.
>   (clean): Add plugin.clean.
>   (distclean): Update for renaming of Make-hooks to Make-lang-hooks;
>   add Make-plugin-hooks.  Add plugin.distclean dependency.
>   (maintainer-clean): Add plugin.maintainer-clean.
>   (install-plugin): Add plugin.install-plugin.
>   (install-common): Add plugin.install-common.
>   (install-info): Add plugin.install-info.
>   (install-pdf): Add plugin.install-pdf.
>   (install-html): Add plugin.install-html.
>   (install-man): Add plugin.install-man.
>   (uninstall): Add plugin.uninstall.
>   (TAGS): Add plugin.tags.
>   * configure.ac (Make-hooks): Rename to Make-lang-hooks.
>   (plugin_opt_files): New.
>   (plugin_specs_files): New.
>   (plugin_tree_files): New.
>   (all_plugins): New.
>   (all_plugin_makefrags): New.
>   (all_selected_plugins): New.
>   (plugin_hooks): New.
>   ("Plugin hooks"): New section.  Iterate through config-plugin.in,
>   analogously to config-lang.in.
>   (check_plugins): New.
>   (selftest_plugins): New.
>   (Make-plugin-hooks): Emit.
>   * doc/install.texi (--enable-plugins): New option.
> ---
>  configure.ac |   6 ++
>  gcc/Makefile.in  |  98 -
>  gcc/configure.ac | 172
> +--
>  gcc/doc/install.texi |   9 +++
>  4 files changed, 251 insertions(+), 34 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index b8ce2ad..9b8b8ab 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2188,6 +2188,12 @@ Supported languages are: ${potential_languages}])
>ac_configure_args=`echo " $ac_configure_args" | sed -e "s/
> '--enable-languages=[[^ ]]*'//g" -e "s/$/
> '--enable-languages="$enable_languages"'/" `
>  fi
>
> +# Look if the user specified --enable-plugins="..."
> +if test -d ${srcdir}/gcc; then
> +  enable_plugins=`echo "${enable_plugins}" | sed -e 's/[[,]][[   
> ,]]*/,/g'
> -e 's/,$//'`
> +  ac_configure_args=`echo " $ac_configure_args" | sed -e "s/
> '--enable-plugins=[[^ ]]*'//g" -e "s/$/
> '--enable-plugins="$enable_plugins"'/" `
> +fi
> +
>  # Handle --disable- generically.
>  for dir in $configdirs $build_configdirs $target_configdirs ; do
>dirname=`echo $dir | sed -e s/target-//g -e s/build-//g -e s/-/_/g`
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 5feef6a..c0dfbde 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -132,7 +132,7 @@ CROSS=@CROSS@
>  # Variables that exist for you to override.
>  # See below for how to change them for certain systems.
>
> -# List of language subdirectories.
> +# List of language and plugin subdirectories.
>  SUBDIRS =@subdirs@ build
>
>  # Selection of languages to be made.
> @@ -142,6 +142,8 @@ ifeq (@enable_gcov@,yes)
>  LANGUAGES += gcov$(exeext) gcov-dump$(exeext) gcov-tool$(exeext)
>  endif
>
> +CONFIG_PLUGINS = @all_selected_plugins@
> +
>  # Default values for variables overridden in Makefile fragments.
>  # CFLAGS is for the user to override to, e.g., do a cross build with 

Re: [PATCH 00/49] RFC: Add a static analysis framework to GCC

[Jeff Law]

On Wed, 2019-12-04 at 12:55 -0700, Martin Sebor wrote:
> On 11/15/19 6:22 PM, David Malcolm wrote:
> > This patch kit introduces a static analysis pass for GCC that can
> > diagnose
> > various kinds of problems in C code at compile-time (e.g. double-
> > free,
> > use-after-free, etc).
> 
> I haven't looked at the analyzer bits in any detail yet so I have
> just some very high-level questions.  But first let me say I'm
> excited to see this project! :)
> 
> It looks like the analyzer detects some of the same problems as
> some existing middle-end warnings (e.g., -Wnonnull, -Wuninitialized),
> and some that I have been working toward implementing (invalid uses
> of freed pointers such as returning them from functions or passing
> them to others), and others still that I have been thinking about
> as possible future projects (e.g., detecting uses of uninitialized
> arrays in string functions).
> 
> What are your thoughts about this sort of overlap?  Do you expect
> us to enhance both sets of warnings in parallel, or do you see us
> moving away from issuing warnings in the middle-end and toward
> making the analyzer the main source of these kinds of diagnostics?
> Maybe even replace some of the problematic middle-end warnings
> with the analyzer?  What (if anything) should we do about warnings
> issued for the same problems by both the middle-end and the analyzer?
> Or about false negatives?  E.g., a bug detected by the middle-end
> but not the analyzer or vice versa.
> 
> What do you see as the biggest pros and cons of either approach?
> (Middle-end vs analyzer.)  What limitations is the analyzer
> approach inherently subject to that the middle-end warnings aren't,
> and vice versa?
> 
> How do we prioritize between the two approaches (e.g., choose
> where to add a new warning)?
Given the cost of David's analyzer, I would tend to prioritize the more
localized analysis.  Also note that because of the compile-time
complexities we end up pruning paths from the search space and lose
precision when we have to merge nodes.   These issues are inherent in
the depth of analysis we're looking to do.

So the way to think about things is David's work is a slower, deeper
analysis than what we usually do.  So things that are reasonable
candidates for -Wall would need to use the traditional mechansisms. 
Things that require deeper analysis would be done in David's framework.

Also note that part of David's work is to bring a fairly generic engine
that we can expand with different domain specific analyzers.  It just
happens to be the case that the first place he's focused is on double-
free and use-after-free.  But (IMHO) the gem is really the generic
engine.

jeff

Re: [PATCH 00/49] RFC: Add a static analysis framework to GCC

[Jeff Law]

On Tue, 2019-12-03 at 11:52 -0500, David Malcolm wrote:
> On Wed, 2019-11-20 at 11:18 +0100, Richard Biener wrote:
> > On Tue, Nov 19, 2019 at 11:02 PM David Malcolm  > >
> > wrote:
> > > > > The checker is implemented as a GCC plugin.
> > > > > 
> > > > > The patch kit adds support for "in-tree" plugins i.e. GCC
> > > > > plugins
> > > > > that
> > > > > would live in the GCC source tree and be shipped as part of
> > > > > the
> > > > > GCC
> > > > > tarball,
> > > > > with a new:
> > > > >   --enable-plugins=[LIST OF PLUGIN NAMES]
> > > > > configure option, analogous to --enable-languages (the
> > > > > Makefile/configure
> > > > > machinery for handling in-tree GCC plugins is adapted from
> > > > > how
> > > > > we
> > > > > support
> > > > > frontends).
> > > > 
> > > > I like that.  Implementing this as a plugin surely must help to
> > > > either
> > > > document the GCC plugin interface as powerful/mature for such a
> > > > task.  Or
> > > > make it so, if it isn't yet.  ;-)
> > > 
> > > Our plugin "interface" as such is very broad.
> > 
> > Just to sneak in here I don't like exposing our current plugin
> > "non-
> > API"
> > more.  In fact I'd just build the analyzer into GCC with maybe an
> > option to disable its build (in case it is very fat?).
> 
> My aim here is to provide a way for distributors to be able to
> disable
> its build - indeed, for now, for it to be disabled by default,
> requiring opting-in.
It seems like there's some move to have this as part of the core
compiler rather than as a plug-in.  That's a bit of a surprise, but a
good one.


> I want some way to label the code as a "technology preview", that
> people may want to experiment with, but to set expectations that this
> is a lot of new code and there will be bugs - but to make it
> available
> to make it easier for adventurous users to try it out.
> 
> I hope that makes sense.
> 
> I went down the "in-tree plugin" path by seeing the analogy with
> frontends, but yes, it would probably be simpler to just build it
> into
> GCC, guarded with a configure-time variable.  It's many thousand
> lines
> of non-trivial C++ code, and associated selftests and DejaGnu tests.
Given the overall feedback, core component with an opt-out seems like
it'd be best.

jeff
> 

Re: [PATCH] [libiberty] Fix read buffer overflow in split_directories

[Jeff Law]

On Thu, 2019-11-28 at 22:10 +0100, Tim Rühsen wrote:
> An empty name param leads to read buffer overflow in
> function split_directories.
> 
> * libiberty/make-relative-prefix.c (split_directories):
>   Return early on empty name.
> ---
>  libiberty/ChangeLog  | 7 +++
>  libiberty/make-relative-prefix.c | 3 +++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog
> index b516903d94..b7e24d11ef 100644
> --- a/libiberty/ChangeLog
> +++ b/libiberty/ChangeLog
> @@ -1,3 +1,10 @@
> +2019-11-28  Tim Ruehsen  
> +
> +   Fix read buffer overflow in split_directories
> +
> +   * make-relative-prefix.c (split_directories):
> +   Return early on empty 'name'
> +
THanks.  Installed on the trunk.
jeff

[committed] Add test for c++/92451

[Marek Polacek]

This was ICEing from r277865 to r278786.

Tested on x86_64-linux, applying to trunk.

2019-12-06  Marek Polacek  

PR c++/92451
* g++.dg/overload/error4.C: New test.

--- /dev/null
+++ gcc/testsuite/g++.dg/overload/error4.C
@@ -0,0 +1,6 @@
+// PR c++/92451
+
+template struct Local {};
+void f() {
+  Local(int); // { dg-error "" }
+}

Re: Fix profile updatin in tree-ssa-threadupdate

[Jeff Law]

On Thu, 2019-12-05 at 11:12 +0100, Jan Hubicka wrote:
> Hi,
> this patch makes tree-ssa-threadupdate to not leave basic blocks with
> undefined counts in the program.  
> 
> create_block_for_threading sets counts as follows:
> 
>   /* Zero out the profile, since the block is unreachable for
> now.  */
>   rd->dup_blocks[count]->count = profile_count::uninitialized ();
> 
> which is usually set to correct count in update_profile. However
> template_blocks are not seen by it and thus this patch calculates the
> profile while redirecting edgs to it.
> 
> Bootstrapped/regtested x86_64-linux and also checked that the profile
> is
> correct. Does it make sense?  There is no testcase since I plan to
> commit sanity check that triggers several times during the testsuite
> and
> bootstrap w/o this patch.

I would have expected a call to update_profile even in the case of the
template block.

ISTM we would call ssa_fixup_template_block, which in turn would call
ssa_fix_duplicate_block_edges which in turn would have called
update_profile.

jeff

Re: Fix @multitable handling in texi2pod.pl

[Jeff Law]

On Fri, 2019-12-06 at 10:17 +, Richard Sandiford wrote:
> While trying out Dennis's Armv8.6-A patch, I noticed that texi2pod.pl
> didn't handle the new @multitable correctly.  There were two
> problems:
> 
> (1) @multitables nested in other @tables inherited the @item type
> from
> the enclosing @table.  Since the new @multitable is in a @table
> @samp,
> we applied @samp markup to the @multitable @items.  This in turn
> meant that it captured the @tab separator in the @item markup.
> 
> Fixed by pushing an empty item code onto the stack.
> 
> (2) We didn't handle @headitem.  Fixed by enclosing it in italics,
> like we do for section headings.  This causes it to be underlined
> in the man output.
> 
> Tested by making sure that it doesn't change the current gcc.pod
> output,
> but fixes the problems mentioned above when the new @multitable is
> added.
> OK to install?
> 
> Richard
> 
> 
> 2019-12-05  Richard Sandiford  
> 
> contrib/
>   * texi2pod.pl: Handle @headitems in @multitables, printing them
>   in italics.  Push an empty item code onto the stack.
OK
jeff
> 

Re: [C++ Patch] Improve build_*_cast locations

[Paolo Carlini]

Hi,

On 06/12/19 18:53, Jason Merrill wrote:

On 12/6/19 11:14 AM, Paolo Carlini wrote:

Hi,

as promised, the below takes care of the various remaining casts. 
It's mostly mechanical, follows the same approach used for 
build_functional_cast. Tested x86_64-linux.


It occurs to me that once we're passing the location into the build_* 
functions, we can apply it to the expression there rather than in the 
parser.


In fact that occurred to me too ;) but at first I didn't like the idea 
of multiplying the set_location calls... Anyway, in practice for the 
casts of this last patch the idea works reasonably well, because most of 
the complexity is encapsulated in the *_1 versions of the functions and 
the build_* functions proper have only a couple of returns. I wanted to 
send those changes... But then my build failed in the libcp1plugin.cc 
bits because the switch also includes c_cast and all the functions must 
return the same type. And then for consistency we want also to adjust 
functional_cast (which allows to remove the set_location in the parser 
which also remained after my previous patch). Those two cast however are 
more annoying, because there aren't *_1 counterparts and the functions 
have *lots* of returns, are complicated. Thus for those I'm proposing to 
create ad hoc *_1 identical to the current functions in order to have 
single set_location in cp_build_c_cast and build_functional_cast. All in 
all, I don't have better ideas... I'm finishing testing the below.


Thanks, Paolo.

//

Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 279041)
+++ gcc/cp/cp-tree.h(working copy)
@@ -6998,7 +6998,8 @@ extern tree build_typeid  (tree, 
tsubst_flags_t);
 extern tree get_tinfo_decl (tree);
 extern tree get_typeid (tree, tsubst_flags_t);
 extern tree build_headof   (tree);
-extern tree build_dynamic_cast (tree, tree, tsubst_flags_t);
+extern cp_expr build_dynamic_cast  (location_t, tree, tree,
+tsubst_flags_t);
 extern void emit_support_tinfos(void);
 extern bool emit_tinfo_decl(tree);
 
@@ -7547,13 +7548,17 @@ extern tree build_x_compound_expr   
(location_t, tr
 tsubst_flags_t);
 extern tree build_compound_expr (location_t, tree, tree);
 extern tree cp_build_compound_expr (tree, tree, tsubst_flags_t);
-extern tree build_static_cast  (tree, tree, tsubst_flags_t);
-extern tree build_reinterpret_cast (tree, tree, tsubst_flags_t);
-extern tree build_const_cast   (tree, tree, tsubst_flags_t);
+extern cp_expr build_static_cast   (location_t, tree, tree,
+tsubst_flags_t);
+extern cp_expr build_reinterpret_cast  (location_t, tree, tree,
+tsubst_flags_t);
+extern cp_expr build_const_cast(location_t, tree, tree,
+tsubst_flags_t);
 extern tree build_c_cast   (location_t, tree, tree);
 extern cp_expr build_c_cast(location_t loc, tree type,
 cp_expr expr);
-extern tree cp_build_c_cast(tree, tree, tsubst_flags_t);
+extern cp_expr cp_build_c_cast (location_t, tree, tree,
+tsubst_flags_t);
 extern cp_expr build_x_modify_expr (location_t, tree,
 enum tree_code, tree,
 tsubst_flags_t);
@@ -7613,7 +7618,8 @@ extern int lvalue_or_else (tree, enum 
lvalue_use
 extern void check_template_keyword (tree);
 extern bool check_raw_literal_operator (const_tree decl);
 extern bool check_literal_operator_args(const_tree, bool *, 
bool *);
-extern void maybe_warn_about_useless_cast   (tree, tree, tsubst_flags_t);
+extern void maybe_warn_about_useless_cast   (location_t, tree, tree,
+tsubst_flags_t);
 extern tree cp_perform_integral_promotions  (tree, tsubst_flags_t);
 
 extern tree finish_left_unary_fold_expr  (tree, int);
@@ -7681,7 +7687,7 @@ extern tree build_scoped_ref  (tree, 
tree, tree *
 extern tree build_x_arrow  (location_t, tree,
 tsubst_flags_t);
 extern tree build_m_component_ref  (tree, tree, tsubst_flags_t);
-extern tree build_functional_cast  (location_t, tree, tree,
+extern cp_expr build_functional_cast

Re: [C++ PATCH] (temporarily) undefine __cpp_consteval

[Jason Merrill]

On 11/29/19 4:30 AM, Jakub Jelinek wrote:

Hi!

When submitting the P1902R1 patch for missing feature macros, I
completely forgot that we can't claim consteval support, because we have
the
   /* FIXME: For now.  */
   if (virtualp && (inlinep & 8) != 0)
 {
   sorry_at (DECL_SOURCE_LOCATION (decl),
 "% % method %qD not supported yet",
 decl);
   inlinep &= ~8;
 }
limitation in consteval support.  I've tried to make some progress on it
in PR88335, but am stuck, so this patch instead comments out this and
updates cxx-status.html to explain the partial support.

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


OK.


2019-11-29  Jakub Jelinek  

* c-cppbuiltin.c (c_cpp_builtins): Don't define __cpp_consteval for
now.

* g++.dg/cpp2a/feat-cxx2a.C: Don't test __cpp_consteval for now.

--- gcc/c-family/c-cppbuiltin.c.jj  2019-11-28 09:02:23.705869433 +0100
+++ gcc/c-family/c-cppbuiltin.c 2019-11-28 18:59:20.407918255 +0100
@@ -999,7 +999,7 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_designated_initializers=201707L");
  cpp_define (pfile, "__cpp_constexpr_in_decltype=201711L");
  cpp_define (pfile, "__cpp_conditional_explicit=201806L");
- cpp_define (pfile, "__cpp_consteval=201811L");
+ /* cpp_define (pfile, "__cpp_consteval=201811L"); */
  cpp_define (pfile, "__cpp_constinit=201907L");
  cpp_define (pfile, "__cpp_deduction_guides=201907L");
  cpp_define (pfile, "__cpp_nontype_template_parameter_class=201806L");
--- gcc/testsuite/g++.dg/cpp2a/feat-cxx2a.C.jj  2019-11-28 09:02:25.331844453 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/feat-cxx2a.C 2019-11-28 19:00:59.459400136 
+0100
@@ -520,11 +520,13 @@
  #  error "__cpp_constexpr_in_decltype != 201711"
  #endif
  
+/* Not supported fully yet:

  #ifndef __cpp_consteval
  #  error "__cpp_consteval"
  #elif __cpp_consteval != 201811
  #  error "__cpp_consteval != 201811"
  #endif
+*/
  
  #ifndef __cpp_concepts

  #  error "__cpp_concepts"

Jakub

Re: [C++ PATCH] Tweak concept diagnostics

[Jason Merrill]

On 12/6/19 3:20 PM, Jakub Jelinek wrote:

Hi!

I've noticed that while for requires keyword we have a diagnostics like
   error_at (cp_lexer_peek_token (parser->lexer)->location,
 "% only available with "
 "%<-std=c++2a%> or %<-fconcepts%>");
for concept keyword we emit
inform (location, "% only available with %<-fconcepts%>");
The following patch adjusts the latter to match the former, because I think
more people will use -std=c++2a than -fconcepts in the GCC 10 timeframe.

Tested on x86_64-linux, ok for trunk?


OK, thanks.


2019-12-06  Jakub Jelinek  

* parser.c (cp_parser_diagnose_invalid_type_name): Mention
that concept is also available with -std=c++2a.

--- gcc/cp/parser.c.jj  2019-12-05 10:03:04.072181899 +0100
+++ gcc/cp/parser.c 2019-12-06 19:40:44.090311079 +0100
@@ -3367,7 +3367,8 @@ cp_parser_diagnose_invalid_type_name (cp
inform (location, "C++20 % only available with "
"%<-std=c++2a%> or %<-std=gnu++2a%>");
else if (!flag_concepts && id == ridpointers[(int)RID_CONCEPT])
-   inform (location, "% only available with %<-fconcepts%>");
+   inform (location, "% only available with %<-std=c++2a%> or "
+   "%<-fconcepts%>");
else if (processing_template_decl && current_class_type
   && TYPE_BINFO (current_class_type))
{

Jakub

[C++ PATCH] Tweak concept diagnostics

[Jakub Jelinek]

Hi!

I've noticed that while for requires keyword we have a diagnostics like
  error_at (cp_lexer_peek_token (parser->lexer)->location,
"% only available with "
"%<-std=c++2a%> or %<-fconcepts%>");
for concept keyword we emit
inform (location, "% only available with %<-fconcepts%>");
The following patch adjusts the latter to match the former, because I think
more people will use -std=c++2a than -fconcepts in the GCC 10 timeframe.

Tested on x86_64-linux, ok for trunk?

2019-12-06  Jakub Jelinek  

* parser.c (cp_parser_diagnose_invalid_type_name): Mention
that concept is also available with -std=c++2a.

--- gcc/cp/parser.c.jj  2019-12-05 10:03:04.072181899 +0100
+++ gcc/cp/parser.c 2019-12-06 19:40:44.090311079 +0100
@@ -3367,7 +3367,8 @@ cp_parser_diagnose_invalid_type_name (cp
inform (location, "C++20 % only available with "
"%<-std=c++2a%> or %<-std=gnu++2a%>");
   else if (!flag_concepts && id == ridpointers[(int)RID_CONCEPT])
-   inform (location, "% only available with %<-fconcepts%>");
+   inform (location, "% only available with %<-std=c++2a%> or "
+   "%<-fconcepts%>");
   else if (processing_template_decl && current_class_type
   && TYPE_BINFO (current_class_type))
{

Jakub

Re: [PATCH 01/49] analyzer: user-facing documentation

[Eric Gallager]

While I get that this is just the documentation, having a good list
like this will make it easy to use to respond to the individual items
it documents, so that's what I'm going to use it for:

On 11/15/19, David Malcolm  wrote:
> gcc/ChangeLog:
>   * doc/invoke.texi ("Static Analyzer Options"): New list and new section.
>   ("Warning Options"): Add static analysis warnings to the list.
>   (-Wno-analyzer-double-fclose): New option.
>   (-Wno-analyzer-double-free): New option.
>   (-Wno-analyzer-exposure-through-output-file): New option.
>   (-Wno-analyzer-file-leak): New option.
>   (-Wno-analyzer-free-of-non-heap): New option.
>   (-Wno-analyzer-malloc-leak): New option.
>   (-Wno-analyzer-possible-null-argument): New option.
>   (-Wno-analyzer-possible-null-dereference): New option.
>   (-Wno-analyzer-null-argument): New option.
>   (-Wno-analyzer-null-dereference): New option.
>   (-Wno-analyzer-stale-setjmp-buffer): New option.
>   (-Wno-analyzer-tainted-array-index): New option.
>   (-Wno-analyzer-use-after-free): New option.
>   (-Wno-analyzer-use-of-pointer-in-stale-stack-frame): New option.
>   (-Wno-analyzer-use-of-uninitialized-value): New option.
>   (-Wanalyzer-too-complex): New option.
>   (-fanalyzer-call-summaries): New warning.
>   (-fanalyzer-checker=): New warning.
>   (-fanalyzer-fine-grained): New warning.
>   (-fno-analyzer-state-merge): New warning.
>   (-fno-analyzer-state-purge): New warning.
>   (-fanalyzer-transitivity): New warning.
>   (-fanalyzer-verbose-edges): New warning.
>   (-fanalyzer-verbose-state-changes): New warning.
>   (-fanalyzer-verbosity=): New warning.
>   (-fdump-analyzer): New warning.
>   (-fdump-analyzer-callgraph): New warning.
>   (-fdump-analyzer-exploded-graph): New warning.
>   (-fdump-analyzer-exploded-nodes): New warning.
>   (-fdump-analyzer-exploded-nodes-2): New warning.
>   (-fdump-analyzer-exploded-nodes-3): New warning.
>   (-fdump-analyzer-supergraph): New warning.
> ---
>  gcc/doc/invoke.texi | 420
> +++-
>  1 file changed, 418 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 085e8b0..384848a 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -153,6 +153,7 @@ listing and explanation of the binary and decimal byte
> size prefixes.
>  * Diagnostic Message Formatting Options:: Controlling how diagnostics
> should
>  be formatted.
>  * Warning Options:: How picky should the compiler be?
> +* Static Analyzer Options:: More expensive warnings.
>  * Debugging Options::   Producing debuggable code.
>  * Optimize Options::How much optimization?
>  * Instrumentation Options:: Enabling profiling and extra run-time error
> checking.
> @@ -284,13 +285,30 @@ Objective-C and Objective-C++ Dialects}.
>
>  @item Warning Options
>  @xref{Warning Options,,Options to Request or Suppress Warnings}.
> -@gccoptlist{-fsyntax-only  -fmax-errors=@var{n}  -Wpedantic @gol
> +@gccoptlist{--analyzer -fsyntax-only  -fmax-errors=@var{n}  -Wpedantic
> @gol
>  -pedantic-errors @gol
>  -w  -Wextra  -Wall  -Waddress  -Waddress-of-packed-member @gol
>  -Waggregate-return  -Waligned-new @gol
>  -Walloc-zero  -Walloc-size-larger-than=@var{byte-size} @gol
>  -Walloca  -Walloca-larger-than=@var{byte-size} @gol
> --Wno-aggressive-loop-optimizations  -Warray-bounds  -Warray-bounds=@var{n}
> @gol
> +-Wno-aggressive-loop-optimizations @gol
> +-Wno-analyzer-double-fclose @gol
> +-Wno-analyzer-double-free @gol
> +-Wno-analyzer-exposure-through-output-file @gol
> +-Wno-analyzer-file-leak @gol
> +-Wno-analyzer-free-of-non-heap @gol
> +-Wno-analyzer-malloc-leak @gol
> +-Wno-analyzer-possible-null-argument @gol
> +-Wno-analyzer-possible-null-dereference @gol
> +-Wno-analyzer-null-argument @gol
> +-Wno-analyzer-null-dereference @gol
> +-Wno-analyzer-stale-setjmp-buffer @gol
> +-Wno-analyzer-tainted-array-index @gol
> +-Wno-analyzer-use-after-free @gol
> +-Wno-analyzer-use-of-pointer-in-stale-stack-frame @gol
> +-Wno-analyzer-use-of-uninitialized-value @gol
> +-Wanalyzer-too-complex @gol
> +-Warray-bounds  -Warray-bounds=@var{n} @gol
>  -Wno-attributes  -Wattribute-alias=@var{n}  @gol
>  -Wbool-compare  -Wbool-operation @gol
>  -Wno-builtin-declaration-mismatch @gol
> @@ -370,6 +388,43 @@ Objective-C and Objective-C++ Dialects}.
>  -Wwrite-strings @gol
>  -Wzero-as-null-pointer-constant}
>
> +@item Static Analyzer Options
> +@gccoptlist{-Wanalyzer-double-fclose @gol
> +-Wanalyzer-double-free @gol
> +-Wanalyzer-exposure-through-output-file @gol
> +-Wanalyzer-file-leak @gol
> +-Wanalyzer-free-of-non-heap @gol
> +-Wanalyzer-malloc-leak @gol
> +-Wanalyzer-null-argument @gol
> +-Wanalyzer-null-dereference @gol
> +-Wanalyzer-possible-null-argument @gol
> +-Wanalyzer-possible-null-dereference @gol
> 

Re: libgo patch committed: Always mark assembly file as non-executable stack

[Ian Lance Taylor]

Thanks, rather than try to make this work everywhere, I decided to
only build the file for x86 GNU/Linux for now, since that is the only
place it is currently used.  This patch bootstrapped on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 279062)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-f04751699e1a1ce98fe8bdbcce5a00f1be6a7d15
+15c7bc9f0a432bc09716758412ea41d6caa6491b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 278984)
+++ libgo/Makefile.am   (working copy)
@@ -414,6 +414,13 @@ else
 rtems_task_variable_add_file =
 endif
 
+runtime_context_asm_file =
+if LIBGO_IS_X86
+if LIBGO_IS_LINUX
+runtime_context_asm_file += runtime/go-context.S
+endif
+endif
+
 runtime_files = \
runtime/aeshash.c \
runtime/go-assert.c \
@@ -445,7 +452,7 @@ runtime_files = \
runtime/runtime_c.c \
runtime/stack.c \
runtime/yield.c \
-   runtime/go-context.S \
+   $(runtime_context_asm_file) \
$(rtems_task_variable_add_file)
 
 version.go: s-version; @true

libgo patch committed: Update HURD support for embedded mOS

[Ian Lance Taylor]

In the update to 1.13 the mOS field of an m was embedded rather than
named.  This patch updates the HURD support for that change.  This
should fix GCC PR 92842.  I built the code on x86_64-pc-linux-gnu, but
that doesn't actually test this.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 279032)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e32651d37e0c43bb7595ac94363b079610bed746
+f04751699e1a1ce98fe8bdbcce5a00f1be6a7d15
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/os_hurd.go
===
--- libgo/go/runtime/os_hurd.go (revision 278984)
+++ libgo/go/runtime/os_hurd.go (working copy)
@@ -39,7 +39,7 @@ func sem_timedwait(sem *_sem_t, timeout
 
 //go:nosplit
 func semacreate(mp *m) {
-   if mp.mos.waitsema != 0 {
+   if mp.waitsema != 0 {
return
}
 
@@ -52,7 +52,7 @@ func semacreate(mp *m) {
if sem_init(sem, 0, 0) != 0 {
throw("sem_init")
}
-   mp.mos.waitsema = uintptr(unsafe.Pointer(sem))
+   mp.waitsema = uintptr(unsafe.Pointer(sem))
 }
 
 //go:nosplit
@@ -62,7 +62,7 @@ func semasleep(ns int64) int32 {
var ts timespec
ts.setNsec(ns)
 
-   if sem_timedwait((*_sem_t)(unsafe.Pointer(_m_.mos.waitsema)), 
) != 0 {
+   if sem_timedwait((*_sem_t)(unsafe.Pointer(_m_.waitsema)), ) 
!= 0 {
err := errno()
if err == _ETIMEDOUT || err == _EAGAIN || err == _EINTR 
{
return -1
@@ -72,7 +72,7 @@ func semasleep(ns int64) int32 {
return 0
}
for {
-   r1 := sem_wait((*_sem_t)(unsafe.Pointer(_m_.mos.waitsema)))
+   r1 := sem_wait((*_sem_t)(unsafe.Pointer(_m_.waitsema)))
if r1 == 0 {
break
}
@@ -86,7 +86,7 @@ func semasleep(ns int64) int32 {
 
 //go:nosplit
 func semawakeup(mp *m) {
-   if sem_post((*_sem_t)(unsafe.Pointer(mp.mos.waitsema))) != 0 {
+   if sem_post((*_sem_t)(unsafe.Pointer(mp.waitsema))) != 0 {
throw("sem_post")
}
 }

Patch to fix PR92176

[Vladimir Makarov]

The following patch fixes

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

The patch was tested on i686, x86-64, and ppc64.

Committed as r279061.


Index: ChangeLog
===
--- ChangeLog	(revision 279060)
+++ ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2019-12-06  Andreas Krebbel  
+	Vladimir Makarov  
+
+	PR rtl-optimization/92176
+	* lra.c (simplify_subreg_regno): Don't permit unconditional
+	changing mode for LRA too.
+
 2019-12-06  Richard Sandiford  
 
 	* target.h (TCTX_ALLOCATION, TCTX_DEALLOCATION, TCTX_EXCEPTIONS)
Index: rtlanal.c
===
--- rtlanal.c	(revision 279060)
+++ rtlanal.c	(working copy)
@@ -3951,9 +3951,7 @@ simplify_subreg_regno (unsigned int xreg
   /* Give the backend a chance to disallow the mode change.  */
   if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
   && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
-  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode)
-  /* We can use mode change in LRA for some transformations.  */
-  && ! lra_in_progress)
+  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode))
 return -1;
 
   /* We shouldn't simplify stack-related registers.  */
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 279060)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2019-12-06  Andreas Krebbel  
+	Vladimir Makarov  
+
+	PR rtl-optimization/92176
+	* gcc.target/s390/pr92176.c: New test.
+
 2019-12-06  Martin Sebor  
 
 	* gcc.dg/Wstringop-overflow-23.c: Use the correct argument type.
Index: testsuite/gcc.target/s390/pr92176.c
===
--- testsuite/gcc.target/s390/pr92176.c	(nonexistent)
+++ testsuite/gcc.target/s390/pr92176.c	(working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z13 -mzarch" } */
+
+int a = 5, b, c, d, g, h, k, l, m, o;
+static int e[7];
+int *volatile i = 
+long long j;
+
+short p(int f, int dummy) {
+  k = 0 != (*e = m);
+  j = 0;
+  for (; j < 59; j = j + 1)
+*i |= b;
+  g = 1;
+  for (; g <= 4; g++) {
+o = 0;
+for (; o <= 4; o++)
+  i = (int * volatile)(long)l;
+  }
+  return 42;
+}
+
+void
+q() {
+  char *n = (char*)
+
+  (*n = a) == p(e[6], c);
+  for (; h;)
+for (;;)
+  ;
+}
+
+/* { dg-final { scan-assembler-not {(?n)^\tvsteb\t.+,0$} } } */

Re: [C++ PATCH] CWG 1299, not extending temporary lifetime for ?: (PR c++/92831)

[Jason Merrill]

On 12/6/19 11:28 AM, Jakub Jelinek wrote:

Hi!

This is a reason latest firefox is miscompiled by G++ 9, seems DR 1299
says in [class.temporary]/(6.7) that reference binding to a temporary
object from the second or third operand of a conditional expression
should have extended lifetime too, but extend_ref_init_temps_1 was
apparently handling only comma expressions, some casts, . (COMPONENT_REF),
[] (ARRAY_REF), but not COND_EXPR.

The following patch handles COND_EXPR in there too, in a similar way how
the gimplifier handles the cleanups of the expressions in the COND_EXPR
operand if there is no lifetime extension due to reference binding.
In particular there are bool temporaries added, initialized to false and set
to true if the particular (leaf) COND_EXPR argument has been invoked and the
corresponding cleanup guarded that way.

I admit I haven't tried to construct testcases for all the things CWG 1299
added, e.g. don't know if ( expression ) will work, if all the *_cast cases
that need to be extended work (some of them do, as the testcase shows), or
if e.g. .* works, so I'm not claiming the DR is completely implemented.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
and after a while for release branches?


OK.


Note, just to double check g++ doesn't ICE on expr1 ? : expr2 GNU extension,
I also wrote the attached testcase, but unlike the testcase included in the
patch which behaves the same with patched g++ as does recent clang++, the
testcase with expr1 ? : expr2 (omitted second operand) actually never
extends the lifetime of any temporary (that is the baz function), unlike
clang++ which extends the lifetime of expr2 if expr1 is false, and doesn't
extend lifetime of anything if expr1 is true.  This is outside of the scope
of the standard, so no idea what is correct, so I'm just asking how it
should behave.


I would expect one or the other to be extended.  I imagine that clang 
not extending expr1 is a bug due to however they avoid evaluating it twice.



extend_ref_init_temps_1 is never called in that case when the expression is 
COND_EXPR.


I think the problem is in build_conditional_expr_1, which needs to treat 
xvalues properly in the handling of this extension, i.e.



-  if (lvalue_p (arg1))
+  if (glvalue_p (arg1))
arg2 = arg1 = cp_stabilize_reference (arg1);


Jason

[PATCH] i386: Use add for a = a + b and a = b + a when possible

[H.J. Lu]

Since except for Bonnell,

01 fbadd%edi,%ebx

is faster and shorter than

8d 1c 1f  lea(%rdi,%rbx,1),%ebx

we should use add for a = a + b and a = b + a when possible if not
optimizing for Bonnell.

Tested on x86-64.

gcc/

PR target/92807
* config/i386/i386.c (ix86_lea_outperforms): Check !TARGET_BONNELL.
(ix86_avoid_lea_for_addr): When not optimizing for Bonnell, use add
for a = a + b and a = b + a.

gcc/testsuite/

PR target/92807
* gcc.target/i386/pr92807-1.c: New test.

-- 
H.J.
From ad803a967a6c18ae3bd6f8381ebc8a78c31a82ae Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Tue, 3 Dec 2019 15:27:51 -0800
Subject: [PATCH] i386: Use add for a = a + b and a = b + a when possible

Since except for Bonnell,

01 fb	add%edi,%ebx

is faster and shorter than

8d 1c 1f 	lea(%rdi,%rbx,1),%ebx

we should use add for a = a + b and a = b + a when possible if not
optimizing for Bonnell.

Tested on x86-64.

gcc/

	PR target/92807
	* config/i386/i386.c (ix86_lea_outperforms): Check !TARGET_BONNELL.
	(ix86_avoid_lea_for_addr): When not optimizing for Bonnell, use add
	for a = a + b and a = b + a.

gcc/testsuite/

	PR target/92807
	* gcc.target/i386/pr92807-1.c: New test.
---
 gcc/config/i386/i386.c| 27 +++
 gcc/testsuite/gcc.target/i386/pr92807-1.c | 11 +
 2 files changed, 29 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr92807-1.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 04cbbd532c0d..65f0d44916a8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -14393,11 +14393,10 @@ ix86_lea_outperforms (rtx_insn *insn, unsigned int regno0, unsigned int regno1,
 {
   int dist_define, dist_use;
 
-  /* For Silvermont if using a 2-source or 3-source LEA for
- non-destructive destination purposes, or due to wanting
- ability to use SCALE, the use of LEA is justified.  */
-  if (TARGET_SILVERMONT || TARGET_GOLDMONT || TARGET_GOLDMONT_PLUS
-  || TARGET_TREMONT || TARGET_INTEL)
+  /* For Atom processors newer than Bonnell, if using a 2-source or
+ 3-source LEA for non-destructive destination purposes, or due to
+ wanting ability to use SCALE, the use of LEA is justified.  */
+  if (!TARGET_BONNELL)
 {
   if (has_scale)
 	return true;
@@ -14532,10 +14531,6 @@ ix86_avoid_lea_for_addr (rtx_insn *insn, rtx operands[])
   struct ix86_address parts;
   int ok;
 
-  /* Check we need to optimize.  */
-  if (!TARGET_AVOID_LEA_FOR_ADDR || optimize_function_for_size_p (cfun))
-return false;
-
   /* The "at least two components" test below might not catch simple
  move or zero extension insns if parts.base is non-NULL and parts.disp
  is const0_rtx as the only components in the address, e.g. if the
@@ -14572,6 +14567,20 @@ ix86_avoid_lea_for_addr (rtx_insn *insn, rtx operands[])
   if (parts.index)
 regno2 = true_regnum (parts.index);
 
+  /* Use add for a = a + b and a = b + a since it is faster and shorter
+ than lea for most processors.  For the processors like BONNELL, if
+ the destination register of LEA holds an actual address which will
+ be used soon, LEA is better and otherwise ADD is better.  */
+  if (!TARGET_BONNELL
+  && parts.scale == 1
+  && (!parts.disp || parts.disp == const0_rtx)
+  && (regno0 == regno1 || regno0 == regno2))
+return true;
+
+  /* Check we need to optimize.  */
+  if (!TARGET_AVOID_LEA_FOR_ADDR || optimize_function_for_size_p (cfun))
+return false;
+
   split_cost = 0;
 
   /* Compute how many cycles we will add to execution time
diff --git a/gcc/testsuite/gcc.target/i386/pr92807-1.c b/gcc/testsuite/gcc.target/i386/pr92807-1.c
new file mode 100644
index ..00f92930af92
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr92807-1.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+unsigned int
+abs2 (unsigned int a) 
+{
+  unsigned int s = ((a>>15)&0x10001)*0x;
+  return (a+s)^s;
+}
+
+/* { dg-final { scan-assembler-not "leal" } } */
-- 
2.21.0

Re: [PATCH] add -Wmismatched-tags (PR 61339)

[Jason Merrill]

On 12/5/19 6:47 PM, Jakub Jelinek wrote:

On Thu, Dec 05, 2019 at 04:33:10PM -0700, Martin Sebor wrote:

It's hard to distinguish between this type and the previous one by name;
this one should probably have "map" in its name.


+static GTY (()) record_to_locs_t *rec2loc;

...

+    rec2loc = new record_to_locs_t ();


If this isn't GC-allocated, marking it with GTY(()) seems wrong.  How do
you imagine this warning interacting with PCH?


I have to confess I know too little about PCH to have an idea how
it might interact.  Is there something you suggest I try testing?


For your patch, obviously some struct/class forward declarations or
definitions in a header that you compile into PCH and then the main testcase
that contains the mismatched pairs.

If there is something that you need to record during parsing of the
precompiled header and use later on, everything needs to be GGC allocated.
So, the hash_map needs to be created with something like
hash_map::create_ggc (nnn)
and it really can't use pointer hashing, but has to use some different one
(say on DECL_UID, TYPE_UID etc.), because the addresses are remapped during
PCH save/restore cycle, but hash tables aren't rehashed.
See e.g. PR92458.


Alternately you can decide that this information will not be saved to 
PCH, and rely on CLASSTYPE_DECLARED_CLASS for classes loaded from a PCH.


Jason

Re: [PATCH v2 2/2][ARM] Improve max_cond_insns setting for Cortex cores

[Wilco Dijkstra]

Hi Christophe,

> In practice, how do you activate it when running the GCC testsuite? Do
> you plan to send a GCC patch to enable this assembler flag, or do you
> locally enable that option by default in your binutils?

The warning is off by default so there is no need to do anything in the 
testsuite,
you just need a fixed binutils.

> FWIW, I've also noticed that the whole libstdc++ testsuite is somehow
> "deactivated" (I have 0 pass, 0 fail etc...)  after your GCC patch
> when configuring GCC
> --target arm-none-linux-gnueabihf
> --with-mode thumb
> --with-cpu cortex-a57
> --with-fpu crypto-neon-fp-armv8

Well it's possible a configure check failed somehow.

Cheers,
Wilco

Re: [PATCH] track dynamic allocation in strlen (PR 91582)

[Martin Sebor]

On 11/30/19 9:31 AM, Christophe Lyon wrote:

On Tue, 12 Nov 2019 at 02:28, Martin Sebor  wrote:


The attached patch extends the strlen pass to detect out-of-bounds
accesses to memory allocated by calls to other allocation functions
besides calloc and malloc, as well as VLAs, and user-defined
functions declared with attribute alloc_size.  There is some
overlap with the _FORTIFY_SOURCE detection but thanks to
the extensive use of ranges, this enhancement detects many more
cases of overflow.

The solution primarily improves warnings but some of the changes
also improve codegen in some cases as a side-effect.  I hope to
take better advantage of the optimization opportunities the dynamic
memory tracking opens up (and also better buffer overflow and array
out-of-bounds detection) in GCC 11.

Although the strlen pass already tracks some dynamic memory calls
(calloc and malloc) rather than extending the same infrastructure
(strinfo::stmt) to others I took the approach of adding a separate
data member for the other calls (strinfo::alloc) and tracking those
independently.  I did this to keep the changes only minimally
intrusive.  In the future (post GCC 10) it might be worth
considering merging both.

Besides introducing the new member and making use of it, the rest
of the changes were prompted by weaknesses exposed by test cases
involving dynamically allocated objects.

The patch is intended to apply on top of the two related patches
posted last week ([1] and [2]).  For all tests to pass also expects
the fix for PR 92412 posted earlier today ([3]).

Martin


Hi Martin,

The new tests gcc.dg/Wstringop-overflow-23.c and gcc.dg/Wstringop-overflow-24.c
fail on arm-eabi (they pass on arm*-linux-gnueabi*):

FAIL: gcc.dg/Wstringop-overflow-23.c (test for excess errors)
Excess errors:
/gcc/testsuite/gcc.dg/Wstringop-overflow-23.c:174:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-23.c:175:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]

FAIL: gcc.dg/Wstringop-overflow-24.c (test for excess errors)
Excess errors:
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:33:12: warning: passing
argument 1 of 'rd1_int' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:35:12: warning: passing
argument 1 of 'rd1_int' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:202:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:203:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]

I'm seeing that at r278638


Those are due to simple oversights in the tests (using int* rather
than int32_t*).  I've fixed that in r279059.

Thanks
Martin



Christophe



[1] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00429.html
[2] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
[3] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00800.html

Re: [committed, amdgcn] Enable QI/HImode vector moves

[Richard Sandiford]

Andrew Stubbs  writes:
> Hi all,
>
> This patch re-enables the V64QImode and V64HImode for GCN.
>
> GCC does not make these easy to work with because there is (was?) an 
> assumption that vector registers do not have excess bits in vector 
> registers, and therefore does not need to worry about truncating or 
> extending smaller types, when  vectorized. This is not true on GCN where 
> each vector lane is always at least 32-bits wide, so we only really 
> implement loading at storing these vectors modes (for now).

FWIW, partial SVE modes work the same way, and this is supposed to be
supported now.  E.g. SVE's VNx4QI is a vector of QIs stored in SI
containers; in other words, it's a VNx4SI in which only the low 8 bits
of each SI are used.

sext_optab, zext_optab and trunc_optab now support vector modes,
so e.g. extendv64qiv64si2 provides sign extension from V64QI to V64SI.
At the moment, in-register truncations like truncv64siv16qi2 have to
be provided as patterns, even though they're no-ops for the target
machine, since they're not no-ops in rtl terms.

And the main snag is rtl, because this isn't the way GCC expects vector
registers to be laid out.  It looks like you already handle that in
TARGET_CAN_CHANGE_MODE_CLASS and TARGET_SECONDARY_RELOAD though.

For SVE, partial vector loads are actually extending loads and partial
vector stores are truncating stores.  Maybe it's the same for amdgcn.
If so, there's a benefit to providing both native movv64qis
and V64QI->V64SI extending loads, i.e. a combine pattern the fuses
movv64qi with a sign_extend or zero_extend.

(Probably none of that is news, sorry, just saying in case.)

Thanks,
Richard

> These modes were originally disabled because, previously, the GCC 
> vectorizer would "lock" into the first vector register size that it 
> encountered in a region, and would refuse to vectorize any type that 
> didn't match that size in the rest of that region. On GCN, where all 
> types have the same number of lanes, and therefore different bit-sizes, 
> this meant that allowing QImode or HImode could prevent it vectorizing 
> SImode or DImode, which are the ones we really want vectorized.
>
> Now that Richard Sandiford has introduced TARGET_VECTORIZE_RELATED_MODE 
> this issue has now been removed, and we can re-enable the vector types 
> once more. Thanks Richard! :-)
>
> This change results in 207 new passes in the vect.exp (there's also 41 
> new fails, but those are exposed bugs I'll fix shortly). Some of these 
> were internal compiler errors that did not exist in older compilers.

Re: [PATCH 21/49] analyzer: command-line options

[Eric Gallager]

On 12/4/19, Martin Sebor  wrote:
> On 11/15/19 6:23 PM, David Malcolm wrote:
>> This patch contains the command-line options for the analyzer.
>>
>
> Some of the -Wanalyzer- options sounds like they control similar
> warnings as existing options (e.g., -Wanalyzer-null-argument sounds
> like -Wnonnull and -Wanalyzer-null-dereference like -Wnull-dereference).
> There are also options whose names suggest they are in the same class
> as -Wmaybe-xxx (e.g., -Wanalyzer-possible-null-argument sounds like
> it would correspond to -Wmaybe-null-argument if it existed).

This is something I wondered about too, but I think when you compare
it to how clang does it (their analyzer options don't even have normal
-W names; you have to toggle them in a different way), the approach
David is suggesting for GCC here is better.

>
> I have a more general question about the apparent overlap of
> functionality that I will save for later but here I wonder about
> the names: that introducing a new set of similar sounding options
> might make them confusing, and might make the analyzer seem more
> like an add-on rather than an integral part of GCC.

Clang has this problem, too.

> I realize the existing option names don't use any particular convention so
> this is an opportunity to put one in place, but at a cost of
> divergence.  Unless you expect the existing options to go away,
> having consistent names would make for a more cohesive feel.
>
> My other concern is the verbosity of some these options:
> -Wanalyzer-use-of-pointer-in-stale-stack-frame is a mouthful and
> will take up a lot of terminal space.  It sounds like the option
> controls warnings about uses of dangling pointers to auto objects,
> similar to -Wreturn-local-addr.  My impression that conventionally
> GCC options have tended to be brief, and I personally would prefer
> shorter option names.

While I get this preference, to compare to clang again, some of their
warning names are even longer than that...
-Wanalyzer-use-of-pointer-in-stale-stack-frame really isn't that much
worse than, say, -Wincompatible-pointer-types-discards-qualifiers or
-Wtautological-constant-out-of-range-compare, for example.

>
> Martin
>
>> gcc/ChangeLog:
>>  * analyzer/plugin.opt: New file.
>>  * common.opt (--analyzer): New driver option.
>> ---
>>   gcc/analyzer/plugin.opt | 161
>> 
>>   gcc/common.opt  |   3 +
>>   2 files changed, 164 insertions(+)
>>   create mode 100644 gcc/analyzer/plugin.opt
>>
>> diff --git a/gcc/analyzer/plugin.opt b/gcc/analyzer/plugin.opt
>> new file mode 100644
>> index 000..55f54bb
>> --- /dev/null
>> +++ b/gcc/analyzer/plugin.opt
>> @@ -0,0 +1,161 @@
>> +; plugin.opt -- Options for the analyzer.
>> +
>> +; Copyright (C) 2019 Free Software Foundation, Inc.
>> +;
>> +; This file is part of GCC.
>> +;
>> +; GCC is free software; you can redistribute it and/or modify it under
>> +; the terms of the GNU General Public License as published by the Free
>> +; Software Foundation; either version 3, or (at your option) any later
>> +; version.
>> +;
>> +; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
>> +; WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> +; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>> +; for more details.
>> +;
>> +; You should have received a copy of the GNU General Public License
>> +; along with GCC; see the file COPYING3.  If not see
>> +; .
>> +
>> +; See the GCC internals manual for a description of this file's format.
>> +
>> +; Please try to keep this file in ASCII collating order.
>> +
>> +Wanalyzer-double-fclose
>> +Common Var(warn_analyzer_double_fclose) Init(1) Warning
>> +Warn about code paths in which a stdio FILE can be closed more than
>> once.
>> +
>> +Wanalyzer-double-free
>> +Common Var(warn_analyzer_double_free) Init(1) Warning
>> +Warn about code paths in which a pointer can be freed more than once.
>> +
>> +Wanalyzer-exposure-through-output-file
>> +Common Var(warn_analyzer_exposure_through_output_file) Init(1) Warning
>> +Warn about code paths in which sensitive data is written to a file.
>> +
>> +Wanalyzer-file-leak
>> +Common Var(warn_analyzer_file_leak) Init(1) Warning
>> +Warn about code paths in which a stdio FILE is not closed.
>> +
>> +Wanalyzer-free-of-non-heap
>> +Common Var(warn_analyzer_free_of_non_heap) Init(1) Warning
>> +Warn about code paths in which a non-heap pointer is freed.
>> +
>> +Wanalyzer-malloc-leak
>> +Common Var(warn_analyzer_malloc_leak) Init(1) Warning
>> +Warn about code paths in which a heap-allocated pointer leaks.
>> +
>> +Wanalyzer-possible-null-argument
>> +Common Var(warn_analyzer_possible_null_argument) Init(1) Warning
>> +Warn about code paths in which a possibly-NULL value is passed to a
>> must-not-be-NULL function argument.
>> +
>> +Wanalyzer-possible-null-dereference
>> +Common 

[committed, amdgcn] Fix unrecognised instruction

[Andrew Stubbs]

Hi all,

I've committed the attached to fix a failure-to-assemble bug that can 
occur in some vectorized code.  This has been hidden for a long time 
because sub-word vectors were disabled on GCN, but this is no longer the 
case.


The gather load instructions had the suffixes for store, which didn't 
assemble well.  E.g. it had 'flat_load_short', instead of 
'flat_load_ustore'.


This fixes about 39 tests in vect.exp.

--
Andrew Stubbs
Mentor Graphics / CodeSourcery
Fix unrecognised GCN instruction.

2019-12-06  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (gather_insn_1offset): Use %o
	in the asm output.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index 90f0dcf3106..95e0731a374 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -716,10 +716,10 @@
 if (AS_FLAT_P (as))
   {
 	if (TARGET_GCN5_PLUS)
-	  sprintf (buf, "flat_load%%s0\t%%0, %%1 offset:%%2%s\;s_waitcnt\t0",
+	  sprintf (buf, "flat_load%%o0\t%%0, %%1 offset:%%2%s\;s_waitcnt\t0",
 		   glc);
 	else
-	  sprintf (buf, "flat_load%%s0\t%%0, %%1%s\;s_waitcnt\t0", glc);
+	  sprintf (buf, "flat_load%%o0\t%%0, %%1%s\;s_waitcnt\t0", glc);
   }
 else if (AS_GLOBAL_P (as))
   sprintf (buf, "global_load%%s0\t%%0, %%1, off offset:%%2%s\;"

Re: [C++ Patch] Improve build_*_cast locations

[Jason Merrill]

On 12/6/19 11:14 AM, Paolo Carlini wrote:

Hi,

as promised, the below takes care of the various remaining casts. It's 
mostly mechanical, follows the same approach used for 
build_functional_cast. Tested x86_64-linux.


It occurs to me that once we're passing the location into the build_* 
functions, we can apply it to the expression there rather than in the 
parser.


Jason

Re: Ping: [PATCH][C++] Pass type uses through the verify_type_context hook

[Jason Merrill]

On 12/6/19 9:26 AM, Richard Sandiford wrote:

Jason Merrill  writes:

On 12/5/19 1:21 PM, Richard Sandiford wrote:

+  else if (!verify_type_context (input_location, TCTX_EXCEPTIONS, type))
+return false;
+
+  else if (TYPE_REF_P (type)
+  && !verify_type_context (input_location, TCTX_EXCEPTIONS,
+   TREE_TYPE (type)))


You could use the non_reference function to combine these.


Thanks.  This patch fixes that and follows Marek's suggestion of using
location_of in check_array_initializer.  (I wondered whether to check
for decl == error_mark_node as well, but that can't currently happen.)

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


OK.


Richard


2019-12-06  Richard Sandiford  

gcc/
* target.h (TCTX_ALLOCATION, TCTX_DEALLOCATION, TCTX_EXCEPTIONS)
(TCTX_CAPTURE_BY_COPY): New type_context_kinds.
* config/aarch64/aarch64-sve-builtins.cc (verify_type_context):
Handle them.

gcc/cp/
* decl.c (start_decl_1): Use verify_type_context to check whether
the target allows variables of a particular type to have static
or thread-local storage duration.
(check_array_initializer): Use verify_type_context to check whether
the target allows a particular type to be used as an array element.
(create_array_type_for_decl): Likewise.
(cp_finish_decl): Use verify_type_context to check whether
the target allows static member variables of a particular type.
(grokdeclarator): Likewise.  Also use verify_type_context to check
whether the target allows non-static member variables of a particular
type.
* except.c: Include target.h.
(is_admissible_throw_operand_or_catch_parameter): Use
verify_type_context to check whether the target allows particular
types to be thrown and caught.
* typeck2.c (add_exception_specifier): Likewise.
* init.c (build_new_1): Use verify_type_context to check whether
the target allows particular types to be dynamically allocated.
(build_vec_delete_1, build_delete): Use verify_type_context to check
whether the target allows particular types to be deleted.
* lambda.c (add_capture): Use verify_type_context to check
whether the target allows particular types to be captured by copy.
* pt.c: Include target.h.
(instantiate_class_template_1): Use verify_type_context to check
whether the target allows non-static member variables of a particular
type.
* typeck.c (cxx_alignof_expr): Use verify_type_context to check
whether the target allows the alignment of a particular type
to be measured.
(pointer_diff, cp_build_unary_op): Use verify_type_context to check
whether the target allows arithmetic involving pointers to particular
types.

gcc/testsuite/
* g++.dg/ext/sve-sizeless-1.C: New test.
* g++.dg/ext/sve-sizeless-2.C: Likewise.

Index: gcc/target.h
===
--- gcc/target.h2019-12-04 13:13:48.0 +
+++ gcc/target.h2019-12-06 14:11:28.233552680 +
@@ -249,7 +249,19 @@ enum type_context_kind {
  
/* Adding to or subtracting from a pointer to T, or computing the

   difference between two pointers when one of them is a pointer to T.  */
-  TCTX_POINTER_ARITH
+  TCTX_POINTER_ARITH,
+
+  /* Dynamically allocating objects of type T.  */
+  TCTX_ALLOCATION,
+
+  /* Dynamically deallocating objects of type T.  */
+  TCTX_DEALLOCATION,
+
+  /* Throwing or catching an object of type T.  */
+  TCTX_EXCEPTIONS,
+
+  /* Capturing objects of type T by value in a closure.  */
+  TCTX_CAPTURE_BY_COPY
  };
  
  extern bool verify_type_context (location_t, type_context_kind, const_tree,

Index: gcc/config/aarch64/aarch64-sve-builtins.cc
===
--- gcc/config/aarch64/aarch64-sve-builtins.cc  2019-12-04 13:13:48.0 
+
+++ gcc/config/aarch64/aarch64-sve-builtins.cc  2019-12-06 14:11:28.217552787 
+
@@ -3352,6 +3352,26 @@ verify_type_context (location_t loc, typ
if (!silent_p)
error_at (loc, "array elements cannot have SVE type %qT", type);
return false;
+
+case TCTX_ALLOCATION:
+  if (!silent_p)
+   error_at (loc, "cannot allocate objects with SVE type %qT", type);
+  return false;
+
+case TCTX_DEALLOCATION:
+  if (!silent_p)
+   error_at (loc, "cannot delete objects with SVE type %qT", type);
+  return false;
+
+case TCTX_EXCEPTIONS:
+  if (!silent_p)
+   error_at (loc, "cannot throw or catch SVE type %qT", type);
+  return false;
+
+case TCTX_CAPTURE_BY_COPY:
+  if (!silent_p)
+   error_at (loc, "capture by copy of SVE type %qT", type);
+  return false;
  }
gcc_unreachable ();
  }
Index: gcc/cp/decl.c

Re: [PATCH 09/49] gimple const-correctness fixes

[David Malcolm]

On Fri, 2019-12-06 at 11:52 +0100, Richard Biener wrote:
> On Sat, Nov 16, 2019 at 2:20 AM David Malcolm 
> wrote:
> > This patch converts various "gimple *" to "const gimple *" and
> > similar
> > fixes for gimple subclasses, adding is_a_helper for gimple
> > subclasses
> > to support the const form of as_a, and adding a few "const"
> > overloads
> > of accessors.
> > 
> > This is enough to make pp_gimple_stmt_1's stmt const.
> 
> Hum.  Can't the const is-a variants be somehow magically implemented
> generally?  If something is a T then it is also a const T, no?  I
> guess
> if something is a const T it isn't a T though?
> 
> Richard.

It is something of a wart to need new is_a_helper<>::test functions for
the const variants.

I tried poking at is-a.h to do this in a more generic way, but I'm not
sure it's doable without an invasive change:  is_a_helper's T is
already a pointer, so AIUI, if we apply "const" to it, we're making the
pointer const, rather than the thing being pointed to.

Maybe someone else can see a way?

In the meantime, is this patch OK?  (I use "const gimple *" etc
throughout the analyzer, to emphasize that I'm not changing them)

Thanks
Dave


> > gcc/ChangeLog:
> > * gimple-predict.h (gimple_predict_predictor): Make "gs"
> > param
> > const.
> > (gimple_predict_outcome): Likewise.
> > * gimple-pretty-print.c (do_niy): Likewise.
> > (dump_unary_rhs): Likewise.
> > (dump_binary_rhs): Likewise.
> > (dump_ternary_rhs): Likewise.
> > (dump_gimple_assign): Likewise.
> > (dump_gimple_return): Likewise.
> > (dump_gimple_call_args): Likewise.
> > (pp_points_to_solution): Make "pt" param const.
> > (dump_gimple_call): Make "gs" param const.
> > (dump_gimple_switch): Likewise.
> > (dump_gimple_cond): Likewise.
> > (dump_gimple_label): Likewise.
> > (dump_gimple_goto): Likewise.
> > (dump_gimple_bind): Likewise.
> > (dump_gimple_try): Likewise.
> > (dump_gimple_catch): Likewise.
> > (dump_gimple_eh_filter): Likewise.
> > (dump_gimple_eh_must_not_throw): Likewise.
> > (dump_gimple_eh_else): Likewise.
> > (dump_gimple_resx): Likewise.
> > (dump_gimple_eh_dispatch): Likewise.
> > (dump_gimple_debug): Likewise.
> > (dump_gimple_omp_for): Likewise.
> > (dump_gimple_omp_continue): Likewise.
> > (dump_gimple_omp_single): Likewise.
> > (dump_gimple_omp_taskgroup): Likewise.
> > (dump_gimple_omp_target): Likewise.
> > (dump_gimple_omp_teams): Likewise.
> > (dump_gimple_omp_sections): Likewise.
> > (dump_gimple_omp_block): Likewise.
> > (dump_gimple_omp_critical): Likewise.
> > (dump_gimple_omp_ordered): Likewise.
> > (dump_gimple_omp_scan): Likewise.
> > (dump_gimple_omp_return): Likewise.
> > (dump_gimple_transaction): Likewise.
> > (dump_gimple_asm): Likewise.
> > (dump_gimple_phi): Make "phi" param const.
> > (dump_gimple_omp_parallel): Make "gs" param const.
> > (dump_gimple_omp_task): Likewise.
> > (dump_gimple_omp_atomic_load): Likewise.
> > (dump_gimple_omp_atomic_store): Likewise.
> > (dump_gimple_mem_ops): Likewise.
> > (pp_gimple_stmt_1): Likewise.  Add "const" to the various
> > as_a <>
> > casts throughout.
> > * gimple-pretty-print.h (gimple_stmt_1): Make gimple *
> > param const.
> > * gimple.h (is_a_helper ::test): New.
> > (is_a_helper ::test): New.
> > (is_a_helper ::test): New.
> > (is_a_helper ::test): New.
> > (is_a_helper ::test): New.
> > (is_a_helper ::test): New.
> > (is_a_helper ::test): New.
> > (is_a_helper ::test): New.
> > (gimple_call_tail_p): Make param const.
> > (gimple_call_return_slot_opt_p): Likewise.
> > (gimple_call_va_arg_pack_p): Likewise.
> > (gimple_call_use_set): Add const overload.
> > (gimple_call_clobber_set): Likewise.
> > (gimple_has_lhs): Make param const.
> > (gimple_bind_body): Likewise.
> > (gimple_catch_handler): Likewise.
> > (gimple_eh_filter_failure): Likewise.
> > (gimple_eh_must_not_throw_fndecl): Likewise.
> > (gimple_eh_else_n_body): Likewise.
> > (gimple_eh_else_e_body): Likewise.
> > (gimple_try_eval): Likewise.
> > (gimple_try_cleanup): Likewise.
> > (gimple_phi_arg): Add const overload.
> > (gimple_phi_arg_def): Make param const.
> > (gimple_phi_arg_edge): Likewise.
> > (gimple_phi_arg_location): Likewise.
> > (gimple_phi_arg_has_location): Likewise.
> > (gimple_debug_bind_get_var): Likewise.
> > (gimple_debug_bind_get_value): Likewise.
> > (gimple_debug_source_bind_get_var): Likewise.
> > 

[committed, amdgcn] Enable QI/HImode vector moves

[Andrew Stubbs]

Hi all,

This patch re-enables the V64QImode and V64HImode for GCN.

GCC does not make these easy to work with because there is (was?) an 
assumption that vector registers do not have excess bits in vector 
registers, and therefore does not need to worry about truncating or 
extending smaller types, when  vectorized. This is not true on GCN where 
each vector lane is always at least 32-bits wide, so we only really 
implement loading at storing these vectors modes (for now).


These modes were originally disabled because, previously, the GCC 
vectorizer would "lock" into the first vector register size that it 
encountered in a region, and would refuse to vectorize any type that 
didn't match that size in the rest of that region. On GCN, where all 
types have the same number of lanes, and therefore different bit-sizes, 
this meant that allowing QImode or HImode could prevent it vectorizing 
SImode or DImode, which are the ones we really want vectorized.


Now that Richard Sandiford has introduced TARGET_VECTORIZE_RELATED_MODE 
this issue has now been removed, and we can re-enable the vector types 
once more. Thanks Richard! :-)


This change results in 207 new passes in the vect.exp (there's also 41 
new fails, but those are exposed bugs I'll fix shortly). Some of these 
were internal compiler errors that did not exist in older compilers.


--
Andrew Stubbs
Mentor Graphics / CodeSourcery
Enable QI/HImode vector moves

2019-12-06  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (VEC_1REG_MODE): Remove V64QI and V64HI.
	(VEC_1REG_ALT): Likewise.
	(VEC_ALL1REG_MODE): New mode iterator.
	(VEC_1REG_INT_MODE): Remove V64QI and V64HI.
	(VEC_1REG_INT_ALT): Likewise.
	(VEC_ALL1REG_INT_MODE): New mode interator.
	(VEC_ALL1REG_INT_ALT): Likewise.
	(VEC_REG_MODE): Remove V64QI and V64HI.
	(VEC_ALLREG_MODE): New mode interator.
	(vec_merge): Change to VEC_ALLREG_MODE.
	(vec_merge_with_clobber): Likewise.
	(vec_merge_with_vcc): Likewise.
	(mov): Likewise.
	(mov_unspec): Likewise.
	(*mov): Change to VEC_ALL1REG_MODE.
	(mov_exec): Likewise.
	(*mov_exec_match): Likewise.
	(mov_sgprbase): Likewise.
	(reload_in): Change to VEC_ALLREG_MODE.
	(reload_out): Likewise.
	(scalar address splits): Likewise.
	(*vec_set): Change to VEC_ALL1REG_MODE.
	(vec_set): Change to VEC_ALLREG_MODE.
	(*vec_set_1): Change to VEC_ALL1REG_MODE.
	(vec_duplicate): Likewise.
	(vec_extract): Likewise.
	(vec_init): Change to VEC_ALLREG_MODE.
	(gather_load): Likewise.
	(gather_exec): Likewise.
	(gather_expr): Likewise.
	(gather_insn_1offset): Likewise.
	(gather_insn_1offset_ds): Likewise.
	(gather_insn_2offsets): Likewise.
	(ds_bpermute): Change to VEC_ALL1REG_MODE.
	(VEC_INT_MODE): Remove V64QI and V64HI.
	(vcond_mask_di): Change to VEC_ALLREG_MODE.
	(vcond): Change to
	VEC_ALL1REG_MODE.
	(vcond_exec): Likewise.
	(vcondu): Likewise.
	(vcondu_exec): Likewise.
	(maskloaddi): Change to VEC_ALL1REG_MODE.
	(maskstoredi): Likewise.
	(mask_gather_load): Likewise.
	(mov_from_lane63_): Likewise.
	* config/gcn/gcn.c (gcn_vector_mode_supported_p): Renable V64QImode
	and V64HImode vectorization.
	(gcn_related_vector_mode): New function.
	(TARGET_VECTORIZE_RELATED_MODE): New define.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index f3262e22a02..90f0dcf3106 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -18,13 +18,19 @@
 
 ; Vector modes for one vector register
 (define_mode_iterator VEC_1REG_MODE
-		  [V64QI V64HI V64SI V64HF V64SF])
+		  [V64SI V64HF V64SF])
 (define_mode_iterator VEC_1REG_ALT
+		  [V64SI V64HF V64SF])
+(define_mode_iterator VEC_ALL1REG_MODE
 		  [V64QI V64HI V64SI V64HF V64SF])
 
 (define_mode_iterator VEC_1REG_INT_MODE
-		  [V64QI V64HI V64SI])
+		  [V64SI])
 (define_mode_iterator VEC_1REG_INT_ALT
+		  [V64SI])
+(define_mode_iterator VEC_ALL1REG_INT_MODE
+		  [V64QI V64HI V64SI])
+(define_mode_iterator VEC_ALL1REG_INT_ALT
 		  [V64QI V64HI V64SI])
 
 ; Vector modes for two vector registers
@@ -33,6 +39,9 @@
 
 ; All of above
 (define_mode_iterator VEC_REG_MODE
+		  [V64SI V64HF V64SF	; Single reg
+		   V64DI V64DF])		; Double reg
+(define_mode_iterator VEC_ALLREG_MODE
 		  [V64QI V64HI V64SI V64HF V64SF; Single reg
 		   V64DI V64DF])		; Double reg
 
@@ -57,38 +66,40 @@
 		   "" "_exec")
 
 (define_subst "vec_merge"
-  [(set (match_operand:VEC_REG_MODE 0)
-	(match_operand:VEC_REG_MODE 1))]
+  [(set (match_operand:VEC_ALLREG_MODE 0)
+	(match_operand:VEC_ALLREG_MODE 1))]
   ""
   [(set (match_dup 0)
-	(vec_merge:VEC_REG_MODE
+	(vec_merge:VEC_ALLREG_MODE
 	  (match_dup 1)
-	  (match_operand:VEC_REG_MODE 3 "gcn_register_or_unspec_operand" "U0")
+	  (match_operand:VEC_ALLREG_MODE 3
+	 "gcn_register_or_unspec_operand" "U0")
 	  (match_operand:DI 4 "gcn_exec_reg_operand" "e")))])
 
 (define_subst "vec_merge_with_clobber"
-  [(set (match_operand:VEC_REG_MODE 0)
-	(match_operand:VEC_REG_MODE 1))
+  [(set 

[PATCH] Allow entry point markers without debug support in accelerator compiler

[Kwok Cheung Yeung]

Hello

A number of the libgomp tests running with AMD GCN offloading fail with 
the following internal compiler error:


during RTL pass: final
/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/libgomp/testsuite/libgomp.fortran/examples-4/async_target-1.f90: 
In function 'pipedf_._omp_fn.2':
/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/libgomp/testsuite/libgomp.fortran/examples-4/async_target-1.f90:49: 
internal compiler error: in dwarf2out_inline_entry, at dwarf2out.c:27682

0x626210 dwarf2out_inline_entry

/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/gcc/dwarf2out.c:27682
0x9692c4 final_scan_insn_1

/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/gcc/final.c:2435
0x969f4b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)

/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/gcc/final.c:3152
0x96a214 final_1

/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/gcc/final.c:2020
0x96ac7f rest_of_handle_final

/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/gcc/final.c:4658
0x96ac7f execute

/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/gcc/final.c:4736

The ICE is due to an assert for debug_inline_points firing. The test 
case does not explicitly set this (using -ginline-points), so it is 
auto-detected.


The problem arises because the host compiler enables it by default, but 
the offload compiler disables it. The host compiler generates the Gimple 
debug statements for inlined functions, then streams them out using the 
LTO mechanism. The accelerator compiler streams them in, encounters the 
unexpected debug statements and ICEs due to a failed assertion.


It is possible to make GCN enable support inline-points by default, but 
I think it would be better to fix it for the general case where there is 
a disagreement between host and accelerator? This patch makes 
dwarf2out_inline_entry ignore the inline entry note if 
debug_inline_points is not set while the compiler is in LTO mode. This 
is effectively relaxing the assertion condition by allowing an exception 
for LTO.


Bootstrapped on x86_64, and tested using GCN as an offload accelerator. 
Okay for trunk?


Kwok


It is possible for the host compiler to emit entry point markers in the
GIMPLE code while the accelerator compiler has them disabled, causing an
assertion to fire where processed by the accelerator compiler.  This is
fixed by allowing the markers to be ignored in LTO mode only.

2019-12-06  Kwok Cheung Yeung  

gcc/
* dwarf2out.c (dwarf2out_inline_entry): Return early if in LTO and
debug_inline_points not set.
---
 gcc/dwarf2out.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 6fb345b..44fa071 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -27679,6 +27679,13 @@ block_within_block_p (tree block, tree outer, 
bool bothways)

 static void
 dwarf2out_inline_entry (tree block)
 {
+  /* In an offloading configuration, it is possible for the host 
toolchain but
+ not the offload toolchain to support extended debug information 
for inlined

+ functions.  In that case, we can just ignore any entry point markers
+ read from the LTO stream.  */
+  if (in_lto_p && !debug_inline_points)
+return;
+
   gcc_assert (debug_inline_points);

   /* If we can't represent it, don't bother.  */
--
2.8.1

Re: libgo patch committed: Always mark assembly file as non-executable stack

[Rainer Orth]

Hi Matthias,

> On 06.12.19 12:28, Rainer Orth wrote:
>> I Ian,
>> 
>>> This libgo patch arranges for go-context.S to always be marked as
>>> using a non-executable stack.  This is not required for all targets,
>>> but should do little harm.  Bootstrapped on x86_64-pc-linux-gnu.
>>> Committed to mainline.
>> 
>> unfortunately, it does, breaking bootstrap on Solaris/SPARC and x86 with
>> the native assembler:
>> 
>> * Solaris/SPARC with as:
>> 
>> /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: invalid character
>> (0x40)
>> /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: quoted-string
>> operand required
>> /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: statement syntax
>> make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1
>> 
>> * Solaris/x86 with as:
>> 
>> Assembler:
>> "/vol/gcc/src/hg/trunk/local/libgo/runtime/go-context.S", line 74
>> : Syntax error
>> Near line: " .section .note.GNU-stack,"",@progbits"
>> make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1
>
> also on arm-linux-gnueabi*. Patch in PR go/92820

that won't help: for one, those .note.GNU-stack sections are useless on
Solaris.  Even if this weren't the case, the syntax is still wrong:
Solaris/SPARC as needs

.section".note.GNU-stack",,#progbits

while Solaris/x86 as doesn't allow for '-' in section names (and there's
no quoting mechanism IIRC).

Rainer

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

Patch ping (was Re: [C++ PATCH] (temporarily) undefine __cpp_consteval)

[Jakub Jelinek]

On Fri, Nov 29, 2019 at 10:30:13AM +0100, Jakub Jelinek wrote:
> 2019-11-29  Jakub Jelinek  
> 
>   * c-cppbuiltin.c (c_cpp_builtins): Don't define __cpp_consteval for
>   now.
> 
>   * g++.dg/cpp2a/feat-cxx2a.C: Don't test __cpp_consteval for now.

I'd like to ping this patch (the wwwdocs change has been committed already).
Thanks.

> --- gcc/c-family/c-cppbuiltin.c.jj2019-11-28 09:02:23.705869433 +0100
> +++ gcc/c-family/c-cppbuiltin.c   2019-11-28 18:59:20.407918255 +0100
> @@ -999,7 +999,7 @@ c_cpp_builtins (cpp_reader *pfile)
> cpp_define (pfile, "__cpp_designated_initializers=201707L");
> cpp_define (pfile, "__cpp_constexpr_in_decltype=201711L");
> cpp_define (pfile, "__cpp_conditional_explicit=201806L");
> -   cpp_define (pfile, "__cpp_consteval=201811L");
> +   /* cpp_define (pfile, "__cpp_consteval=201811L"); */
> cpp_define (pfile, "__cpp_constinit=201907L");
> cpp_define (pfile, "__cpp_deduction_guides=201907L");
> cpp_define (pfile, "__cpp_nontype_template_parameter_class=201806L");
> --- gcc/testsuite/g++.dg/cpp2a/feat-cxx2a.C.jj2019-11-28 
> 09:02:25.331844453 +0100
> +++ gcc/testsuite/g++.dg/cpp2a/feat-cxx2a.C   2019-11-28 19:00:59.459400136 
> +0100
> @@ -520,11 +520,13 @@
>  #  error "__cpp_constexpr_in_decltype != 201711"
>  #endif
>  
> +/* Not supported fully yet:
>  #ifndef __cpp_consteval
>  #  error "__cpp_consteval"
>  #elif __cpp_consteval != 201811
>  #  error "__cpp_consteval != 201811"
>  #endif
> +*/
>  
>  #ifndef __cpp_concepts
>  #  error "__cpp_concepts"
> 

Jakub

Re: [PATCH] extend -Wstringop-overflow to allocated objects (PR 91582)

[Martin Sebor]

On 12/6/19 8:44 AM, Christophe Lyon wrote:

On Thu, 5 Dec 2019 at 02:37, Martin Sebor  wrote:


On 12/2/19 10:06 AM, Jeff Law wrote:

On 11/8/19 3:11 PM, Martin Sebor wrote:

Unless it's used with _FORTIFY_SOURCE, -Wstringop-overflow
doesn't consider out-of-bounds accesses to objects allocated
by alloca, malloc, other functions declared with attribute
alloc_size, or even VLAs with variable bounds.  This was
a known limitation of the checks (done just before expansion)
relying on the the object size pass when they were introduced
in GCC 7.

But since its introduction in GCC 7, the warning has evolved
beyond some of the limitations of the object size pass.  Unlike
it, the warning considers non-constant offsets and stores with
non-constant sizes.  Attached is a simple enhancement that
(finally) adds the ability to also detect overflow in allocated
objects to the warning.

With the patch GCC detects the overflow in code like this:

char* f (void)
{
  char s[] = "12345";
  char *p = malloc (strlen (s));
  strcpy (p, s);   // warning here
  return p;
}

but not (yet) in something like this:

char* g (const char *s)
{
  char *p = malloc (strlen (s));
  strcpy (p, s);   // no warning (yet)
  return p;
}

and quite a few other examples.  Doing better requires extending
the strlen pass.  I'm working on this extension and expect to
submit a patch before stage 1 ends.

Martin

PS I was originally planning to do all the allocation checking
in the strlen pass but it occurred to me that by also enhancing
the compute_objsize function, all warnings that use it will
benefit.  Besides -Wstringop-overflow this includes a subset
of -Warray-bounds, -Wformat-overflow, and -Wrestrict.  It's
nice when a small enhancement has such a broad positive effect.



PR middle-end/91582 - missing heap overflow detection for strcpy

gcc/ChangeLog:

  * builtins.c (gimple_call_alloc_size): New function.
  (compute_objsize): Add argument.  Call gimple_call_alloc_size.
  Handle variable offsets and indices.
  * builtins.h (gimple_call_alloc_size): Declare.
  (compute_objsize): Add argument.
  * tree-ssa-strlen.c (handle_store): Handle calls to allocated objects.

gcc/testsuite/ChangeLog:

  * c-c++-common/Wstringop-truncation.c: Remove xfails.
  * gcc/testsuite/g++.dg/ext/attr-alloc_size.C: Suppress -Warray-bounds.
  * gcc.dg/Wstringop-overflow-22.c: New test.
  * gcc/testsuite/gcc.dg/attr-alloc_size.c: Suppress -Warray-bounds.
  * gcc/testsuite/gcc.dg/attr-copy-2.c: Same.
  * gcc.dg/builtin-stringop-chk-5.c: Remove xfails.
  * gcc.dg/builtin-stringop-chk-8.c: Same.  Correct the text of expected
  warnings.
  * gcc.target/i386/pr82002-2a.c: Prune expected warning.
  * gcc.target/i386/pr82002-2b.c: Same.

[ ... ]



Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 277978)
+++ gcc/builtins.c  (working copy)
@@ -3563,6 +3563,80 @@ check_access (tree exp, tree, tree, tree dstwrite,
 return true;
   }

+/* If STMT is a call to an allocation function, returns the size
+   of the object allocated by the call.  */
+
+tree
+gimple_call_alloc_size (gimple *stmt)
+{
+  tree size = gimple_call_arg (stmt, argidx1);
+  tree n = argidx2 < nargs ? gimple_call_arg (stmt, argidx2) : 
integer_one_node;
+
+  /* To handle ranges do the math in wide_int and return the product
+ of the upper bounds as a constant.  Ignore anti-ranges.  */
+  wide_int rng1[2];
+  if (TREE_CODE (size) == INTEGER_CST)
+rng1[0] = rng1[1] = wi::to_wide (size);
+  else if (TREE_CODE (size) != SSA_NAME
+  || get_range_info (size, rng1, rng1 + 1) != VR_RANGE)
+return NULL_TREE;
+
+  wide_int rng2[2];
+  if (TREE_CODE (n) == INTEGER_CST)
+rng2[0] = rng2[1] = wi::to_wide (n);
+  else if (TREE_CODE (n) != SSA_NAME
+  || get_range_info (n, rng2 + 1, rng2 + 1) != VR_RANGE)
+return NULL_TREE;

Should that 2nd call to get_range_info be "get_range_info (n, rng2, rng2
+ 1)?  I don't think it makes any difference in practice due to the
implementation of get_range_info, but if it wasn't intentional let's get
it fixed.


Yes, it should be.  It's correct in my tree but didn't post
the updated revision.





Index: gcc/builtins.h
===
--- gcc/builtins.h  (revision 277978)
+++ gcc/builtins.h  (working copy)
@@ -134,7 +134,8 @@ extern tree fold_call_stmt (gcall *, bool);
   extern void set_builtin_user_assembler_name (tree decl, const char *asmspec);
   extern bool is_simple_builtin (tree);
   extern bool is_inexpensive_builtin (tree);
-extern tree compute_objsize (tree, int, tree * = NULL);
+tree gimple_call_alloc_size (gimple *);
+extern tree compute_objsize (tree, int, tree * = NULL, tree * = NULL);

   extern bool readonly_data_expr (tree 

Re: *PING* – Re: [Patch, Fortran] PR 92793 - fix column used for error diagnostic

[Janne Blomqvist]

On Fri, Dec 6, 2019 at 10:02 AM Tobias Burnus  wrote:
>
> *Ping*

Ok.
>
> Regarding Frederik's remark about the testsuite:
>
> I think the only test case in gfortran.dg/, which tests the column
> number, is use_without_only_1.f90. It has:
> { dg-warning "7:has no ONLY qualifier" }
> here, the "7" is the column number. — Hence, it is not surprising that
> changes do not affect the test suite.
>
> Cheers,
>
> Tobias
>
> On 12/4/19 2:37 PM, Tobias Burnus wrote:
> > As reported internally by Frederik, gfortran currently passes
> > LOCATION_COLUMN == 0 to the middle end. The reason for that is how
> > parsing works – gfortran reads the input line by line.
> >
> > For internal error diagnostic (fortran/error.c), the column location
> > was corrected –  but not for locations passed to the middle end.
> > Hence, the diagnostic there wasn't optimal.
> >
> > Fixed by introducing a new function; now one only needs to make sure
> > that no new code will re-introduce "lb->location" :-)
> >
> > Build and regtested on x86-64-gnu-linux.
> > OK for the trunk?
> >
> > Tobias
> >



-- 
Janne Blomqvist

[PATCH] Canonicalize fancy ways of expressing blend operation into COND_EXPR (PR tree-optimization/92834)

[Jakub Jelinek]

Hi!

The following patch canonicalizes fancy ways of writing cond ? A : B
into COND_EXPR, which is what we expect people writing and thus are able to
optimize it better.  If in some case we wouldn't optimize it better,
the right way would be improve the COND_EXPR handling, as that is what
people are using in the wild most of the time.
E.g. on the testcase in the patch on x86_64-linux with -O2, the difference
is that test used to be 519 bytes long and now is 223, with -O2
-march=skylake used to be the same 519 bytes long and now is 275 bytes (in
that case it uses the SSE4.1+ min/max).

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

2019-12-06  Jakub Jelinek  

PR tree-optimization/92834
* match.pd (A - ((A - B) & -(C cmp D)) -> (C cmp D) ? B : A,
A + ((B - A) & -(C cmp D)) -> (C cmp D) ? B : A): New simplifications.

* gcc.dg/tree-ssa/pr92834.c: New test.

--- gcc/match.pd.jj 2019-12-06 14:07:26.877749065 +0100
+++ gcc/match.pd2019-12-06 15:06:08.042953309 +0100
@@ -2697,6 +2697,31 @@ (define_operator_list COND_TERNARY
   (cmp (minmax @0 INTEGER_CST@1) INTEGER_CST@2)
   (comb (cmp @0 @2) (cmp @1 @2
 
+/* Undo fancy way of writing max/min or other ?: expressions,
+   like a - ((a - b) & -(a < b)), in this case into (a < b) ? b : a.
+   People normally use ?: and that is what we actually try to optimize.  */
+(for cmp (simple_comparison)
+ (simplify
+  (minus @0 (bit_and:c (minus @0 @1)
+  (convert? (negate@4 (convert? (cmp@5 @2 @3))
+  (if (INTEGRAL_TYPE_P (type)
+   && INTEGRAL_TYPE_P (TREE_TYPE (@4))
+   && TREE_CODE (TREE_TYPE (@4)) != BOOLEAN_TYPE
+   && INTEGRAL_TYPE_P (TREE_TYPE (@5))
+   && (TYPE_PRECISION (TREE_TYPE (@4)) >= TYPE_PRECISION (type)
+  || !TYPE_UNSIGNED (TREE_TYPE (@4
+   (cond (cmp @2 @3) @1 @0)))
+ (simplify
+  (plus:c @0 (bit_and:c (minus @1 @0)
+   (convert? (negate@4 (convert? (cmp@5 @2 @3))
+  (if (INTEGRAL_TYPE_P (type)
+   && INTEGRAL_TYPE_P (TREE_TYPE (@4))
+   && TREE_CODE (TREE_TYPE (@4)) != BOOLEAN_TYPE
+   && INTEGRAL_TYPE_P (TREE_TYPE (@5))
+   && (TYPE_PRECISION (TREE_TYPE (@4)) >= TYPE_PRECISION (type)
+  || !TYPE_UNSIGNED (TREE_TYPE (@4
+   (cond (cmp @2 @3) @1 @0
+
 /* Simplifications of shift and rotates.  */
 
 (for rotate (lrotate rrotate)
--- gcc/testsuite/gcc.dg/tree-ssa/pr92834.c.jj  2019-12-06 15:24:56.817353747 
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr92834.c 2019-12-06 15:24:08.921100518 
+0100
@@ -0,0 +1,122 @@
+/* PR tree-optimization/92834 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-times "MIN_EXPR <" 8 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "MAX_EXPR <" 8 "optimized" } } */
+
+static inline unsigned
+umax1 (unsigned a, unsigned b)
+{
+  return a - ((a - b) & -(a < b));
+}
+
+static inline unsigned
+umin1 (unsigned a, unsigned b)
+{
+  return a - ((a - b) & -(a > b));
+}
+
+static inline int
+smax1 (int a, int b)
+{
+  return a - ((a - b) & -(a < b));
+}
+
+static inline int
+smin1 (int a, int b)
+{
+  return a - ((a - b) & -(a > b));
+}
+
+static inline unsigned long long
+umax2 (unsigned long long a, unsigned long long b)
+{
+  return a - ((a - b) & -(a <= b));
+}
+
+static inline unsigned long long
+umin2 (unsigned long long a, unsigned long long b)
+{
+  return a - ((a - b) & -(a >= b));
+}
+
+static inline long long
+smax2 (long long a, long long b)
+{
+  return a - ((a - b) & -(a <= b));
+}
+
+static inline long long
+smin2 (long long a, long long b)
+{
+  return a - ((a - b) & -(a >= b));
+}
+
+static inline unsigned
+umax3 (unsigned a, unsigned b)
+{
+  return a + ((b - a) & -(a < b));
+}
+
+static inline unsigned
+umin3 (unsigned a, unsigned b)
+{
+  return a + ((b - a) & -(a > b));
+}
+
+static inline int
+smax3 (int a, int b)
+{
+  return a + ((b - a) & -(a < b));
+}
+
+static inline int
+smin3 (int a, int b)
+{
+  return a + ((b - a) & -(a > b));
+}
+
+static inline unsigned long long
+umax4 (unsigned long long a, unsigned long long b)
+{
+  return a + ((b - a) & -(a <= b));
+}
+
+static inline unsigned long long
+umin4 (unsigned long long a, unsigned long long b)
+{
+  return a + ((b - a) & -(a >= b));
+}
+
+static inline long long
+smax4 (long long a, long long b)
+{
+  return a + ((b - a) & -(a <= b));
+}
+
+static inline long long
+smin4 (long long a, long long b)
+{
+  return a + ((b - a) & -(a >= b));
+}
+
+void
+test (unsigned *x, int *y, unsigned long long *z, long long *w)
+{
+  x[2] = umax1 (x[0], x[1]);
+  x[5] = umin1 (x[2], x[3]);
+  y[2] = smax1 (y[0], y[1]);
+  y[5] = smin1 (y[2], y[3]);
+  z[2] = umax2 (z[0], z[1]);
+  z[5] = umin2 (z[2], z[3]);
+  w[2] = smax2 (w[0], w[1]);
+  w[5] = smin2 (w[2], w[3]);
+  x[8] = umax3 (x[6], x[7]);
+  x[11] = umin3 (x[9], x[10]);
+  y[8] = smax3 (y[6], y[7]);
+  y[11] = smin3 (y[9], y[10]);
+  z[8] = umax4 (z[6], z[7]);
+  z[11] 

Re: [PATCH, Modula-2 (C/C++/D/F/Go/Jit)] (Register spec fn) (v3)

[Matthias Klose]

On 17.11.19 07:49, Gaius Mulley wrote:
> 
> Hello,
> 
> while spending the weekend on the Howland and Baker islands :-) I
> thought I'd post version three of the patches which introduce Modula-2
> into the GCC trunk.  The patches include:

[...]

> At a later point (after it is reviewed/approved) the gm2 tree
> http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/m2/ could
> be included.  Together with the gm2 testsuite.
> 
> But for now here are the proposed patches and ChangeLogs and new files
> (gm2-v3.tar.gz) (after the patches):

I have updated my distro packaging to build gcc-10, including gm2 from the
trunk.  Both native and cross builds seem to work, with some glitches:

 - For native builds, the profiled build doesn't work, failing to link
   the gcov library. Failing that, I can't check the lto+profiled build.
   Both the profiled and lto+profiled builds are working on your gcc-9
   branch.

 - For cross builds, the libgm2 libraries install as host libraries,
   not target libraries (but are correctly built).  I sent one patch
   to Gaius, but couldn't figure out yet, why the libs are not
   installed as target libraries.

The packages are publicly available in Debian experimental [1] and Ubuntu focal
[2], test results are sent to the gcc-testresults ML.

Are you still aiming for inclusion in GCC 10?

Matthias

[1] https://tracker.debian.org/pkg/gcc-10
[2]
https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/10781708/+listing-archive-extra

[C++ PATCH] CWG 1299, not extending temporary lifetime for ?: (PR c++/92831)

[Jakub Jelinek]

Hi!

This is a reason latest firefox is miscompiled by G++ 9, seems DR 1299
says in [class.temporary]/(6.7) that reference binding to a temporary
object from the second or third operand of a conditional expression
should have extended lifetime too, but extend_ref_init_temps_1 was
apparently handling only comma expressions, some casts, . (COMPONENT_REF),
[] (ARRAY_REF), but not COND_EXPR.

The following patch handles COND_EXPR in there too, in a similar way how
the gimplifier handles the cleanups of the expressions in the COND_EXPR
operand if there is no lifetime extension due to reference binding.
In particular there are bool temporaries added, initialized to false and set
to true if the particular (leaf) COND_EXPR argument has been invoked and the
corresponding cleanup guarded that way.

I admit I haven't tried to construct testcases for all the things CWG 1299
added, e.g. don't know if ( expression ) will work, if all the *_cast cases
that need to be extended work (some of them do, as the testcase shows), or
if e.g. .* works, so I'm not claiming the DR is completely implemented.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
and after a while for release branches?

Note, just to double check g++ doesn't ICE on expr1 ? : expr2 GNU extension,
I also wrote the attached testcase, but unlike the testcase included in the
patch which behaves the same with patched g++ as does recent clang++, the
testcase with expr1 ? : expr2 (omitted second operand) actually never
extends the lifetime of any temporary (that is the baz function), unlike
clang++ which extends the lifetime of expr2 if expr1 is false, and doesn't
extend lifetime of anything if expr1 is true.  This is outside of the scope
of the standard, so no idea what is correct, so I'm just asking how it
should behave.  extend_ref_init_temps_1 is never called in that case when
the expression is COND_EXPR.

2019-12-06  Jakub Jelinek  

PR c++/92831 - CWG 1299, not extending temporary lifetime for ?:
* cp-tree.h (extend_ref_init_temps): Add a new argument with NULL
default arg.
* call.c (set_up_extended_ref_temp): Add COND_GUARD argument, pass it
down to extend_ref_init_temps.  Before pushing cleanup, if COND_GUARD
is non-NULL, create a bool temporary if needed, initialize to false
and guard the cleanup with the temporary being true.
(extend_ref_init_temps_1): Add COND_GUARD argument, pass it down
to recursive calls and set_up_extended_ref_temp.  Handle COND_EXPR.
(extend_ref_init_temps): Add COND_GUARD argument, pass it down to
recursive calls and to extend_ref_init_temps_1.

* g++.dg/cpp0x/temp-extend2.C: New test.

--- gcc/cp/cp-tree.h.jj 2019-12-05 10:03:04.81297 +0100
+++ gcc/cp/cp-tree.h2019-12-06 11:00:43.230257916 +0100
@@ -6321,7 +6321,9 @@ extern tree convert_for_arg_passing   (tr
 extern bool is_properly_derived_from   (tree, tree);
 extern tree initialize_reference   (tree, tree, int,
 tsubst_flags_t);
-extern tree extend_ref_init_temps  (tree, tree, vec**);
+extern tree extend_ref_init_temps  (tree, tree,
+vec**,
+tree * = NULL);
 extern tree make_temporary_var_for_ref_to_temp (tree, tree);
 extern bool type_has_extended_temps(tree);
 extern tree strip_top_quals(tree);
--- gcc/cp/call.c.jj2019-12-06 00:40:29.439856520 +0100
+++ gcc/cp/call.c   2019-12-06 11:00:17.111660971 +0100
@@ -11965,7 +11965,7 @@ make_temporary_var_for_ref_to_temp (tree
 
 static tree
 set_up_extended_ref_temp (tree decl, tree expr, vec **cleanups,
- tree *initp)
+ tree *initp, tree *cond_guard)
 {
   tree init;
   tree type;
@@ -11996,7 +11996,8 @@ set_up_extended_ref_temp (tree decl, tre
 
   /* Recursively extend temps in this initializer.  */
   TARGET_EXPR_INITIAL (expr)
-= extend_ref_init_temps (decl, TARGET_EXPR_INITIAL (expr), cleanups);
+= extend_ref_init_temps (decl, TARGET_EXPR_INITIAL (expr), cleanups,
+cond_guard);
 
   /* Any reference temp has a non-trivial initializer.  */
   DECL_NONTRIVIALLY_INITIALIZED_P (var) = true;
@@ -12037,7 +12038,24 @@ set_up_extended_ref_temp (tree decl, tre
{
  tree cleanup = cxx_maybe_build_cleanup (var, tf_warning_or_error);
  if (cleanup)
-   vec_safe_push (*cleanups, cleanup);
+   {
+ if (cond_guard && cleanup != error_mark_node)
+   {
+ if (*cond_guard == NULL_TREE)
+   {
+ *cond_guard = build_local_temp (boolean_type_node);
+ add_decl_expr (*cond_guard);
+ tree set = cp_build_modify_expr (UNKNOWN_LOCATION,
+

Re: libgo patch committed: Always mark assembly file as non-executable stack

[Matthias Klose]

On 06.12.19 12:28, Rainer Orth wrote:
> I Ian,
> 
>> This libgo patch arranges for go-context.S to always be marked as
>> using a non-executable stack.  This is not required for all targets,
>> but should do little harm.  Bootstrapped on x86_64-pc-linux-gnu.
>> Committed to mainline.
> 
> unfortunately, it does, breaking bootstrap on Solaris/SPARC and x86 with
> the native assembler:
> 
> * Solaris/SPARC with as:
> 
> /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: invalid character 
> (0x40)
> /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: quoted-string operand 
> required
> /usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: statement syntax
> make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1
> 
> * Solaris/x86 with as:
> 
> Assembler:
> "/vol/gcc/src/hg/trunk/local/libgo/runtime/go-context.S", line 74 : 
> Syntax error
> Near line: " .section .note.GNU-stack,"",@progbits"
> make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1

also on arm-linux-gnueabi*. Patch in PR go/92820

Matthias

[C++ Patch] Improve build_*_cast locations

[Paolo Carlini]

Hi,

as promised, the below takes care of the various remaining casts. It's 
mostly mechanical, follows the same approach used for 
build_functional_cast. Tested x86_64-linux.


Thanks, Paolo.



gcc/cp
2019-12-06  Paolo Carlini  

* typeck.c (check_for_casting_away_constness): Add location_t
parameter and use it.
(maybe_warn_about_useless_cast): Likewise.
(maybe_warn_about_cast_ignoring_quals): Likewise.
(build_static_cast_1): Likewise.
(build_static_cast): Likewise.
(build_reinterpret_cast_1): Likewise.
(build_reinterpret_cast): Likewise.
(build_const_cast_1): Likewise.
(build_const_cast): Likewise.
(cp_build_c_cast): Likewise.
(build_c_cast): Adjust.
(build_ptrmemfunc): Adjust calls.
(cp_build_unary_op): Pass the location to invert_truthvalue_loc.
* rtti.c (build_dynamic_cast_1): Add location_t parameter and
use it.
(build_dynamic_cast): Likewise.
* cp-tree.h: Adjust declarations.
* parser.c (cp_parser_postfix_expression): Pass cp_cast_loc to
the various build_*_cast functions.
(get_cast_suggestion): Adjust calls.
(cp_parser_builtin_offsetof): Likewise.
* decl.c (reshape_init): Adjust call.
* method.c (forward_parm): Likewise.
(build_comparison_op): Likewise.
* pt.c (tsubst_copy_and_build): Likewise.
* semantics.c (finish_omp_reduction_clause): Likewise.
(cp_omp_finish_iterators): Likewise.
* tree.c (cp_stabilize_reference): Likewise.
(move): Likewise.
* typeck2.c (build_functional_cast): Likewise.

/libcc1
2019-12-06  Paolo Carlini  

* libcp1plugin.cc (plugin_build_cast_expr): Adjust build_cast
declaration.

gcc/testsuite
2019-12-06  Paolo Carlini  

* c-c++-common/Wcast-align.c: Check location(s) too.
* c-c++-common/Wcast-function-type.c: Likewise.
* c-c++-common/Wint-to-pointer-cast-1.c: Likewise.
* c-c++-common/Wint-to-pointer-cast-2.c: Likewise.
* c-c++-common/Wint-to-pointer-cast-3.c: Likewise.
* g++.dg/Wcast-function-type.C: Likewise.
* g++.dg/addr_builtin-1.C: Likewise.
* g++.dg/conversion/const2.C: Likewise.
* g++.dg/conversion/dynamic1.C: Likewise.
* g++.dg/conversion/ptrmem2.C: Likewise.
* g++.dg/conversion/ptrmem3.C: Likewise.
* g++.dg/conversion/qual3.C: Likewise.
* g++.dg/conversion/reinterpret3.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-conv11.C: Likewise.
* g++.dg/cpp0x/nullptr04.C: Likewise.
* g++.dg/cpp0x/reinterpret_cast2.C: Likewise.
* g++.dg/cpp0x/rv-cast2.C: Likewise.
* g++.dg/cpp1y/lambda-conv1.C: Likewise.
* g++.dg/cpp1z/noexcept-type7.C: Likewise.
* g++.dg/cpp2a/array-conv9.C: Likewise.
* g++.dg/expr/cast11.C: Likewise.
* g++.dg/expr/static_cast8.C: Likewise.
* g++.dg/ext/vector6.C: Likewise.
* g++.dg/other/conversion1.C: Likewise.
* g++.dg/parse/pr26997.C: Likewise.
* g++.dg/rtti/no-rtti.C: Likewise.
* g++.dg/tc1/dr137.C: Likewise.
* g++.dg/template/cast4.C: Likewise.
* g++.dg/warn/Wcast-qual1.C: Likewise.
* g++.dg/warn/Wcast-qual2.C: Likewise.
* g++.dg/warn/Wconditionally-supported-1.C: Likewise.
* g++.dg/warn/Wuseless-cast.C: Likewise.
* g++.dg/warn/pr35711.C: Likewise.
* g++.old-deja/g++.bugs/900227_01.C: Likewise.
* g++.old-deja/g++.bugs/900404_07.C: Likewise.
* g++.old-deja/g++.jason/overload1.C: Likewise.
* g++.old-deja/g++.jason/rfg26.C: Likewise.
* g++.old-deja/g++.jason/rvalue3.C: Likewise.
* g++.old-deja/g++.jason/warning2.C: Likewise.
* g++.old-deja/g++.mike/dyncast4.C: Likewise.
* g++.old-deja/g++.mike/dyncast6.C: Likewise.
* g++.old-deja/g++.mike/p11482.C: Likewise.
* g++.old-deja/g++.mike/p2573.C: Likewise.
* g++.old-deja/g++.mike/p2855.C: Likewise.
* g++.old-deja/g++.mike/p7476.C: Likewise.
* g++.old-deja/g++.mike/p8039.C: Likewise.
* g++.old-deja/g++.other/cast2.C: Likewise.
* g++.old-deja/g++.other/cast3.C: Likewise.
* g++.old-deja/g++.other/dcast1.C: Likewise.
* g++.old-deja/g++.other/dcast2.C: Likewise.

Index: gcc/cp/cp-tree.h
===
--- gcc/cp/cp-tree.h(revision 279041)
+++ gcc/cp/cp-tree.h(working copy)
@@ -6998,7 +6998,8 @@ extern tree build_typeid  (tree, 
tsubst_flags_t);
 extern tree get_tinfo_decl (tree);
 extern tree get_typeid (tree, tsubst_flags_t);
 extern tree build_headof   (tree);
-extern tree build_dynamic_cast (tree, tree, tsubst_flags_t);
+extern tree build_dynamic_cast (location_t, tree, 

Re: [PATCH] Enable ICE-after-error with -fchecking

[Segher Boessenkool]

On Wed, Dec 04, 2019 at 05:26:25PM +0100, Jakub Jelinek wrote:
> I'd fear people will use -fchecking and feel error-recovery bugs are then
> more important because they no longer get the more user friendly message.
> Can't we arrange for the emergency IL dump to happen in this case anyway?

Does it not already happen?  You need dump files enabled, of course.


Segher

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

[David Malcolm]

On Tue, 2019-11-26 at 11:28 -0500, Lewis Hyatt wrote:
> New version 4 patch attached, and responses below too.
> 

Thanks for the various updates; sorry about the delay in responding.

[...]

> > As noted above, m_x_offset should be renamed to clarify its units
> > ("m_x_offset_display"?)
> > 
> > Can you move this calculation of the offset to a subroutine please.
> > (I wonder if it can be unit-tested, but don't feel obliged to).
> > 
> 
> Done. I also split the calculation of m_linenum_width into a
> subroutine for consistency, and added new selftests that cover both.
> 
> One thing that came up when setting up the selftests. The existing
> code
> offsets the caret position by (m_linenum_width + 2) when comparing it
> to the
> physical end of the display. I think this should be (m_linenum_width
> + 3),
> because the line number is followed by the three-character string " |
> "
> prior to the start of the source line. I went ahead and made that
> change.

This was one part of the patch I wasn't sure about, but I've been
re-reading it and have come round.

We emit a space after the '|' for m_x_offset's column, which is
column 0 for the "no offset" case.
There are a few places where move_to_column is used to reset things
after a possible newline.

I think I've had in my mind the idea that there's an initial space
after the '|' that terminates the left margin, and then the source
begins, but for some reason I thought that if we were offsetting,
then the offset source could potentially begin right up against the '|' 
character.

On re-reading trunk's implementation, I think that that isn't the
current behavior, and that we simply have a " | " margin as your
patch describes, with the offset source text being printed after it.

Indeed, I think we ought to always have at least some indent of the
source lines, so that they stand out from the diagnostic lines.


> It did require a corresponding change to resolve some new testsuites
> failure
> afterwards, in this file:
> 
> gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
> 
> The expected output just needs to shift left by one column, which I
> did in
> this version of the patch as well. It seems to make sense to me, but
> I
> wanted to mention in case I am missing something subtle here. I made
> a
> similar adjustment in case line numbers are not being output; here we
> still
> output a space before every line so it feels like that should be
> taken into
> account.

> This calculation still does not attempt to take into account whether
> pp_print_prefix () will do anything, not sure if that is desired or
> not, but
> it was the existing behavior.
> 
> I am glad you brought this up, as the logic is a little tricky and
> another
> issue was fixed when I separated it out and worked through the tests:
> some
> source lines cannot be offset by exactly as many display columns as
> dictated
> by m_x_offset_display. For instance, if the offset is 1 column, and
> the
> portion of the line to be deleted ends with a character of wcwidth 2,
> then
> it ends up offsetting too much. I added code to pad with a space in
> this
> case to make it line up again. This is in the selftests as well.

Excellent; thanks for doing this.

[...]

> BTW, bootstrap and reg-test were performed in linux x86-64. Test
> results are
> the same before and after:
> 
> FAIL 104 104
> PASS 454289 454289
> UNSUPPORTED 10722 10722
> UNTESTED 205 205
> XFAIL 1652 1652
> XPASS 35 35
> 
> Also I wanted to remind that the three Unicode data files:
> 
> contrib/unicode/EastAsianWidth.txt
> contrib/unicode/PropList.txt
> contrib/unicode/UnicodeData.txt
> 
> are to be committed along with this this patch but I did not include
> them in
> the email since they are so large.
> 
> Thanks again for your time, assuming you have the patience to look at
> this
> again :).
> 
> -Lewis

[...]

> gcc/testsuite/ChangeLog:
> 
> 2019-11-26  Lewis Hyatt  
> 
> * gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
> (test_show_locus): Adjust expected output based on new behavior.

To be pedantic, this ChangeLog text seems wrong: I think you're
actually tweaking the config to preserve the old expected output given
the new x-offset implementation, right?  The change in question is:

> diff --git a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c 
> b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
> index 3f62edd408e..153bdb2fd89 100644
> --- a/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
> +++ b/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
> @@ -174,7 +174,7 @@ test_show_locus (function *fun)
>  
>/* Hardcode the "terminal width", to verify the behavior of
>   very wide lines.  */
> -  global_dc->caret_max_width = 70;
> +  global_dc->caret_max_width = 71;
>  
>if (0 == strcmp (fnname, "test_simple"))
>  {

[...]

> diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
> index 

Re: [PATCH] extend -Wstringop-overflow to allocated objects (PR 91582)

[Christophe Lyon]

On Thu, 5 Dec 2019 at 02:37, Martin Sebor  wrote:
>
> On 12/2/19 10:06 AM, Jeff Law wrote:
> > On 11/8/19 3:11 PM, Martin Sebor wrote:
> >> Unless it's used with _FORTIFY_SOURCE, -Wstringop-overflow
> >> doesn't consider out-of-bounds accesses to objects allocated
> >> by alloca, malloc, other functions declared with attribute
> >> alloc_size, or even VLAs with variable bounds.  This was
> >> a known limitation of the checks (done just before expansion)
> >> relying on the the object size pass when they were introduced
> >> in GCC 7.
> >>
> >> But since its introduction in GCC 7, the warning has evolved
> >> beyond some of the limitations of the object size pass.  Unlike
> >> it, the warning considers non-constant offsets and stores with
> >> non-constant sizes.  Attached is a simple enhancement that
> >> (finally) adds the ability to also detect overflow in allocated
> >> objects to the warning.
> >>
> >> With the patch GCC detects the overflow in code like this:
> >>
> >>char* f (void)
> >>{
> >>  char s[] = "12345";
> >>  char *p = malloc (strlen (s));
> >>  strcpy (p, s);   // warning here
> >>  return p;
> >>}
> >>
> >> but not (yet) in something like this:
> >>
> >>char* g (const char *s)
> >>{
> >>  char *p = malloc (strlen (s));
> >>  strcpy (p, s);   // no warning (yet)
> >>  return p;
> >>}
> >>
> >> and quite a few other examples.  Doing better requires extending
> >> the strlen pass.  I'm working on this extension and expect to
> >> submit a patch before stage 1 ends.
> >>
> >> Martin
> >>
> >> PS I was originally planning to do all the allocation checking
> >> in the strlen pass but it occurred to me that by also enhancing
> >> the compute_objsize function, all warnings that use it will
> >> benefit.  Besides -Wstringop-overflow this includes a subset
> >> of -Warray-bounds, -Wformat-overflow, and -Wrestrict.  It's
> >> nice when a small enhancement has such a broad positive effect.
> >
> >> PR middle-end/91582 - missing heap overflow detection for strcpy
> >>
> >> gcc/ChangeLog:
> >>
> >>  * builtins.c (gimple_call_alloc_size): New function.
> >>  (compute_objsize): Add argument.  Call gimple_call_alloc_size.
> >>  Handle variable offsets and indices.
> >>  * builtins.h (gimple_call_alloc_size): Declare.
> >>  (compute_objsize): Add argument.
> >>  * tree-ssa-strlen.c (handle_store): Handle calls to allocated 
> >> objects.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >>  * c-c++-common/Wstringop-truncation.c: Remove xfails.
> >>  * gcc/testsuite/g++.dg/ext/attr-alloc_size.C: Suppress 
> >> -Warray-bounds.
> >>  * gcc.dg/Wstringop-overflow-22.c: New test.
> >>  * gcc/testsuite/gcc.dg/attr-alloc_size.c: Suppress -Warray-bounds.
> >>  * gcc/testsuite/gcc.dg/attr-copy-2.c: Same.
> >>  * gcc.dg/builtin-stringop-chk-5.c: Remove xfails.
> >>  * gcc.dg/builtin-stringop-chk-8.c: Same.  Correct the text of 
> >> expected
> >>  warnings.
> >>  * gcc.target/i386/pr82002-2a.c: Prune expected warning.
> >>  * gcc.target/i386/pr82002-2b.c: Same.
> > [ ... ]
> >
> >
> >> Index: gcc/builtins.c
> >> ===
> >> --- gcc/builtins.c  (revision 277978)
> >> +++ gcc/builtins.c  (working copy)
> >> @@ -3563,6 +3563,80 @@ check_access (tree exp, tree, tree, tree dstwrite,
> >> return true;
> >>   }
> >>
> >> +/* If STMT is a call to an allocation function, returns the size
> >> +   of the object allocated by the call.  */
> >> +
> >> +tree
> >> +gimple_call_alloc_size (gimple *stmt)
> >> +{
> >> +  tree size = gimple_call_arg (stmt, argidx1);
> >> +  tree n = argidx2 < nargs ? gimple_call_arg (stmt, argidx2) : 
> >> integer_one_node;
> >> +
> >> +  /* To handle ranges do the math in wide_int and return the product
> >> + of the upper bounds as a constant.  Ignore anti-ranges.  */
> >> +  wide_int rng1[2];
> >> +  if (TREE_CODE (size) == INTEGER_CST)
> >> +rng1[0] = rng1[1] = wi::to_wide (size);
> >> +  else if (TREE_CODE (size) != SSA_NAME
> >> +  || get_range_info (size, rng1, rng1 + 1) != VR_RANGE)
> >> +return NULL_TREE;
> >> +
> >> +  wide_int rng2[2];
> >> +  if (TREE_CODE (n) == INTEGER_CST)
> >> +rng2[0] = rng2[1] = wi::to_wide (n);
> >> +  else if (TREE_CODE (n) != SSA_NAME
> >> +  || get_range_info (n, rng2 + 1, rng2 + 1) != VR_RANGE)
> >> +return NULL_TREE;
> > Should that 2nd call to get_range_info be "get_range_info (n, rng2, rng2
> > + 1)?  I don't think it makes any difference in practice due to the
> > implementation of get_range_info, but if it wasn't intentional let's get
> > it fixed.
>
> Yes, it should be.  It's correct in my tree but didn't post
> the updated revision.
>
> >
> >
> >> Index: gcc/builtins.h
> >> ===
> >> --- gcc/builtins.h  (revision 

Re: [PATCH v2 2/2][ARM] Improve max_cond_insns setting for Cortex cores

[Christophe Lyon]

On Fri, 6 Dec 2019 at 16:03, Wilco Dijkstra  wrote:
>
> Hi Christophe,
>
> I've added an option to allow the warning to be enabled/disabled:
> https://sourceware.org/ml/binutils/2019-12/msg00093.html
>
Thanks.

In practice, how do you activate it when running the GCC testsuite? Do
you plan to send a GCC patch to enable this assembler flag, or do you
locally enable that option by default in your binutils?
FWIW, I've also noticed that the whole libstdc++ testsuite is somehow
"deactivated" (I have 0 pass, 0 fail etc...)  after your GCC patch
when configuring GCC
--target arm-none-linux-gnueabihf
--with-mode thumb
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8

Or do you filter these warnings in dejagnu ?

> Cheers,
> Wilco

Re: [PATCH v2 2/2][ARM] Improve max_cond_insns setting for Cortex cores

[Wilco Dijkstra]

Hi Christophe,

I've added an option to allow the warning to be enabled/disabled:
https://sourceware.org/ml/binutils/2019-12/msg00093.html

Cheers,
Wilco

Re: [PATCH] [libgomp, amdgcn] Fix Fortran linker errors on AMD GCN

[Thomas Schwinge]

Hi Kwok!

On 2019-12-06T14:17:47+, Kwok Cheung Yeung  wrote:
> While running the libgomp testsuite with an AMD GCN card configured as 
> as the offload accelerator, I often see these errors with the Fortran 
> testcases:
>
> ld: error: undefined symbol: gomp_ialias_omp_get_num_procs
 referenced by fortran.c:330 
> (/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/libgompg/fortran.c:330)
   fortran.o:(omp_get_num_procs_) in archive 
> /scratch/ci-cs/amdtest/upstream-offload/obj/test-mainline-0-x86_64-none-linux-gnu/host-x86_64-linux-gnu/fsf-mainline/bin/../lib/gcc/x86_64-none-linux-gnu/10.0.0/accel/amdgcn-unknown-amdhsa/../../../../../../amdgcn-unknown-amdhsa/lib/gfx906/libgomp.a
>
> omp_get_num_procs_ in fortran.c calls omp_get_num_procs, but the 
> declaration of omp_get_num_procs is processed using the ialias_redirect 
> macro so that it is aliased to a function named 
> gomp_ialias_omp_get_num_procs. The definition of omp_get_num_procs is in 
> libgomp/config/accel/proc.c, but it is not aliased to 
> gomp_ialias_omp_get_num_procs, so the linker fails to satisfy the reference.
>
> This patch applies the corresponding ialias macro to the definition of 
> gomp_omp_get_num_procs in libgomp/config/accel/proc.c. This is already 
> done with the alternative definitions in the mingw32, bsd, linux, posix 
> and rtems subdirectories of libgomp/config/.

Thanks for the clear description.

I suppose this hasn't been a problem for nvptx, as we're not
supporting/using the symbol aliasing machinery there.

> Tested on an x86_64 host with both NVPTX and GCN offloading. Okay to 
> commit to trunk?

Yes, thanks.  To record the review effort, please include "Reviewed-by:
Thomas Schwinge " in the commit log, see
.


Grüße
 Thomas


> 2019-12-06  Kwok Cheung Yeung  
>
>   libgomp/
>   * config/accel/proc.c (omp_get_num_procs): Apply ialias macro.
> ---
>   libgomp/config/accel/proc.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/libgomp/config/accel/proc.c b/libgomp/config/accel/proc.c
> index 8ca0b0a..be4cb30 100644
> --- a/libgomp/config/accel/proc.c
> +++ b/libgomp/config/accel/proc.c
> @@ -39,3 +39,5 @@ omp_get_num_procs (void)
>   {
> return gomp_icv (false)->nthreads_var;
>   }
> +
> +ialias (omp_get_num_procs)


signature.asc
Description: PGP signature

Re: Ping: [PATCH][C++] Pass type uses through the verify_type_context hook

[Richard Sandiford]

Jason Merrill  writes:
> On 12/5/19 1:21 PM, Richard Sandiford wrote:
>> +  else if (!verify_type_context (input_location, TCTX_EXCEPTIONS, type))
>> +return false;
>> +
>> +  else if (TYPE_REF_P (type)
>> +   && !verify_type_context (input_location, TCTX_EXCEPTIONS,
>> +TREE_TYPE (type)))
>
> You could use the non_reference function to combine these.

Thanks.  This patch fixes that and follows Marek's suggestion of using
location_of in check_array_initializer.  (I wondered whether to check
for decl == error_mark_node as well, but that can't currently happen.)

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

Richard


2019-12-06  Richard Sandiford  

gcc/
* target.h (TCTX_ALLOCATION, TCTX_DEALLOCATION, TCTX_EXCEPTIONS)
(TCTX_CAPTURE_BY_COPY): New type_context_kinds.
* config/aarch64/aarch64-sve-builtins.cc (verify_type_context):
Handle them.

gcc/cp/
* decl.c (start_decl_1): Use verify_type_context to check whether
the target allows variables of a particular type to have static
or thread-local storage duration.
(check_array_initializer): Use verify_type_context to check whether
the target allows a particular type to be used as an array element.
(create_array_type_for_decl): Likewise.
(cp_finish_decl): Use verify_type_context to check whether
the target allows static member variables of a particular type.
(grokdeclarator): Likewise.  Also use verify_type_context to check
whether the target allows non-static member variables of a particular
type.
* except.c: Include target.h.
(is_admissible_throw_operand_or_catch_parameter): Use
verify_type_context to check whether the target allows particular
types to be thrown and caught.
* typeck2.c (add_exception_specifier): Likewise.
* init.c (build_new_1): Use verify_type_context to check whether
the target allows particular types to be dynamically allocated.
(build_vec_delete_1, build_delete): Use verify_type_context to check
whether the target allows particular types to be deleted.
* lambda.c (add_capture): Use verify_type_context to check
whether the target allows particular types to be captured by copy.
* pt.c: Include target.h.
(instantiate_class_template_1): Use verify_type_context to check
whether the target allows non-static member variables of a particular
type.
* typeck.c (cxx_alignof_expr): Use verify_type_context to check
whether the target allows the alignment of a particular type
to be measured.
(pointer_diff, cp_build_unary_op): Use verify_type_context to check
whether the target allows arithmetic involving pointers to particular
types.

gcc/testsuite/
* g++.dg/ext/sve-sizeless-1.C: New test.
* g++.dg/ext/sve-sizeless-2.C: Likewise.

Index: gcc/target.h
===
--- gcc/target.h2019-12-04 13:13:48.0 +
+++ gcc/target.h2019-12-06 14:11:28.233552680 +
@@ -249,7 +249,19 @@ enum type_context_kind {
 
   /* Adding to or subtracting from a pointer to T, or computing the
  difference between two pointers when one of them is a pointer to T.  */
-  TCTX_POINTER_ARITH
+  TCTX_POINTER_ARITH,
+
+  /* Dynamically allocating objects of type T.  */
+  TCTX_ALLOCATION,
+
+  /* Dynamically deallocating objects of type T.  */
+  TCTX_DEALLOCATION,
+
+  /* Throwing or catching an object of type T.  */
+  TCTX_EXCEPTIONS,
+
+  /* Capturing objects of type T by value in a closure.  */
+  TCTX_CAPTURE_BY_COPY
 };
 
 extern bool verify_type_context (location_t, type_context_kind, const_tree,
Index: gcc/config/aarch64/aarch64-sve-builtins.cc
===
--- gcc/config/aarch64/aarch64-sve-builtins.cc  2019-12-04 13:13:48.0 
+
+++ gcc/config/aarch64/aarch64-sve-builtins.cc  2019-12-06 14:11:28.217552787 
+
@@ -3352,6 +3352,26 @@ verify_type_context (location_t loc, typ
   if (!silent_p)
error_at (loc, "array elements cannot have SVE type %qT", type);
   return false;
+
+case TCTX_ALLOCATION:
+  if (!silent_p)
+   error_at (loc, "cannot allocate objects with SVE type %qT", type);
+  return false;
+
+case TCTX_DEALLOCATION:
+  if (!silent_p)
+   error_at (loc, "cannot delete objects with SVE type %qT", type);
+  return false;
+
+case TCTX_EXCEPTIONS:
+  if (!silent_p)
+   error_at (loc, "cannot throw or catch SVE type %qT", type);
+  return false;
+
+case TCTX_CAPTURE_BY_COPY:
+  if (!silent_p)
+   error_at (loc, "capture by copy of SVE type %qT", type);
+  return false;
 }
   gcc_unreachable ();
 }
Index: gcc/cp/decl.c

Re: [PATCH] Come up with constructors of symtab_node, cgraph_node and varpool_node.

[Michael Matz]

Hi,

On Thu, 5 Dec 2019, Richard Biener wrote:

> >> Indeed - please adjust that as well. 
> >
> >Explicit ctors are a c++11+ feature.
> 
> Surely not.

Whoops, I was conflating ctors and conversion functions, the latter can 
be explicit only in c++11+.


Ciao,
Michael.

[PATCH] [libgomp, amdgcn] Fix Fortran linker errors on AMD GCN

[Kwok Cheung Yeung]

Hello

While running the libgomp testsuite with an AMD GCN card configured as 
as the offload accelerator, I often see these errors with the Fortran 
testcases:


ld: error: undefined symbol: gomp_ialias_omp_get_num_procs
referenced by fortran.c:330 

(/scratch/ci-cs/amdtest/upstream-offload/src/gcc-mainline/libgompg/fortran.c:330)
  fortran.o:(omp_get_num_procs_) in archive 

/scratch/ci-cs/amdtest/upstream-offload/obj/test-mainline-0-x86_64-none-linux-gnu/host-x86_64-linux-gnu/fsf-mainline/bin/../lib/gcc/x86_64-none-linux-gnu/10.0.0/accel/amdgcn-unknown-amdhsa/../../../../../../amdgcn-unknown-amdhsa/lib/gfx906/libgomp.a

omp_get_num_procs_ in fortran.c calls omp_get_num_procs, but the 
declaration of omp_get_num_procs is processed using the ialias_redirect 
macro so that it is aliased to a function named 
gomp_ialias_omp_get_num_procs. The definition of omp_get_num_procs is in 
libgomp/config/accel/proc.c, but it is not aliased to 
gomp_ialias_omp_get_num_procs, so the linker fails to satisfy the reference.


This patch applies the corresponding ialias macro to the definition of 
gomp_omp_get_num_procs in libgomp/config/accel/proc.c. This is already 
done with the alternative definitions in the mingw32, bsd, linux, posix 
and rtems subdirectories of libgomp/config/.


Tested on an x86_64 host with both NVPTX and GCN offloading. Okay to 
commit to trunk?


Kwok


2019-12-06  Kwok Cheung Yeung  

libgomp/
* config/accel/proc.c (omp_get_num_procs): Apply ialias macro.
---
 libgomp/config/accel/proc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libgomp/config/accel/proc.c b/libgomp/config/accel/proc.c
index 8ca0b0a..be4cb30 100644
--- a/libgomp/config/accel/proc.c
+++ b/libgomp/config/accel/proc.c
@@ -39,3 +39,5 @@ omp_get_num_procs (void)
 {
   return gomp_icv (false)->nthreads_var;
 }
+
+ialias (omp_get_num_procs)
--
2.8.1

Fwd: [PATCH, GCC, Vect] Fix costing for vector shifts

[Sudakshina Das]

Hi

While looking at the vectorization for following example, we realized 
that even though vectorizable_shift function was distinguishing vector 
shifted by vector from vector shifted by scalar, while modeling the cost 
it would always add the cost of building a vector constant despite not 
needing it for vector shifted by scalar.

This patch fixes this by using scalar_shift_arg to determine whether we 
need to build a vector for the second operand or not. This reduces 
prologue cost as shown in the test.

Build and regression tests pass on aarch64-none-elf and 
x86_64-pc-linux-gnu-gcc. This gives a 3.42% boost to 525.x264_r in 
Spec2017 for AArch64.

gcc/ChangeLog:

2019-xx-xx  Sudakshina Das  
Richard Sandiford  

* tree-vect-stmt.c (vectorizable_shift): Condition ndts for
vect_model_simple_cost call on scalar_shift_arg.

gcc/testsuite/ChangeLog:

2019-xx-xx  Sudakshina Das  

* gcc.dg/vect/vect-shift-5.c: New test.

Is this ok for trunk?

Thanks
Sudi

diff --git a/gcc/testsuite/gcc.dg/vect/vect-shift-5.c b/gcc/testsuite/gcc.dg/vect/vect-shift-5.c
new file mode 100644
index 000..c1fd4f2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-shift-5.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_shift } */
+/* { dg-require-effective-target vect_int } */
+
+typedef unsigned int uint32_t;
+typedef short unsigned int uint16_t;
+
+int foo (uint32_t arr[4][4])
+{
+  int sum = 0;
+  for(int i = 0; i < 4; i++)
+{
+  sum += ((arr[0][i] >> 10) * 20) + ((arr[1][i] >> 11) & 53)
+	 + ((arr[2][i] >> 12) * 7)  + ((arr[3][i] >> 13) ^ 43);
+}
+return (((uint16_t)sum) + ((uint32_t)sum >> 16)) >> 1;
+}
+
+/* { dg-final { scan-tree-dump {vectorizable_shift ===[\n\r][^\n]*prologue_cost = 0} "vect" } } */
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 2cb6b15..396ff15 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -5764,7 +5764,8 @@ vectorizable_shift (stmt_vec_info stmt_info, gimple_stmt_iterator *gsi,
 {
   STMT_VINFO_TYPE (stmt_info) = shift_vec_info_type;
   DUMP_VECT_SCOPE ("vectorizable_shift");
-  vect_model_simple_cost (stmt_info, ncopies, dt, ndts, slp_node, cost_vec);
+  vect_model_simple_cost (stmt_info, ncopies, dt,
+			  scalar_shift_arg ? 1 : ndts, slp_node, cost_vec);
   return true;
 }
 

Re: libgo patch committed: Always mark assembly file as non-executable stack

[Rainer Orth]

I Ian,

> This libgo patch arranges for go-context.S to always be marked as
> using a non-executable stack.  This is not required for all targets,
> but should do little harm.  Bootstrapped on x86_64-pc-linux-gnu.
> Committed to mainline.

unfortunately, it does, breaking bootstrap on Solaris/SPARC and x86 with
the native assembler:

* Solaris/SPARC with as:

/usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: invalid character (0x40)
/usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: quoted-string operand 
required
/usr/ccs/bin/as: "/var/tmp//ccSl12Nb.s", line 7: error: statement syntax
make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1

* Solaris/x86 with as:

Assembler:
"/vol/gcc/src/hg/trunk/local/libgo/runtime/go-context.S", line 74 : 
Syntax error
Near line: " .section .note.GNU-stack,"",@progbits"
make[4]: *** [Makefile:1433: runtime/go-context.lo] Error 1

Rainer

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

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

[Marc Glisse]

On Fri, 6 Dec 2019, Richard Biener wrote:


Although that will increase the code size. In case, we could still have both a
nop_convert and a strip_nop predicates. Just thinking:


We should measure it, yes, I hope it won't be too bad ;)  In theory
making genmatch emitted code more like a graph rather than a tree
(with shared leafs) might save us a bit here.


Indeed, it isn't worth hacking this specific case. If we really want those 
savings, making it automatic at a higher level is the right way to go.



On Fri, 6 Dec 2019, Richard Biener wrote:


@@ -1684,7 +1681,7 @@ (define_operator_list COND_TERNARY
/* For equality, this is also true with wrapping overflow.  */
(for op (eq ne)
 (simplify
-  (op:c (nop_convert@3 (plus:c@2 @0 (convert1? @1))) (convert2? @1))
+  (op:c (nop_convert?@3 (plus:c@2 @0 (convert1? @1))) (convert2? @1))
  (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
   && (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
   || TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))


Possible future clean-up: those convert1 and convert2 have (strange) 
associated tree_nop_conversion_p below and look like candidates to become 
nop_convert.



@@ -2159,25 +2156,25 @@ (define_operator_list COND_TERNARY
  /* A - (A +- B)   -> -+ B */
  /* A +- (B -+ A)  ->  +- B */
  (simplify
-   (minus (nop_convert (plus:c (nop_convert @0) @1)) @0)
+   (minus (nop_convert1? (plus:c (nop_convert2? @0) @1)) @0)
   (view_convert @1))


I was wondering if we could use nop_convert for both (instead of 
nop_convert1 and 2), but for constants that wouldn't work, so this looks 
good.


--
Marc Glisse

Re: Ping Re: Fix libdecnumber handling of non-canonical BID significands (PR middle-end/91226)

[Richard Sandiford]

Joseph Myers  writes:
> Ping.  This patch 
>  is pending 
> review.

Like you say, it seems we no longer have a maintainer for this,
and I wonder how many people other than you understand it well
enough to do a meaningful technical review.

Having never worked with decimal flats, I personally can't contribute
anything useful here, but I guess from the delay that no-one else feels
they can either.  So IMO we should just go with the patch if you're
confident it's correct.

On that basis: OK by rubber stamp.

Thanks,
Richard

Re: [PATCH v2 2/2][ARM] Improve max_cond_insns setting for Cortex cores

[Christophe Lyon]

On Fri, 6 Dec 2019 at 11:47, Wilco Dijkstra  wrote:
>
> Hi Christophe,
>
> > This patch (r278968) is causing regressions when building GCC
> > --target arm-none-linux-gnueabihf
> > --with-mode thumb
> > --with-cpu cortex-a57
> > --with-fpu crypto-neon-fp-armv8
> > because the assembler (gas version 2.33.1) complains:
> > /ccc7z5eW.s:4267: IT blocks containing more than one conditional
> > instruction are performance deprecated in ARMv8-A and ARMv8-R
> >
> > I guess that's related to what you say about -mrestrict-it ?
>
> Yes it looks like that unnecessary warning hasn't been silenced in latest 
> binutils,
> but it should be easy to turn off.
>
Do you mean that binutils should be "fixed" not to emit this warning
(since you say it's unnecessary), or GCC made not to emit the
offending sequence?


> Cheers,
> Wilco

[committed][testsuite][aarch64] type_redef_11.c: Update expected diagnostics.

[Christophe Lyon]

Hi,

After the fix for PR c/36941 and PR c/88827 (r278976), this test emits
a different error message and needs an update.

I've committed this as r279039.

Christophe

2019-12-06  Christophe Lyon  

PR c/36941
PR c/88827
* gcc.target/aarch64/sve/acle/general-c/type_redef_11.c: Update
expected diagnostics.

Index: gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/type_redef_11.c
===
--- gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/type_redef_11.c
(revision 279038)
+++ gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/type_redef_11.c
(revision 279039)
@@ -8,5 +8,5 @@
 void
 f (svint8x2_t *a, struct svint8x2_t *b)
 {
-  *a = *b; /* { dg-error {dereferencing pointer to incomplete type} } */
+  *a = *b; /* { dg-error {invalid use of undefined type} } */
 }

Re: [PATCH 09/49] gimple const-correctness fixes

[Richard Biener]

On Sat, Nov 16, 2019 at 2:20 AM David Malcolm  wrote:
>
> This patch converts various "gimple *" to "const gimple *" and similar
> fixes for gimple subclasses, adding is_a_helper for gimple subclasses
> to support the const form of as_a, and adding a few "const" overloads
> of accessors.
>
> This is enough to make pp_gimple_stmt_1's stmt const.

Hum.  Can't the const is-a variants be somehow magically implemented
generally?  If something is a T then it is also a const T, no?  I guess
if something is a const T it isn't a T though?

Richard.

> gcc/ChangeLog:
> * gimple-predict.h (gimple_predict_predictor): Make "gs" param
> const.
> (gimple_predict_outcome): Likewise.
> * gimple-pretty-print.c (do_niy): Likewise.
> (dump_unary_rhs): Likewise.
> (dump_binary_rhs): Likewise.
> (dump_ternary_rhs): Likewise.
> (dump_gimple_assign): Likewise.
> (dump_gimple_return): Likewise.
> (dump_gimple_call_args): Likewise.
> (pp_points_to_solution): Make "pt" param const.
> (dump_gimple_call): Make "gs" param const.
> (dump_gimple_switch): Likewise.
> (dump_gimple_cond): Likewise.
> (dump_gimple_label): Likewise.
> (dump_gimple_goto): Likewise.
> (dump_gimple_bind): Likewise.
> (dump_gimple_try): Likewise.
> (dump_gimple_catch): Likewise.
> (dump_gimple_eh_filter): Likewise.
> (dump_gimple_eh_must_not_throw): Likewise.
> (dump_gimple_eh_else): Likewise.
> (dump_gimple_resx): Likewise.
> (dump_gimple_eh_dispatch): Likewise.
> (dump_gimple_debug): Likewise.
> (dump_gimple_omp_for): Likewise.
> (dump_gimple_omp_continue): Likewise.
> (dump_gimple_omp_single): Likewise.
> (dump_gimple_omp_taskgroup): Likewise.
> (dump_gimple_omp_target): Likewise.
> (dump_gimple_omp_teams): Likewise.
> (dump_gimple_omp_sections): Likewise.
> (dump_gimple_omp_block): Likewise.
> (dump_gimple_omp_critical): Likewise.
> (dump_gimple_omp_ordered): Likewise.
> (dump_gimple_omp_scan): Likewise.
> (dump_gimple_omp_return): Likewise.
> (dump_gimple_transaction): Likewise.
> (dump_gimple_asm): Likewise.
> (dump_gimple_phi): Make "phi" param const.
> (dump_gimple_omp_parallel): Make "gs" param const.
> (dump_gimple_omp_task): Likewise.
> (dump_gimple_omp_atomic_load): Likewise.
> (dump_gimple_omp_atomic_store): Likewise.
> (dump_gimple_mem_ops): Likewise.
> (pp_gimple_stmt_1): Likewise.  Add "const" to the various as_a <>
> casts throughout.
> * gimple-pretty-print.h (gimple_stmt_1): Make gimple * param const.
> * gimple.h (is_a_helper ::test): New.
> (is_a_helper ::test): New.
> (is_a_helper ::test): New.
> (is_a_helper ::test): New.
> (is_a_helper ::test): New.
> (is_a_helper ::test): New.
> (is_a_helper ::test): New.
> (is_a_helper ::test): New.
> (gimple_call_tail_p): Make param const.
> (gimple_call_return_slot_opt_p): Likewise.
> (gimple_call_va_arg_pack_p): Likewise.
> (gimple_call_use_set): Add const overload.
> (gimple_call_clobber_set): Likewise.
> (gimple_has_lhs): Make param const.
> (gimple_bind_body): Likewise.
> (gimple_catch_handler): Likewise.
> (gimple_eh_filter_failure): Likewise.
> (gimple_eh_must_not_throw_fndecl): Likewise.
> (gimple_eh_else_n_body): Likewise.
> (gimple_eh_else_e_body): Likewise.
> (gimple_try_eval): Likewise.
> (gimple_try_cleanup): Likewise.
> (gimple_phi_arg): Add const overload.
> (gimple_phi_arg_def): Make param const.
> (gimple_phi_arg_edge): Likewise.
> (gimple_phi_arg_location): Likewise.
> (gimple_phi_arg_has_location): Likewise.
> (gimple_debug_bind_get_var): Likewise.
> (gimple_debug_bind_get_value): Likewise.
> (gimple_debug_source_bind_get_var): Likewise.
> (gimple_debug_source_bind_get_value): Likewise.
> (gimple_omp_body): Likewise.
> (gimple_omp_for_collapse): Likewise.
> (gimple_omp_for_pre_body): Likewise.
> (gimple_transaction_body): Likewise.
> * tree-eh.c (lookup_stmt_eh_lp_fn): Make param "t" const.
> (lookup_stmt_eh_lp): Likewise.
> * tree-eh.h (lookup_stmt_eh_lp_fn): Make param const.
> (lookup_stmt_eh_lp): Likewise.
> * tree-ssa-alias.h (pt_solution_empty_p): Make param const.
> * tree-ssa-structalias.c (pt_solution_empty_p): Likewise.
> ---
>  gcc/gimple-predict.h   |   4 +-
>  gcc/gimple-pretty-print.c  | 159 
> +++--
>  gcc/gimple-pretty-print.h  |   3 +-
>  gcc/gimple.h   | 156 ++--
>  

Re: [PATCH v2 2/2][ARM] Improve max_cond_insns setting for Cortex cores

[Wilco Dijkstra]

Hi Christophe,

> This patch (r278968) is causing regressions when building GCC
> --target arm-none-linux-gnueabihf
> --with-mode thumb
> --with-cpu cortex-a57
> --with-fpu crypto-neon-fp-armv8
> because the assembler (gas version 2.33.1) complains:
> /ccc7z5eW.s:4267: IT blocks containing more than one conditional
> instruction are performance deprecated in ARMv8-A and ARMv8-R
>
> I guess that's related to what you say about -mrestrict-it ?

Yes it looks like that unnecessary warning hasn't been silenced in latest 
binutils,
but it should be easy to turn off.

Cheers,
Wilco

Re: [PATCH v2 2/2][ARM] Improve max_cond_insns setting for Cortex cores

[Christophe Lyon]

On Tue, 3 Dec 2019 at 14:45, Wilco Dijkstra  wrote:
>
> Hi,
>
> Part 2, split off from 
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00399.html
>
> To enable cores to use the correct max_cond_insns setting, use the 
> core-specific
> tuning when a CPU/tune is selected unless -mrestrict-it is explicitly set.
>

Hi,

This patch (r278968) is causing regressions when building GCC
--target arm-none-linux-gnueabihf
--with-mode thumb
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8
because the assembler (gas version 2.33.1) complains:
/ccc7z5eW.s:4267: IT blocks containing more than one conditional
instruction are performance deprecated in ARMv8-A and ARMv8-R

I guess that's related to what you say about -mrestrict-it ?

Christophe

> On Cortex-A57 this gives 1.1% performance gain on SPECINT2006 as well as a
> 0.4% codesize reduction.
>
> Bootstrapped on armhf. OK for commit?
>
> ChangeLog:
>
> 2019-12-03  Wilco Dijkstra  
>
> * config/arm/arm.c (arm_option_override_internal):
> Use max_cond_insns from CPU tuning unless -mrestrict-it is used.
> --
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 
> daebe76352d62ad94556762b4e3bc3d0532ad411..5ed9046988996e56f754c5588e4d25d5ecdd6b03
>  100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -3041,6 +3041,11 @@ arm_option_override_internal (struct gcc_options *opts,
>if (!TARGET_THUMB2_P (opts->x_target_flags) || !arm_arch_notm)
>  opts->x_arm_restrict_it = 0;
>
> +  /* Use the IT size from CPU specific tuning unless -mrestrict-it is used.  
> */
> +  if (!opts_set->x_arm_restrict_it
> +  && (opts_set->x_arm_cpu_string || opts_set->x_arm_tune_string))
> +opts->x_arm_restrict_it = 0;
> +
>/* Enable -munaligned-access by default for
>   - all ARMv6 architecture-based processors when compiling for a 32-bit 
> ISA
>   i.e. Thumb2 and ARM state only.

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

[Richard Biener]

On Fri, 6 Dec 2019, Richard Biener wrote:

> On Fri, 6 Dec 2019, Marc Glisse wrote:
> 
> > On Fri, 6 Dec 2019, Richard Biener wrote:
> > 
> > >>> nop_convert sees that 'a' comes from a conversion, and only returns d
> > >>> (unlike 'convert?' which would try both a and d).
> > 
> > Maybe I should have formulated it as: nop_convert works kind of like a
> > strip_nops.
> > 
> > >> If use gets more and more we can make nop_convert a first class citizen 
> > >> and
> > >> allow a? Variant.
> > 
> > One reason I did not specifically push for that is that nop_convert is 
> > seldom
> > the right condition. It is convenient because it is usually easy enough to
> > check that it is correct, but in most cases one of narrowing / 
> > zero-extension
> > / sign-extension also works. Still, it is better to handle just NOPs than no
> > conversion at all, so I guess making that easy is still good.
> 
> In my view nop_convert is useful to avoid cluttering the code with
> (if (tree_nop_conversion_p ...)  checks that are even redundant
> when a (convert? ... is stripped away.
> 
> > > Like the attached (need to adjust docs & rename some functions still)
> > > which generalizes
> > > [digit]? parsing.  This allows you to write (nop_convert? ...)
> > 
> > I guess once this is in, we should replace all (most?) 'nop_convert' with
> > 'nop_convert?' (and possibly a digit in some places) and remove the last
> > alternative in the definition of nop_convert.
> 
> Yes, that was my thinking.
> 
> > Although that will increase the code size. In case, we could still have 
> > both a
> > nop_convert and a strip_nop predicates. Just thinking:
> 
> We should measure it, yes, I hope it won't be too bad ;)  In theory
> making genmatch emitted code more like a graph rather than a tree
> (with shared leafs) might save us a bit here.
> 
> > (match (nop_convert @0)
> >  (convert @0)
> >  (if (tree_nop_conversion_p (type, TREE_TYPE (@0)
> > (match (nop_convert @0)
> >  (view_convert @0)
> >  (if (VECTOR_TYPE_P (type) && VECTOR_TYPE_P (TREE_TYPE (@0))
> >   && known_eq (TYPE_VECTOR_SUBPARTS (type),
> >TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0)))
> >   && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE
> >   && (@0))
> > 
> > (match (strip_nops @0)
> >  (nop_convert? @0))
> > 
> > but that relies on the fact that when there is an optional operation, the
> > machinery first tries with the operation, and then without, the order 
> > matters.
> > Maybe being explicit on the priorities is safer
> > 
> > (match (strip_nops @0)
> >  (nop_convert @0))
> > (match (strip_nops @0)
> >  @0)
> 
> Yeah, I don't think the above complexity is worth it.
> 
> > > It works (generated files are unchanged), so I guess I'll push it
> > > after polishing.
> > >
> > > It also extends the 1/2/3 grouping to be able to group like (plus
> > > (nop_convert2? @0) (convert2? @1))
> > > so either both will be present or none (meaning that when grouping you
> > > can choose the "cheaper"
> > > test for one in case you know the conversions will be the same).
> > 
> > Nice.
> 
> r279037.

And testing the following now, replacing all nop_converts.

> wc -l gimple-match.c.orig 
117182 gimple-match.c.orig
> wc -l gimple-match.c
119052 gimple-match.c

so impact is minimal.

Richard.

2019-12-06  Richard Biener  

* match.pd (nop_convert): Remove empty match.  Use nop_convert?
everywhere.

Index: gcc/match.pd
===
--- gcc/match.pd(revision 279037)
+++ gcc/match.pd(working copy)
@@ -98,8 +98,8 @@ (define_operator_list UNCOND_TERNARY
 (define_operator_list COND_TERNARY
   IFN_COND_FMA IFN_COND_FMS IFN_COND_FNMA IFN_COND_FNMS)
 
-/* As opposed to convert?, this still creates a single pattern, so
-   it is not a suitable replacement for convert? in all cases.  */
+/* With nop_convert? combine convert? and view_convert? in one pattern
+   plus conditionalize on tree_nop_conversion_p conversions.  */
 (match (nop_convert @0)
  (convert @0)
  (if (tree_nop_conversion_p (type, TREE_TYPE (@0)
@@ -109,9 +109,6 @@ (define_operator_list COND_TERNARY
   && known_eq (TYPE_VECTOR_SUBPARTS (type),
   TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0)))
   && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE 
(@0))
-/* This one has to be last, or it shadows the others.  */
-(match (nop_convert @0)
- @0)
 
 /* Transform likes of (char) ABS_EXPR <(int) x> into (char) ABSU_EXPR 
ABSU_EXPR returns unsigned absolute value of the operand and the operand
@@ -1428,7 +1425,7 @@ (define_operator_list COND_TERNARY
 
 /* Convert - (~A) to A + 1.  */
 (simplify
- (negate (nop_convert (bit_not @0)))
+ (negate (nop_convert? (bit_not @0)))
  (plus (view_convert @0) { build_each_one_cst (type); }))
 
 /* Convert ~ (A - 1) or ~ (A + -1) to -A.  */
@@ -1455,7 +1452,7 @@ (define_operator_list COND_TERNARY
 
 /* Otherwise prefer ~(X ^ Y) to ~X ^ Y 

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

[Richard Biener]

On Fri, 6 Dec 2019, Marc Glisse wrote:

> On Fri, 6 Dec 2019, Richard Biener wrote:
> 
> >>> nop_convert sees that 'a' comes from a conversion, and only returns d
> >>> (unlike 'convert?' which would try both a and d).
> 
> Maybe I should have formulated it as: nop_convert works kind of like a
> strip_nops.
> 
> >> If use gets more and more we can make nop_convert a first class citizen and
> >> allow a? Variant.
> 
> One reason I did not specifically push for that is that nop_convert is seldom
> the right condition. It is convenient because it is usually easy enough to
> check that it is correct, but in most cases one of narrowing / zero-extension
> / sign-extension also works. Still, it is better to handle just NOPs than no
> conversion at all, so I guess making that easy is still good.

In my view nop_convert is useful to avoid cluttering the code with
(if (tree_nop_conversion_p ...)  checks that are even redundant
when a (convert? ... is stripped away.

> > Like the attached (need to adjust docs & rename some functions still)
> > which generalizes
> > [digit]? parsing.  This allows you to write (nop_convert? ...)
> 
> I guess once this is in, we should replace all (most?) 'nop_convert' with
> 'nop_convert?' (and possibly a digit in some places) and remove the last
> alternative in the definition of nop_convert.

Yes, that was my thinking.

> Although that will increase the code size. In case, we could still have both a
> nop_convert and a strip_nop predicates. Just thinking:

We should measure it, yes, I hope it won't be too bad ;)  In theory
making genmatch emitted code more like a graph rather than a tree
(with shared leafs) might save us a bit here.

> (match (nop_convert @0)
>  (convert @0)
>  (if (tree_nop_conversion_p (type, TREE_TYPE (@0)
> (match (nop_convert @0)
>  (view_convert @0)
>  (if (VECTOR_TYPE_P (type) && VECTOR_TYPE_P (TREE_TYPE (@0))
>   && known_eq (TYPE_VECTOR_SUBPARTS (type),
>TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0)))
>   && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE
>   && (@0))
> 
> (match (strip_nops @0)
>  (nop_convert? @0))
> 
> but that relies on the fact that when there is an optional operation, the
> machinery first tries with the operation, and then without, the order matters.
> Maybe being explicit on the priorities is safer
> 
> (match (strip_nops @0)
>  (nop_convert @0))
> (match (strip_nops @0)
>  @0)

Yeah, I don't think the above complexity is worth it.

> > It works (generated files are unchanged), so I guess I'll push it
> > after polishing.
> >
> > It also extends the 1/2/3 grouping to be able to group like (plus
> > (nop_convert2? @0) (convert2? @1))
> > so either both will be present or none (meaning that when grouping you
> > can choose the "cheaper"
> > test for one in case you know the conversions will be the same).
> 
> Nice.

r279037.

Richard.

Re: [PATCH][AArch64] Enable CLI for Armv8.6-a: armv8.6-a, i8mm and bf16

[Richard Sandiford]

Dennis Zhang  writes:
> 2019-12-04  Dennis Zhang  
>
>   * config/aarch64/aarch64-arches.def (armv8.6-a): New.
>   * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
>   __ARM_FEATURE_MATMUL_INT8, __ARM_FEATURE_BF16_VECTOR_ARITHMETIC and
>   __ARM_FEATURE_BF16_SCALAR_ARITHMETIC when enabled.
>   * config/aarch64/aarch64-option-extensions.def (i8mm, bf16): New.
>   (fp): Disabling fp also disables i8mm and bf16.
>   (simd): Disabling simd also disables i8mm.
>   * config/aarch64/aarch64.h (AARCH64_FL_V8_6): New macro.
>   (AARCH64_FL_I8MM, AARCH64_FL_BF16, AARCH64_FL_FOR_ARCH8_6): Likewise.
>   (AARCH64_ISA_V8_6, AARCH64_ISA_I8MM, AARCH64_ISA_BF16): Likewise.
>   (TARGET_I8MM, TARGET_BF16_FP, TARGET_BF16_SIMD): Likewise.
>   * doc/invoke.texi (armv8.6-a, i8mm, bf16): Document new options. Add
>   a new table to list permissible values for ARCH.
>
> gcc/testsuite/ChangeLog:
>
> 2019-12-04  Dennis Zhang  
>
>   * gcc.target/aarch64/pragma_cpp_predefs_2.c: Add tests for i8mm
>   and bf16 features.

Thanks for the update, looks great.  A couple of comments below.

> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index d165f31a865..1192e8f4b06 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -16050,25 +16050,22 @@ Specify the name of the target architecture and, 
> optionally, one or
>  more feature modifiers.  This option has the form
>  @option{-march=@var{arch}@r{@{}+@r{[}no@r{]}@var{feature}@r{@}*}}.
>  
> -The permissible values for @var{arch} are @samp{armv8-a},
> -@samp{armv8.1-a}, @samp{armv8.2-a}, @samp{armv8.3-a}, @samp{armv8.4-a},
> -@samp{armv8.5-a} or @var{native}.
> -
> -The value @samp{armv8.5-a} implies @samp{armv8.4-a} and enables compiler
> -support for the ARMv8.5-A architecture extensions.
> -
> -The value @samp{armv8.4-a} implies @samp{armv8.3-a} and enables compiler
> -support for the ARMv8.4-A architecture extensions.
> -
> -The value @samp{armv8.3-a} implies @samp{armv8.2-a} and enables compiler
> -support for the ARMv8.3-A architecture extensions.
> -
> -The value @samp{armv8.2-a} implies @samp{armv8.1-a} and enables compiler
> -support for the ARMv8.2-A architecture extensions.
> -
> -The value @samp{armv8.1-a} implies @samp{armv8-a} and enables compiler
> -support for the ARMv8.1-A architecture extension.  In particular, it
> -enables the @samp{+crc}, @samp{+lse}, and @samp{+rdma} features.
> +The table below summarizes the permissible values for @var{arch}
> +and the features that they enable by default:
> +
> +@multitable @columnfractions 0.20 0.20 0.60
> +@headitem @var{arch} value @tab Architecture @tab Includes by default

We should have an armv8-a entry here, something like:

@item @samp{armv8-a} @tab Armv8-A @tab @samp{+fp}, @samp{+simd}

> +@item @samp{armv8.1-a} @tab Armv8.1-A
> +@tab @samp{armv8-a}, @samp{+crc}, @samp{+lse}, @samp{+rdma}
> +@item @samp{armv8.2-a} @tab Armv8.2-A @tab @samp{armv8.1-a}
> +@item @samp{armv8.3-a} @tab Armv8.3-A @tab @samp{armv8.2-a}
> +@item @samp{armv8.4-a} @tab Armv8.4-A
> +@tab @samp{armv8.3-a}, @samp{+fp16fml}, @samp{+dotprod}
> +@item @samp{armv8.5-a} @tab Armv8.5-A
> +@tab @samp{armv8.4-a}, @samp{+sb}, @samp{+ssbs}, @samp{+predres}
> +@item @samp{armv8.6-a} @tab Armv8.6-A
> +@tab @samp{armv8.5-a}, @samp{+bf16}, @samp{+i8mm}
> +@end multitable

I should have tried a proof of concept of this before suggesting it, sorry.
Trying the patch locally I get:

gcc.pod around line 18643: You can't have =items (as at line 18649) unless the 
first thing after the =over is an =item
POD document had syntax errors at /usr/bin/pod2man line 71.
Makefile:3363: recipe for target 'doc/gcc.1' failed
make: [doc/gcc.1] Error 1 (ignored)

(Odd that this is an ignored error, since we end up with an empty man page.)

I've posted a texi2pod.pl patch for that:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00407.html

However, even with that patch, the script needs the full table row to be
on a single line, so I think we need to do that and live with the long lines.

> [...]
> diff --git a/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_2.c 
> b/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_2.c
> index 608b89d19ce..5ae39bc6cf0 100644
> --- a/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/pragma_cpp_predefs_2.c
> @@ -13,6 +13,92 @@
>  #error "__ARM_FEATURE_TME is defined but should not be!"
>  #endif
>  
> +/* Test Armv8.6-a features.  */
> +
> +#pragma GCC push_options
> +#pragma GCC target ("arch=armv8-a")

These two pragmas should be at the beginning of the file, so that we
start with base armv8-a for all the tests.

Thanks,
Richard

Fix @multitable handling in texi2pod.pl

[Richard Sandiford]

While trying out Dennis's Armv8.6-A patch, I noticed that texi2pod.pl
didn't handle the new @multitable correctly.  There were two problems:

(1) @multitables nested in other @tables inherited the @item type from
the enclosing @table.  Since the new @multitable is in a @table @samp,
we applied @samp markup to the @multitable @items.  This in turn
meant that it captured the @tab separator in the @item markup.

Fixed by pushing an empty item code onto the stack.

(2) We didn't handle @headitem.  Fixed by enclosing it in italics,
like we do for section headings.  This causes it to be underlined
in the man output.

Tested by making sure that it doesn't change the current gcc.pod output,
but fixes the problems mentioned above when the new @multitable is added.
OK to install?

Richard


2019-12-05  Richard Sandiford  

contrib/
* texi2pod.pl: Handle @headitems in @multitables, printing them
in italics.  Push an empty item code onto the stack.

Index: contrib/texi2pod.pl
===
--- contrib/texi2pod.pl 2019-03-08 18:14:23.345019203 +
+++ contrib/texi2pod.pl 2019-12-06 10:15:24.968809478 +
@@ -164,6 +164,7 @@ while(<$inf>) {
$ic = pop @icstack;
} elsif ($ended eq "multitable") {
$_ = "\n=back\n";
+   $ic = pop @icstack;
} else {
die "unknown command \@end $ended at line $.\n";
}
@@ -288,7 +289,9 @@ while(<$inf>) {
 
 /^\@multitable\s.*/ and do {
push @endwstack, $endw;
+   push @icstack, $ic;
$endw = "multitable";
+   $ic = "";
$_ = "\n=over 4\n";
 };
 
@@ -312,11 +315,13 @@ while(<$inf>) {
$_ = "";# need a paragraph break
 };
 
-/^\@item\s+(.*\S)\s*$/ and $endw eq "multitable" and do {
+/^\@(headitem|item)\s+(.*\S)\s*$/ and $endw eq "multitable" and do {
@columns = ();
-   for $column (split (/\s*\@tab\s*/, $1)) {
+   $item = $1;
+   for $column (split (/\s*\@tab\s*/, $2)) {
# @strong{...} is used a @headitem work-alike
$column =~ s/^\@strong\{(.*)\}$/$1/;
+   $column = "I<$column>" if $item eq "headitem";
push @columns, $column;
}
$_ = "\n=item ".join (" : ", @columns)."\n";

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

[Marc Glisse]

On Fri, 6 Dec 2019, Richard Biener wrote:


nop_convert sees that 'a' comes from a conversion, and only returns d
(unlike 'convert?' which would try both a and d).


Maybe I should have formulated it as: nop_convert works kind of like a 
strip_nops.



If use gets more and more we can make nop_convert a first class citizen and 
allow a? Variant.


One reason I did not specifically push for that is that nop_convert is 
seldom the right condition. It is convenient because it is usually easy 
enough to check that it is correct, but in most cases one of narrowing / 
zero-extension / sign-extension also works. Still, it is better to handle 
just NOPs than no conversion at all, so I guess making that easy is still 
good.



Like the attached (need to adjust docs & rename some functions still)
which generalizes
[digit]? parsing.  This allows you to write (nop_convert? ...)


I guess once this is in, we should replace all (most?) 'nop_convert' with 
'nop_convert?' (and possibly a digit in some places) and remove the last 
alternative in the definition of nop_convert.


Although that will increase the code size. In case, we could still have 
both a nop_convert and a strip_nop predicates. Just thinking:


(match (nop_convert @0)
 (convert @0)
 (if (tree_nop_conversion_p (type, TREE_TYPE (@0)
(match (nop_convert @0)
 (view_convert @0)
 (if (VECTOR_TYPE_P (type) && VECTOR_TYPE_P (TREE_TYPE (@0))
  && known_eq (TYPE_VECTOR_SUBPARTS (type),
   TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0)))
  && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE (@0))

(match (strip_nops @0)
 (nop_convert? @0))

but that relies on the fact that when there is an optional operation, the 
machinery first tries with the operation, and then without, the order 
matters. Maybe being explicit on the priorities is safer


(match (strip_nops @0)
 (nop_convert @0))
(match (strip_nops @0)
 @0)


It works (generated files are unchanged), so I guess I'll push it
after polishing.

It also extends the 1/2/3 grouping to be able to group like (plus
(nop_convert2? @0) (convert2? @1))
so either both will be present or none (meaning that when grouping you
can choose the "cheaper"
test for one in case you know the conversions will be the same).


Nice.

--
Marc Glisse

Re: Avoid quadratic behaviour in prune_runtime_alias_test_list

[Richard Biener]

On Fri, Dec 6, 2019 at 9:36 AM Richard Sandiford
 wrote:
>
> prune_runtime_alias_test_list used ordered_remove to remove a merged
> alias pair, which made the function quadratic when many aliases could
> be removed.
>
> I had a testcase in which these memmoves accounted for an impressive
> 85% of compile time.  The fact that we had so many probably shows
> a deeper problem, but still, it's easy to remove as we go.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

OK.

> Richard
>
>
> 2019-12-06  Richard Sandiford  
>
> gcc/
> * tree-data-ref.c (prune_runtime_alias_test_list): Exit early
> for empty vectors.  Avoid using ordered_remove and instead
> shuffle the vector as we go.
>
> Index: gcc/tree-data-ref.c
> ===
> --- gcc/tree-data-ref.c 2019-11-18 15:36:04.873884873 +
> +++ gcc/tree-data-ref.c 2019-12-06 08:35:38.153410087 +
> @@ -1535,6 +1535,9 @@ dump_alias_pair (dr_with_seg_len_pair_t
>  prune_runtime_alias_test_list (vec *alias_pairs,
>poly_uint64)
>  {
> +  if (alias_pairs->is_empty ())
> +return;
> +
>/* Canonicalize each pair so that the base components are ordered wrt
>   data_ref_compare_tree.  This allows the loop below to merge more
>   cases.  */
> @@ -1565,10 +1568,11 @@ prune_runtime_alias_test_list (vec
>/* Scan the sorted dr pairs and check if we can combine alias checks
>   of two neighboring dr pairs.  */
> +  unsigned int last = 0;
>for (i = 1; i < alias_pairs->length (); ++i)
>  {
>/* Deal with two ddrs (dr_a1, dr_b1) and (dr_a2, dr_b2).  */
> -  dr_with_seg_len_pair_t *alias_pair1 = &(*alias_pairs)[i - 1];
> +  dr_with_seg_len_pair_t *alias_pair1 = &(*alias_pairs)[last];
>dr_with_seg_len_pair_t *alias_pair2 = &(*alias_pairs)[i];
>
>dr_with_seg_len *dr_a1 = _pair1->first;
> @@ -1584,10 +1588,15 @@ prune_runtime_alias_test_list (vec  DR_REF (dr_a1->dr), DR_REF (dr_b1->dr),
>  DR_REF (dr_a2->dr), DR_REF (dr_b2->dr));
>   alias_pair1->flags |= alias_pair2->flags;
> - alias_pairs->ordered_remove (i--);
>   continue;
> }
>
> +  /* Assume that we won't be able to merge the pairs, then correct
> +if we do.  */
> +  last += 1;
> +  if (last != i)
> +   (*alias_pairs)[last] = (*alias_pairs)[i];
> +
>if (*dr_a1 == *dr_a2 || *dr_b1 == *dr_b2)
> {
>   /* We consider the case that DR_B1 and DR_B2 are same memrefs,
> @@ -1695,10 +1704,10 @@ prune_runtime_alias_test_list (vec  DR_REF (dr_a1->dr), DR_REF (dr_b1->dr),
>  DR_REF (dr_a2->dr), DR_REF (dr_b2->dr));
>   alias_pair1->flags |= alias_pair2->flags;
> - alias_pairs->ordered_remove (i);
> - i--;
> + last -= 1;
> }
>  }
> +  alias_pairs->truncate (last + 1);
>
>/* Try to restore the original dr_with_seg_len order within each
>   dr_with_seg_len_pair_t.  If we ended up combining swapped and

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

[Richard Biener]

On Fri, 6 Dec 2019, Richard Biener wrote:

> On Thu, Dec 5, 2019 at 4:16 PM Richard Biener  wrote:
> >
> > On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse 
> >  wrote:
> > >On Wed, 4 Dec 2019, Jakub Jelinek wrote:
> > >
> > >> --- gcc/match.pd.jj  2019-12-03 10:20:00.244913801 +0100
> > >> +++ gcc/match.pd 2019-12-03 13:36:01.084435697 +0100
> > >> @@ -2159,20 +2159,26 @@ (define_operator_list COND_TERNARY
> > >>   /* A - (A +- B)   -> -+ B */
> > >>   /* A +- (B -+ A)  ->  +- B */
> > >>   (simplify
> > >> -(minus (plus:c @0 @1) @0)
> > >> -@1)
> > >> +   (minus (nop_convert (plus:c (nop_convert @0) @1)) @0)
> > >> +   (view_convert @1))
> > >
> > >I know I introduced nop_convert, and it can be convenient, but IIRC it
> > >also has some limitations.
> > >
> > >int f(int b,unsigned c){
> > >   int a=c;
> > >   int d=a+b;
> > >   return d-a;
> > >}
> > >int g(int a, int b){
> > >   int d=(unsigned)a+b;
> > >   return d-a;
> > >}
> > >int h(int b,int a){
> > >   int d=a+b;
> > >   return d-a;
> > >}
> > >
> > >While g and h are properly optimized during forwprop1, f isn't, because
> > >
> > >nop_convert sees that 'a' comes from a conversion, and only returns d
> > >(unlike 'convert?' which would try both a and d).
> > >
> > >When inside nop_convert we have an operation, say (nop_convert (plus
> > >...)), there is no ambiguity, so we are fine. With just (nop_convert
> > >@0),
> > >less so.
> > >
> > >It happens that during EVRP, for some reason (different valuization
> > >function?), nop_convert does not match the conversion, and we do
> > >optimize
> > >f. But that almost looks like an accident.
> > >
> > >convert? with explicit checks would probably work better for the inner
> > >conversion, except that handling the vector view_convert case may
> > >become
> > >painful. I didn't think too hard about possible fancy tricks like a
> > >second
> > >nop_convert:
> > >
> > >(minus (nop_convert (plus:c (nop_convert @0) @1)) (nop_convert @0))
> >
> > If use gets more and more we can make nop_convert a first class citizen and 
> > allow a? Variant. Or handle all predicates as? Variant.
> 
> Like the attached (need to adjust docs & rename some functions still)
> which generalizes
> [digit]? parsing.  This allows you to write (nop_convert? ...)
> 
> It works (generated files are unchanged), so I guess I'll push it
> after polishing.
> 
> It also extends the 1/2/3 grouping to be able to group like (plus
> (nop_convert2? @0) (convert2? @1))
> so either both will be present or none (meaning that when grouping you
> can choose the "cheaper"
> test for one in case you know the conversions will be the same).

Like this.

Bootstrap on x86_64-unknown-linux-gnu running, tested by building
docs and comparing {gimple,generic}-match.c before/after the patch.

Richard.

2019-12-06  Richard Biener  

* genmatch.c (enum tree_code): Remove CONVERT{0,1,2} and
VIEW_CONVERT{0,1,2}.
(expr::opt_grp): Add and initialize.
(lower_opt_convert): Rename to ...
(lower_opt): ... and work on opt_grp, simply switching operations
from being optional to being present or not.
(has_opt_convert): Rename to ...
(has_opt): ... and adjust.
(parser::parse_operation): Return the optional opt_grp,
remove special-casing of conditional operations and more generally
parse [digit]'?'.
(parser::parse_expr): Stick on the parsed opt_grp and perform
rough verification.
(parser::parse_for): Remove now unnecessary code.
(main): Likewise.
* doc/match-and-simplify.texi: Mention ? now works on all
unary operations and also match predicates.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 279036)
+++ gcc/genmatch.c  (working copy)
@@ -224,12 +224,6 @@ output_line_directive (FILE *f, location
 #define DEFTREECODE(SYM, STRING, TYPE, NARGS)   SYM,
 enum tree_code {
 #include "tree.def"
-CONVERT0,
-CONVERT1,
-CONVERT2,
-VIEW_CONVERT0,
-VIEW_CONVERT1,
-VIEW_CONVERT2,
 MAX_TREE_CODES
 };
 #undef DEFTREECODE
@@ -703,11 +697,12 @@ public:
   expr (id_base *operation_, location_t loc, bool is_commutative_ = false)
 : operand (OP_EXPR, loc), operation (operation_),
   ops (vNULL), expr_type (NULL), is_commutative (is_commutative_),
-  is_generic (false), force_single_use (false) {}
+  is_generic (false), force_single_use (false), opt_grp (0) {}
   expr (expr *e)
 : operand (OP_EXPR, e->location), operation (e->operation),
   ops (vNULL), expr_type (e->expr_type), is_commutative 
(e->is_commutative),
-  is_generic (e->is_generic), force_single_use (e->force_single_use) {}
+  is_generic (e->is_generic), force_single_use (e->force_single_use),
+  opt_grp (e->opt_grp) {}
   void append_op (operand *op) { ops.safe_push (op); }
   /* The operator and its operands.  */
   id_base *operation;
@@ -722,6 +717,8 @@ 

Re: [PATCH] Some further match.pd optimizations with nop_convert (PR tree-optimization/92734)

[Richard Biener]

On Thu, Dec 5, 2019 at 4:16 PM Richard Biener  wrote:
>
> On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse  
> wrote:
> >On Wed, 4 Dec 2019, Jakub Jelinek wrote:
> >
> >> --- gcc/match.pd.jj  2019-12-03 10:20:00.244913801 +0100
> >> +++ gcc/match.pd 2019-12-03 13:36:01.084435697 +0100
> >> @@ -2159,20 +2159,26 @@ (define_operator_list COND_TERNARY
> >>   /* A - (A +- B)   -> -+ B */
> >>   /* A +- (B -+ A)  ->  +- B */
> >>   (simplify
> >> -(minus (plus:c @0 @1) @0)
> >> -@1)
> >> +   (minus (nop_convert (plus:c (nop_convert @0) @1)) @0)
> >> +   (view_convert @1))
> >
> >I know I introduced nop_convert, and it can be convenient, but IIRC it
> >also has some limitations.
> >
> >int f(int b,unsigned c){
> >   int a=c;
> >   int d=a+b;
> >   return d-a;
> >}
> >int g(int a, int b){
> >   int d=(unsigned)a+b;
> >   return d-a;
> >}
> >int h(int b,int a){
> >   int d=a+b;
> >   return d-a;
> >}
> >
> >While g and h are properly optimized during forwprop1, f isn't, because
> >
> >nop_convert sees that 'a' comes from a conversion, and only returns d
> >(unlike 'convert?' which would try both a and d).
> >
> >When inside nop_convert we have an operation, say (nop_convert (plus
> >...)), there is no ambiguity, so we are fine. With just (nop_convert
> >@0),
> >less so.
> >
> >It happens that during EVRP, for some reason (different valuization
> >function?), nop_convert does not match the conversion, and we do
> >optimize
> >f. But that almost looks like an accident.
> >
> >convert? with explicit checks would probably work better for the inner
> >conversion, except that handling the vector view_convert case may
> >become
> >painful. I didn't think too hard about possible fancy tricks like a
> >second
> >nop_convert:
> >
> >(minus (nop_convert (plus:c (nop_convert @0) @1)) (nop_convert @0))
>
> If use gets more and more we can make nop_convert a first class citizen and 
> allow a? Variant. Or handle all predicates as? Variant.

Like the attached (need to adjust docs & rename some functions still)
which generalizes
[digit]? parsing.  This allows you to write (nop_convert? ...)

It works (generated files are unchanged), so I guess I'll push it
after polishing.

It also extends the 1/2/3 grouping to be able to group like (plus
(nop_convert2? @0) (convert2? @1))
so either both will be present or none (meaning that when grouping you
can choose the "cheaper"
test for one in case you know the conversions will be the same).

Richard.

> Richard.
>


p2
Description: Binary data

Re: [RFC] Characters per line: from punch card (80) to line printer (132)

[Andrew Stubbs]

On 05/12/2019 18:21, Robin Curtis wrote:

My IBM Selectric golfball electronic printer only does 90 characters on A4 in 
portrait mode………(at 10 cps)

(as for my all electric TELEX Teleprinter machine !)

Is this debate for real ?!  - or is this a Christmas spoof ?


I can't speak for the debate, but the pain is real.

Andrew

Re: [PATCH] Fix up Fortran debug info for arrays with descriptors (PR fortran/92775)

[Tobias Burnus]

@Paul: I have an ISO-C question for you.


On 12/6/19 1:16 AM, Jakub Jelinek wrote:

[…]
Unfortunately, I don't know Fortran enough to find out when exactly the
compiler knows that descr->span will be always equal to element_size,


Well, while gfc_expr is still available, that's gfc_get_array_span; if 
it is neither a pointer (in the Fortran sense)/ISO-C descriptor nor a 
polymorphic, it has the element length [for strings: times the string 
length].


Instead of going for the general solution, I wonder whether one could 
use something like: If type is integer/real/complex and not a pointer, 
take the element size; namely, something like:


if (GFC_TYPE_ARRAY_AKIND (type) != GFC_ARRAY_POINTER
&& (INTEGRAL_TYPE_P (type) || SCALAR_FLOAT_TYPE_P (type)
|| COMPLEX_FLOAT_TYPE_P (type)))

That wouldn't cover known-size/nonpolymorphic derived types nor compile-time
const strings (span =  * ) but at least
the ubiquitous numeric arrays.
It surely could be refined to cover the rest (fixed-length strings, 
nonpolymorphic
types).

I only don't quickly see which GFC_TYPE_ARRAY_AKIND the ISO-C descriptor
gets, i.e. whether condition above will work or whether something in addition
is needed.

Paul?

(For me the whole gfc <-> ISO C descriptor handling looks like a mess,
but I also have not yet tried to fully understood how it works in detail.)
 


In the meantime, I think it is better to go for correct debug info over
saving the 3 bytes in .debug_info per dimension.

The patch also removes fields/macros that aren't ever used since r251949
and just waste compile time memory.

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


OK; thanks for the patch!

Tobias


2019-12-06  Jakub Jelinek  

PR fortran/92775
* trans.h (struct lang_type, struct lang_decl): Remove span member.
(GFC_DECL_SPAN, GFC_TYPE_ARRAY_SPAN): Remove macros.
* trans-array.h (gfc_get_descriptor_offsets_for_info): Add another
argument.
* trans-array.c (gfc_get_descriptor_offsets_for_info): Add SPAN_OFF
argument and initialize *SPAN_OFF to the offset of span field.
* trans-types.c (gfc_get_array_descr_info): Adjust
gfc_get_descriptor_offsets_for_info caller.  Compute elem_size
as base->span instead of TYPE_SIZE_UNIT (etype) constant.

--- gcc/fortran/trans.h.jj  2019-11-11 21:04:05.210259346 +0100
+++ gcc/fortran/trans.h 2019-12-05 11:23:55.935237355 +0100
@@ -981,7 +981,6 @@ struct GTY(())  lang_type{
tree offset;
tree dtype;
tree dataptr_type;
-  tree span;
tree base_decl[2];
tree nonrestricted_type;
tree caf_token;
@@ -997,7 +996,6 @@ struct GTY(()) lang_decl {
   address of target label.  */
tree stringlen;
tree addr;
-  tree span;
/* For assumed-shape coarrays.  */
tree token, caf_offset;
unsigned int scalar_allocatable : 1;
@@ -1008,7 +1006,6 @@ struct GTY(()) lang_decl {
  
  #define GFC_DECL_ASSIGN_ADDR(node) DECL_LANG_SPECIFIC(node)->addr

  #define GFC_DECL_STRING_LEN(node) DECL_LANG_SPECIFIC(node)->stringlen
-#define GFC_DECL_SPAN(node) DECL_LANG_SPECIFIC(node)->span
  #define GFC_DECL_TOKEN(node) DECL_LANG_SPECIFIC(node)->token
  #define GFC_DECL_CAF_OFFSET(node) DECL_LANG_SPECIFIC(node)->caf_offset
  #define GFC_DECL_SAVED_DESCRIPTOR(node) \
@@ -1059,7 +1056,6 @@ struct GTY(()) lang_decl {
  #define GFC_TYPE_ARRAY_DTYPE(node) (TYPE_LANG_SPECIFIC(node)->dtype)
  #define GFC_TYPE_ARRAY_DATAPTR_TYPE(node) \
(TYPE_LANG_SPECIFIC(node)->dataptr_type)
-#define GFC_TYPE_ARRAY_SPAN(node) (TYPE_LANG_SPECIFIC(node)->span)
  #define GFC_TYPE_ARRAY_BASE_DECL(node, internal) \
(TYPE_LANG_SPECIFIC(node)->base_decl[(internal)])
  
--- gcc/fortran/trans-array.h.jj	2019-09-26 22:02:40.236457478 +0200

+++ gcc/fortran/trans-array.h   2019-12-05 11:07:52.255125510 +0100
@@ -163,7 +163,7 @@ void gfc_trans_array_cobounds (tree, stm
  
  /* Build expressions for accessing components of an array descriptor.  */

  void gfc_get_descriptor_offsets_for_info (const_tree, tree *, tree *, tree *, 
tree *,
- tree *, tree *, tree *);
+ tree *, tree *, tree *, tree *);
  
  tree gfc_conv_descriptor_data_get (tree);

  tree gfc_conv_descriptor_data_addr (tree);
--- gcc/fortran/trans-array.c.jj2019-11-01 09:01:50.111998535 +0100
+++ gcc/fortran/trans-array.c   2019-12-05 11:09:38.545483494 +0100
@@ -540,9 +540,10 @@ gfc_conv_shift_descriptor_lbound (stmtbl
  
  void

  gfc_get_descriptor_offsets_for_info (const_tree desc_type, tree *data_off,
-tree *dtype_off, tree *dim_off,
-tree *dim_size, tree *stride_suboff,
-tree *lower_suboff, tree *upper_suboff)
+tree *dtype_off, tree *span_off,
+tree *dim_off, tree *dim_size,
+ 

Avoid quadratic behaviour in prune_runtime_alias_test_list

[Richard Sandiford]

prune_runtime_alias_test_list used ordered_remove to remove a merged
alias pair, which made the function quadratic when many aliases could
be removed.

I had a testcase in which these memmoves accounted for an impressive
85% of compile time.  The fact that we had so many probably shows
a deeper problem, but still, it's easy to remove as we go.

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

Richard


2019-12-06  Richard Sandiford  

gcc/
* tree-data-ref.c (prune_runtime_alias_test_list): Exit early
for empty vectors.  Avoid using ordered_remove and instead
shuffle the vector as we go.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c 2019-11-18 15:36:04.873884873 +
+++ gcc/tree-data-ref.c 2019-12-06 08:35:38.153410087 +
@@ -1535,6 +1535,9 @@ dump_alias_pair (dr_with_seg_len_pair_t
 prune_runtime_alias_test_list (vec *alias_pairs,
   poly_uint64)
 {
+  if (alias_pairs->is_empty ())
+return;
+
   /* Canonicalize each pair so that the base components are ordered wrt
  data_ref_compare_tree.  This allows the loop below to merge more
  cases.  */
@@ -1565,10 +1568,11 @@ prune_runtime_alias_test_list (veclength (); ++i)
 {
   /* Deal with two ddrs (dr_a1, dr_b1) and (dr_a2, dr_b2).  */
-  dr_with_seg_len_pair_t *alias_pair1 = &(*alias_pairs)[i - 1];
+  dr_with_seg_len_pair_t *alias_pair1 = &(*alias_pairs)[last];
   dr_with_seg_len_pair_t *alias_pair2 = &(*alias_pairs)[i];
 
   dr_with_seg_len *dr_a1 = _pair1->first;
@@ -1584,10 +1588,15 @@ prune_runtime_alias_test_list (vecdr), DR_REF (dr_b1->dr),
 DR_REF (dr_a2->dr), DR_REF (dr_b2->dr));
  alias_pair1->flags |= alias_pair2->flags;
- alias_pairs->ordered_remove (i--);
  continue;
}
 
+  /* Assume that we won't be able to merge the pairs, then correct
+if we do.  */
+  last += 1;
+  if (last != i)
+   (*alias_pairs)[last] = (*alias_pairs)[i];
+
   if (*dr_a1 == *dr_a2 || *dr_b1 == *dr_b2)
{
  /* We consider the case that DR_B1 and DR_B2 are same memrefs,
@@ -1695,10 +1704,10 @@ prune_runtime_alias_test_list (vecdr), DR_REF (dr_b1->dr),
 DR_REF (dr_a2->dr), DR_REF (dr_b2->dr));
  alias_pair1->flags |= alias_pair2->flags;
- alias_pairs->ordered_remove (i);
- i--;
+ last -= 1;
}
 }
+  alias_pairs->truncate (last + 1);
 
   /* Try to restore the original dr_with_seg_len order within each
  dr_with_seg_len_pair_t.  If we ended up combining swapped and

[PATCH] Improve *-match.c debugging

[Richard Biener]

The following more closely re-emits C expressions by emitting line
breaks whenever the source line location changes rather than only
after ;

This makes 'n' debugging easier.

I've only briefly tried to reconstruct the original source but
failed.  I guess the pp tokens do not contain enough information here.

Bootstrapped on x86_64-unknown-linux-gnu, applied.

Richard.

2019-12-06  Richard Biener  

* genmatch.c (c_expr::gen_transform): Emit newlines from line
number changes rather than after every semicolon.

Index: gcc/genmatch.c
===
--- gcc/genmatch.c  (revision 279033)
+++ gcc/genmatch.c  (working copy)
@@ -2599,10 +2599,22 @@ c_expr::gen_transform (FILE *f, int inde
 fprintf_indent (f, indent, "%s = ", dest);
 
   unsigned stmt_nr = 1;
+  int prev_line = -1;
   for (unsigned i = 0; i < code.length (); ++i)
 {
   const cpp_token *token = [i];
 
+  /* We can't recover from all lexing losses but we can roughly restore 
line
+ breaks from location info.  */
+  const line_map_ordinary *map;
+  linemap_resolve_location (line_table, token->src_loc,
+   LRK_SPELLING_LOCATION, );
+  expanded_location loc = linemap_expand_location (line_table, map,
+  token->src_loc);
+  if (prev_line != -1 && loc.line != prev_line)
+   fputc ('\n', f);
+  prev_line = loc.line;
+
   /* Replace captures for code-gen.  */
   if (token->type == CPP_ATSIGN)
{
@@ -2653,11 +2665,11 @@ c_expr::gen_transform (FILE *f, int inde
   if (token->type == CPP_SEMICOLON)
{
  stmt_nr++;
- fputc ('\n', f);
  if (dest && stmt_nr == nr_stmts)
fprintf_indent (f, indent, "%s = ", dest);
}
 }
+  fputc ('\n', f);
 }
 
 /* Generate transform code for a capture.  */

*PING* – Re: [Patch, Fortran] PR 92793 - fix column used for error diagnostic

[Tobias Burnus]

*Ping*

Regarding Frederik's remark about the testsuite:

I think the only test case in gfortran.dg/, which tests the column 
number, is use_without_only_1.f90. It has:

{ dg-warning "7:has no ONLY qualifier" }
here, the "7" is the column number. — Hence, it is not surprising that 
changes do not affect the test suite.


Cheers,

Tobias

On 12/4/19 2:37 PM, Tobias Burnus wrote:
As reported internally by Frederik, gfortran currently passes 
LOCATION_COLUMN == 0 to the middle end. The reason for that is how 
parsing works – gfortran reads the input line by line.


For internal error diagnostic (fortran/error.c), the column location 
was corrected –  but not for locations passed to the middle end. 
Hence, the diagnostic there wasn't optimal.


Fixed by introducing a new function; now one only needs to make sure 
that no new code will re-introduce "lb->location" :-)


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

Tobias