Re: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[Uros Bizjak via Gcc-patches]

On Tue, May 19, 2020 at 4:17 AM H.J. Lu  wrote:
>
> On Mon, May 18, 2020 at 5:57 AM H.J. Lu  wrote:
> >
> > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak  wrote:
> > >
> > > On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
> > > >
> > > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  wrote:
> > > > >
> > > > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  wrote:
> > > > > >
> > > > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice 
> > > > > > Lake
> > > > > > and Tiger Lake processor families.
> > > > > >
> > > > > > OK for master?
> > > > >
> > > > > OK.
> > > >
> > > > I am checking in my patch.
> > > >
> > > > > Please also update cpuinfo.c from libgcc and corresponding
> > > >
> > > > I will take a look to see if we share the same CPU detection code 
> > > > between
> > > > libgcc and config/i386/driver-i386.c.
> > >
> > > I don't think it will bring any benefit, this is mainly one huge
> > > switch statement that maps to different stuff in libgcc and
> > > driver-i386.
> >
> > libgcc and config/i386/driver-i386.c differ even before my patch.
> > I think we can do better.
> >
>
> Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
> can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
> and libgfortran to detect the specific type of Intel CPU.  Update
> libgfortran to use has_cpu_feature to detect x86 CPU features.
>
> Tested on Linux/x86 and Linux/x86-64.  OK for master?

Handling only Intel targets and not others is a sure way for patch to
be ignored.

Uros.

[PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[H.J. Lu via Gcc-patches]

On Mon, May 18, 2020 at 5:57 AM H.J. Lu  wrote:
>
> On Mon, May 18, 2020 at 5:43 AM Uros Bizjak  wrote:
> >
> > On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
> > >
> > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  wrote:
> > > >
> > > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  wrote:
> > > > >
> > > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> > > > > and Tiger Lake processor families.
> > > > >
> > > > > OK for master?
> > > >
> > > > OK.
> > >
> > > I am checking in my patch.
> > >
> > > > Please also update cpuinfo.c from libgcc and corresponding
> > >
> > > I will take a look to see if we share the same CPU detection code between
> > > libgcc and config/i386/driver-i386.c.
> >
> > I don't think it will bring any benefit, this is mainly one huge
> > switch statement that maps to different stuff in libgcc and
> > driver-i386.
>
> libgcc and config/i386/driver-i386.c differ even before my patch.
> I think we can do better.
>

Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
and libgfortran to detect the specific type of Intel CPU.  Update
libgfortran to use has_cpu_feature to detect x86 CPU features.

Tested on Linux/x86 and Linux/x86-64.  OK for master?

Thanks.

-- 
H.J.
From 3f75ee91b68c196660df21f43c3c2121fb63e69a Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 18 May 2020 05:58:41 -0700
Subject: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
and libgfortran to detect the specific type of Intel CPU.  Update
libgfortran to use has_cpu_feature to detect x86 CPU features.

gcc/

	* common/config/i386/cpuinfo.h: Moved from libgcc/config/i386.
	(CHECK___builtin_cpu_is): New.  Defined as empty if not defined.
	(get_intel_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Add
	an argument for AVX512VNNI.  Use CHECK___builtin_cpu_is.  Return
	Intel CPU name.
	(has_cpu_feature): New function.
	* config/i386/driver-i386.c: Include
	"common/config/i386/cpuinfo.h".
	(host_detect_local_cpu): Call get_intel_cpu to get Intel CPU
	name.

gcc/testsuite/

	* gcc.target/i386/builtin_target.c: Include  and
	../../../common/config/i386/cpuinfo.h.
	(CHECK___builtin_cpu_is): New.
	(inline): New.  Defined as empty.
	(check_intel_cpu_model): Removed.
	(check_detailed): Call get_intel_cpu instead of
	check_intel_cpu_model.

libgcc/

	* config/i386/cpuinfo.h: Moved to ... gcc/common/config/i386.
	* config/i386/cpuinfo.c: Include "common/config/i386/cpuinfo.h".
	(__cpu_features2): Make it static in libgcc_s.so.1.
	(get_intel_cpu): Moved to ... gcc/common/config/i386/cpuinfo.h.
	(get_available_features): Always set __cpu_features2.
	(__cpu_indicator_init): Call get_available_features before
	calling get_intel_cpu.  Pass has_cpu_feature (FEATURE_AVX512VNNI)
	to get_intel_cpu.

libgfortran/

	* m4/matmul.m4: Include  instead
	of .  Use has_cpu_feature.
	* generated/matmul_c10.c: Regenerated.
	* generated/matmul_c16.c: Likewise.
	* generated/matmul_c4.c: Likewise.
	* generated/matmul_c8.c: Likewise.
	* generated/matmul_i1.c: Likewise.
	* generated/matmul_i16.c: Likewise.
	* generated/matmul_i2.c: Likewise.
	* generated/matmul_i4.c: Likewise.
	* generated/matmul_i8.c: Likewise.
	* generated/matmul_r10.c: Likewise.
	* generated/matmul_r16.c: Likewise.
	* generated/matmul_r4.c: Likewise.
	* generated/matmul_r8.c: Likewise.
---
 gcc/common/config/i386/cpuinfo.h  | 365 ++
 gcc/config/i386/driver-i386.c | 131 +--
 .../gcc.target/i386/builtin_target.c  | 141 +--
 libgcc/config/i386/cpuinfo.c  | 162 +---
 libgcc/config/i386/cpuinfo.h  | 135 ---
 libgfortran/generated/matmul_c10.c|  18 +-
 libgfortran/generated/matmul_c16.c|  18 +-
 libgfortran/generated/matmul_c4.c |  18 +-
 libgfortran/generated/matmul_c8.c |  18 +-
 libgfortran/generated/matmul_i1.c |  18 +-
 libgfortran/generated/matmul_i16.c|  18 +-
 libgfortran/generated/matmul_i2.c |  18 +-
 libgfortran/generated/matmul_i4.c |  18 +-
 libgfortran/generated/matmul_i8.c |  18 +-
 libgfortran/generated/matmul_r10.c|  18 +-
 libgfortran/generated/matmul_r16.c|  18 +-
 libgfortran/generated/matmul_r4.c |  18 +-
 libgfortran/generated/matmul_r8.c |  18 +-
 libgfortran/m4/matmul.m4  |  18 +-
 19 files changed, 518 insertions(+), 668 deletions(-)
 create mode 100644 gcc/common/config/i386/cpuinfo.h
 delete mode 100644 libgcc/config/i386/cpuinfo.h

diff --git a/gcc/common/config/i386/cpuinfo.h b/gcc/common/config/i386/cpuinfo.h
new file mode 100644
index 000..8fe85d2c177
--- /dev/null
+++ b/gcc/common/config/i386/cpuinfo.h
@@ -0,0 

[PATCH] Refactor `execute` from gcc.c

[Giuliano Belinassi via Gcc-patches]

Hi,

After having so much trouble working on the `execute' function inside
gcc.c, I decided to refactor it so that it could be more digestible.
Since I am using it on my branch, I am submitting this patch for
"battlefield" testing.

Bootstrapped and ran the testsuite on Linux x86_64.

-

Refactor `execute' function to avoid exposing unnecessary details of
how it works, encapsulating each important step into a function.

gcc/ChangeLog
2020-05-18  Giuliano Belinassi  

* gcc.c (struct command): Move from execute.
(await_commands_to_finish): New function.
(split_commands): Same as above.
(parse_argbuf): Same as above.
(execute): Refactor based on new functions.
>From df092d93b511a28180105a2db40777fb977e23da Mon Sep 17 00:00:00 2001
From: Giuliano Belinassi 
Date: Mon, 18 May 2020 21:08:43 -0300
Subject: [PATCH] Refactor execute in gcc.c

Refactor `execute' function to avoid exposing unnecessary details of
how it works, encapsulating each important step into a function.

gcc/ChangeLog
2020-05-18  Giuliano Belinassi  

	* gcc.c (struct command): Move from execute.
	(await_commands_to_finish): New function.
	(split_commands): Same as above.
	(parse_argbuf): Same as above.
	(execute): Refactor based on new functions.
---
 gcc/ChangeLog |   8 +
 gcc/gcc.c | 595 +-
 2 files changed, 353 insertions(+), 250 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7f484da04f0..3ad1b9f7fb9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-05-18  Giuliano Belinassi  
+
+	* gcc.c (struct command): Move from execute.
+	(await_commands_to_finish): New function.
+	(split_commands): Same as above.
+	(parse_argbuf): Same as above.
+	(execute): Refactor based on new functions.
+
 2020-05-18  Jason Merrill  
 
 	* aclocal.m4: Add ax_cxx_compile_stdcxx.m4.
diff --git a/gcc/gcc.c b/gcc/gcc.c
index b0d0308f127..082a5d1d4a8 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -3019,157 +3019,105 @@ add_sysrooted_hdrs_prefix (struct path_prefix *pprefix, const char *prefix,
 }
 
 
-/* Execute the command specified by the arguments on the current line of spec.
-   When using pipes, this includes several piped-together commands
-   with `|' between them.
 
-   Return 0 if successful, -1 if failed.  */
+struct command
+{
+  const char *prog;		/* program name.  */
+  const char **argv;		/* vector of args.  */
+};
+
+/* Print what commands will run.  Return 0 if success, anything else on
+   error.  */
 
 static int
-execute (void)
+print_verbose (int n_commands, struct command commands[])
 {
   int i;
-  int n_commands;		/* # of command.  */
-  char *string;
-  struct pex_obj *pex;
-  struct command
-  {
-const char *prog;		/* program name.  */
-const char **argv;		/* vector of args.  */
-  };
-  const char *arg;
-
-  struct command *commands;	/* each command buffer with above info.  */
-
-  gcc_assert (!processing_spec_function);
-
-  if (wrapper_string)
-{
-  string = find_a_file (_prefixes,
-			argbuf[0], X_OK, false);
-  if (string)
-	argbuf[0] = string;
-  insert_wrapper (wrapper_string);
-}
 
-  /* Count # of piped commands.  */
-  for (n_commands = 1, i = 0; argbuf.iterate (i, ); i++)
-if (strcmp (arg, "|") == 0)
-  n_commands++;
-
-  /* Get storage for each command.  */
-  commands = (struct command *) alloca (n_commands * sizeof (struct command));
-
-  /* Split argbuf into its separate piped processes,
- and record info about each one.
- Also search for the programs that are to be run.  */
-
-  argbuf.safe_push (0);
-
-  commands[0].prog = argbuf[0]; /* first command.  */
-  commands[0].argv = argbuf.address ();
-
-  if (!wrapper_string)
-{
-  string = find_a_file (_prefixes, commands[0].prog, X_OK, false);
-  if (string)
-	commands[0].argv[0] = string;
-}
-
-  for (n_commands = 1, i = 0; argbuf.iterate (i, ); i++)
-if (arg && strcmp (arg, "|") == 0)
-  {/* each command.  */
-#if defined (__MSDOS__) || defined (OS2) || defined (VMS)
-	fatal_error (input_location, "%<-pipe%> not supported");
-#endif
-	argbuf[i] = 0; /* Termination of command args.  */
-	commands[n_commands].prog = argbuf[i + 1];
-	commands[n_commands].argv
-	  = &(argbuf.address ())[i + 1];
-	string = find_a_file (_prefixes, commands[n_commands].prog,
-			  X_OK, false);
-	if (string)
-	  commands[n_commands].argv[0] = string;
-	n_commands++;
-  }
-
-  /* If -v, print what we are about to do, and maybe query.  */
+  /* For help listings, put a blank line between sub-processes.  */
+  if (print_help_list)
+fputc ('\n', stderr);
 
-  if (verbose_flag)
+  /* Print each piped command as a separate line.  */
+  for (i = 0; i < n_commands; i++)
 {
-  /* For help listings, put a blank line between sub-processes.  */
-  if (print_help_list)
-	fputc ('\n', stderr);
+  const char *const *j;
 
-  /* Print each piped command as a separate line.  */
-  

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

[Marek Polacek via Gcc-patches]

On Tue, May 19, 2020 at 01:19:13AM +0200, Mark Wielaard wrote:
> On Mon, May 18, 2020 at 05:24:58PM +0200, Mark Wielaard wrote:
> > On Mon, May 18, 2020 at 11:09:18AM -0400, David Malcolm wrote:
> > > Overall, I like it, but it looks like there's a problem with the
> > > location of the fix-it hint: it looks like it might be replacing the
> > > whole of the underlined section of the call, argument, parentheses and
> > > all, with "_exit", rather than just the "exit" token.  I wonder if the
> > > location of that token is still available in the middle-end by the time
> > > the analyzer runs.
> > > 
> > > What does -fdiagnostics-generate-patch emit?
> > 
> > --- bzip2.c
> > +++ bzip2.c
> > @@ -871,7 +871,7 @@
> >terribly wrong. Trying to clean up might fail spectacularly. */
> >  
> > if (opMode == OM_Z) setExit(3); else setExit(2);
> > -   exit(exitValue);
> > +   _exit;
> >  }
> > 
> > Hmmm, back to the drawing board it seems.
> 
> It seems it is impossible to untangle the gimple call. We do have the
> function decl, but this is associated with the declaration of the
> function. Since we know the call starts with a known symbol identifier
> (that is all on one line), it seems we should be able to truncate the
> source_range for the call location to just that prefix. But it is
> incredibly hard to manipulate locations. Neither seems it simple to
> get the actual text of the location or a range to sanity check what we
> are doing.
> 
> So I am afraid we have to drop the actual fixit. But we can still add
> the note itself. The diagnostic now looks as follows:
> 
> /opt/local/install/gcc/bin/gcc -g -O2 -fanalyzer -fanalyzer-fine-grained -c 
> bzip2.c
> bzip2.c: In function ‘mySIGSEGVorSIGBUScatcher’:
> bzip2.c:874:4: warning: call to ‘exit’ from within signal handler [CWE-479] 
> [-Wanalyzer-unsafe-call-within-signal-handler]
>   874 |exit(exitValue);
>   |^~~
>   ‘main’: events 1-2
> |
> | 1784 | IntNative main ( IntNative argc, Char *argv[] )
> |  |   ^~~~
> |  |   |
> |  |   (1) entry to ‘main’
> |..
> | 1816 |signal (SIGSEGV, mySIGSEGVorSIGBUScatcher);
> |  |~~
> |  ||
> |  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
> |
>   event 3
> |
> |cc1:
> | (3): later on, when the signal is delivered to the process
> |
> +--> ‘mySIGSEGVorSIGBUScatcher’: events 4-5
>|
>|  816 | void mySIGSEGVorSIGBUScatcher ( IntNative n )
>|  |  ^~~~
>|  |  |
>|  |  (4) entry to ‘mySIGSEGVorSIGBUScatcher’
>|..
>|  874 |exit(exitValue);
>|  |~~~
>|  ||
>|  |(5) call to ‘exit’ from within signal handler
>|
> bzip2.c:874:4: note: ‘_exit’ is a possible signal-safe alternative for ‘exit’
>   874 |exit(exitValue);
>   |^~~
> 
> What do you think of the attached patch?
> 
> Thanks,
> 
> Mark

> From e47d9c6898b0db7f56cff03096b3fccaeb801efa Mon Sep 17 00:00:00 2001
> From: Mark Wielaard 
> Date: Sun, 17 May 2020 23:50:41 +0200
> Subject: [PATCH] analyzer: Add exit, and _exit replacement, to sm-signal.
> 
> Warn about using exit in signal handler and suggest _exit as alternative.
> 
> gcc/analyzer/ChangeLog:
>   * sm-signal.cc(signal_unsafe_call::emit): Possibly add
>   gcc_rich_location note for replacement.
>   (signal_unsafe_call::get_replacement_fn): New private function.
>   (get_async_signal_unsafe_fns): Add "exit".
> 
> gcc/testsuite/ChangeLog:
>   * gcc.dg/analyzer/signal-exit.c: New testcase.
> ---
>  gcc/analyzer/sm-signal.cc   | 43 +++--
>  gcc/testsuite/gcc.dg/analyzer/signal-exit.c | 23 +++
>  2 files changed, 62 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/analyzer/signal-exit.c
> 
> diff --git a/gcc/analyzer/sm-signal.cc b/gcc/analyzer/sm-signal.cc
> index 5935e229e77c..379f58004219 100644
> --- a/gcc/analyzer/sm-signal.cc
> +++ b/gcc/analyzer/sm-signal.cc
> @@ -123,13 +123,32 @@ public:
>  
>bool emit (rich_location *rich_loc) FINAL OVERRIDE
>{
> +auto_diagnostic_group d;
>  diagnostic_metadata m;
>  /* CWE-479: Signal Handler Use of a Non-reentrant Function.  */
>  m.add_cwe (479);
> -return warning_meta (rich_loc, m,
> -  OPT_Wanalyzer_unsafe_call_within_signal_handler,
> -  "call to %qD from within signal handler",
> -  m_unsafe_fndecl);
> +if (warning_meta (rich_loc, m,
> +   OPT_Wanalyzer_unsafe_call_within_signal_handler,
> +   "call to %qD from within signal handler",
> +   m_unsafe_fndecl))
> +  {
> + /* If we know a 

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

[Mark Wielaard]

On Mon, May 18, 2020 at 05:24:58PM +0200, Mark Wielaard wrote:
> On Mon, May 18, 2020 at 11:09:18AM -0400, David Malcolm wrote:
> > Overall, I like it, but it looks like there's a problem with the
> > location of the fix-it hint: it looks like it might be replacing the
> > whole of the underlined section of the call, argument, parentheses and
> > all, with "_exit", rather than just the "exit" token.  I wonder if the
> > location of that token is still available in the middle-end by the time
> > the analyzer runs.
> > 
> > What does -fdiagnostics-generate-patch emit?
> 
> --- bzip2.c
> +++ bzip2.c
> @@ -871,7 +871,7 @@
>terribly wrong. Trying to clean up might fail spectacularly. */
>  
> if (opMode == OM_Z) setExit(3); else setExit(2);
> -   exit(exitValue);
> +   _exit;
>  }
> 
> Hmmm, back to the drawing board it seems.

It seems it is impossible to untangle the gimple call. We do have the
function decl, but this is associated with the declaration of the
function. Since we know the call starts with a known symbol identifier
(that is all on one line), it seems we should be able to truncate the
source_range for the call location to just that prefix. But it is
incredibly hard to manipulate locations. Neither seems it simple to
get the actual text of the location or a range to sanity check what we
are doing.

So I am afraid we have to drop the actual fixit. But we can still add
the note itself. The diagnostic now looks as follows:

/opt/local/install/gcc/bin/gcc -g -O2 -fanalyzer -fanalyzer-fine-grained -c 
bzip2.c
bzip2.c: In function ‘mySIGSEGVorSIGBUScatcher’:
bzip2.c:874:4: warning: call to ‘exit’ from within signal handler [CWE-479] 
[-Wanalyzer-unsafe-call-within-signal-handler]
  874 |exit(exitValue);
  |^~~
  ‘main’: events 1-2
|
| 1784 | IntNative main ( IntNative argc, Char *argv[] )
|  |   ^~~~
|  |   |
|  |   (1) entry to ‘main’
|..
| 1816 |signal (SIGSEGV, mySIGSEGVorSIGBUScatcher);
|  |~~
|  ||
|  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
|
  event 3
|
|cc1:
| (3): later on, when the signal is delivered to the process
|
+--> ‘mySIGSEGVorSIGBUScatcher’: events 4-5
   |
   |  816 | void mySIGSEGVorSIGBUScatcher ( IntNative n )
   |  |  ^~~~
   |  |  |
   |  |  (4) entry to ‘mySIGSEGVorSIGBUScatcher’
   |..
   |  874 |exit(exitValue);
   |  |~~~
   |  ||
   |  |(5) call to ‘exit’ from within signal handler
   |
bzip2.c:874:4: note: ‘_exit’ is a possible signal-safe alternative for ‘exit’
  874 |exit(exitValue);
  |^~~

What do you think of the attached patch?

Thanks,

Mark>From e47d9c6898b0db7f56cff03096b3fccaeb801efa Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Sun, 17 May 2020 23:50:41 +0200
Subject: [PATCH] analyzer: Add exit, and _exit replacement, to sm-signal.

Warn about using exit in signal handler and suggest _exit as alternative.

gcc/analyzer/ChangeLog:
	* sm-signal.cc(signal_unsafe_call::emit): Possibly add
	gcc_rich_location note for replacement.
	(signal_unsafe_call::get_replacement_fn): New private function.
	(get_async_signal_unsafe_fns): Add "exit".

gcc/testsuite/ChangeLog:
	* gcc.dg/analyzer/signal-exit.c: New testcase.
---
 gcc/analyzer/sm-signal.cc   | 43 +++--
 gcc/testsuite/gcc.dg/analyzer/signal-exit.c | 23 +++
 2 files changed, 62 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/signal-exit.c

diff --git a/gcc/analyzer/sm-signal.cc b/gcc/analyzer/sm-signal.cc
index 5935e229e77c..379f58004219 100644
--- a/gcc/analyzer/sm-signal.cc
+++ b/gcc/analyzer/sm-signal.cc
@@ -123,13 +123,32 @@ public:
 
   bool emit (rich_location *rich_loc) FINAL OVERRIDE
   {
+auto_diagnostic_group d;
 diagnostic_metadata m;
 /* CWE-479: Signal Handler Use of a Non-reentrant Function.  */
 m.add_cwe (479);
-return warning_meta (rich_loc, m,
-			 OPT_Wanalyzer_unsafe_call_within_signal_handler,
-			 "call to %qD from within signal handler",
-			 m_unsafe_fndecl);
+if (warning_meta (rich_loc, m,
+		  OPT_Wanalyzer_unsafe_call_within_signal_handler,
+		  "call to %qD from within signal handler",
+		  m_unsafe_fndecl))
+  {
+	/* If we know a possible alternative function, add a note
+	   suggesting the replacement.  */
+	if (const char *replacement = get_replacement_fn ())
+	  {
+	location_t note_loc = gimple_location (m_unsafe_call);
+	/* It would be nice to add a fixit, but the gimple call
+	   location covers the whole call expression.  It isn't
+	   currently possible to cut this down to just the call
+	   symbol.  So the fixit would replace 

[PATCH] ppc64 check for incompatible setting of minimal-toc

[Douglas B Rupp]

Greetings,

The attached patch is proposed for rs6000/linux64.h.

The problem it addresses is that the current checking only tests for 
existence not for an incompatible/compatible setting.


For example:

$ powerpc64-linux-gnu-gcc -mcmodel=medium -mminimal-toc foo.c
is an incompatible set of switches

however

$ powerpc64-linux-gnu-gcc -mcmodel=medium -mno-minimal-toc foo.c
is ok.

Currently both are reported as incompatible.

--Douglas Rupp, AdaCore

diff --git gcc/config/rs6000/linux64.h gcc/config/rs6000/linux64.h
index 34776c8421e..6728006d208 100644
--- gcc/config/rs6000/linux64.h
+++ gcc/config/rs6000/linux64.h
@@ -134,8 +134,10 @@ extern int dot_symbols;
 	  rs6000_isa_flags |= OPTION_MASK_POWERPC64;	\
 	  error ("%<-m64%> requires a PowerPC64 cpu");		\
 	}			\
-	  if ((rs6000_isa_flags_explicit			\
-	   & OPTION_MASK_MINIMAL_TOC) != 0)			\
+	  if (((rs6000_isa_flags_explicit			\
+		& OPTION_MASK_MINIMAL_TOC) != 0) &&		\
+	  ((rs6000_isa_flags\
+		& OPTION_MASK_MINIMAL_TOC) != 0))		\
 	{			\
 	  if (global_options_set.x_rs6000_current_cmodel	\
 		  && rs6000_current_cmodel != CMODEL_SMALL)	\


changelog.toc
Description: application/cdrdao-toc

Re: [PATCH] Describe coding conventions surrounding "auto"

[Martin Sebor via Gcc-patches]

On 5/18/20 12:02 PM, Richard Sandiford wrote:

Martin Sebor  writes:

On 5/16/20 4:43 AM, Richard Sandiford wrote:

Sorry for the empty subject line earlier...

Jason Merrill  writes:

On Fri, May 15, 2020 at 9:47 PM Martin Sebor  wrote:


On 5/15/20 8:08 AM, Richard Sandiford wrote:

Those are all good examples.  Mind putting that into a patch
for the coding conventions?

How's this?  I added "new" expressions as another example of the
first category.

I'm sure I've missed other good uses, but we can always add to the
list later if necessary.

Thanks,
Richard


0001-Describe-coding-conventions-surrounding-auto.patch

   From 10b27e367de0fa9d5bf91544385401cdcbdb8c00 Mon Sep 17 00:00:00 2001
From: Richard Sandiford
Date: Fri, 15 May 2020 14:58:46 +0100
Subject: [PATCH] Describe coding conventions surrounding "auto"

---
htdocs/codingconventions.html | 53 +++
htdocs/codingrationale.html   | 17 +++
2 files changed, 70 insertions(+)

diff --git a/htdocs/codingconventions.html

b/htdocs/codingconventions.html

index f4732ef6..ae49fb91 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -51,6 +51,7 @@ the conventions separately from any other changes to

the code.

Language Use

Variable Definitions
+Use of auto
Struct Definitions
Class Definitions
Constructors and

Destructors

@@ -884,6 +885,58 @@ Variables may be simultaneously defined and tested

in control expressions.

Rationale and Discussion


+Use of auto
+
+auto should be used in the following circumstances:
+
+  when the expression gives the C++ type explicitly.  For

example

+
+
+if (auto *table = dyn_cast rtx_jump_table_data

* (insn)) // OK

+  ...
+if (rtx_jump_table_data *table = dyn_cast rtx_jump_table_data *

(insn))  // Avoid

+  ...
+auto *map = new hash_map tree, size_t;

  // OK

+hash_map tree, size_t *map = new hash_map tree, size_t;

// Avoid

+
+This rule does not apply to abbreviated type names embedded in
+an identifier, such as the result of tree_to_shwi.
+  
+  
+when the expression simply provides an alternative view of an

object

+and is bound to a read-only temporary.  For example:
+
+
+auto wioff = wi::to_wide (off); // OK
+wide_int wioff = wi::to_wide (off); // Avoid if wioff is read-only
+auto minus1 = std::shwi (-1, prec); // OK
+wide_int minus1 = std::shwi (-1, prec); // Avoid if minus1 is

read-only

+
+In principle this rule applies to other views of an object too,
+such as a reversed view of a list, or a sequential view of a
+hash_set.  It does not apply to general

temporaries.

+  
+  
+the type of an iterator.  For example:
+
+
+auto it = std::find (names.begin (), names.end (),

needle);// OK

+vector name_map::iterator it = std::find (names.begin (),
+names.end (), needle); //

Avoid

+  
+  
+the type of a lambda expression.  For example:
+
+
+auto f = [] (int x) { return x + 1; }; //

OK

+  
+
+
+auto should not be used in other contexts.


This seems like a severe (and unnecessary) restriction...


+
+
+Rationale and Discussion
+

Struct Definitions

diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..a919023c 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -50,6 +50,23 @@ if (info *q = get_any_available_info ()) {
}


+Use of auto
+
+The reason for preferring auto in expressions like:
+auto wioff = wi::to_wide (off);
+is that using the natural type of the expression is more efficient than
+converting it to types like wide_int.
+
+The reason for excluding other uses of auto is that
+in most other cases the type carries useful information.  For example:
+for (const std::pair const char *, tree

elt : indirect_pool)

+  ...
+makes it obvious that elt is a pair and gives the types of
+elt.first and elt.second.  In contrast:
+for (const auto elt : indirect_pool)
+  ...
+gives no immediate indication what elt is or what can
+be done with it.


...there are countless constructs in C++ 98 as well in C where there
is no such indication yet we don't (and very well can't) try to avoid
using them.  Examples include macros, members of structures defined
far away from the point of their use, results of ordinary function
calls, results of overloaded functions or templates, default function
arguments, default template parameters, etc.

By way of a random example from genrecog.c:

   int_set::iterator end
  = std::set_union (trans1->labels.begin (), trans1->labels.end (),
combined->begin (), combined->end (),
next->begin ());

There is no immediate indication precisely what type int_set::iterator
is.  All we can tell is that that it's some sort of an iterator, and
that 

Re: [PATCH] c++: ICE when shortening right shift [PR94955]

[Jason Merrill via Gcc-patches]

On 5/6/20 4:31 PM, Marek Polacek wrote:

Since r10-6527 fold_for_warn calls maybe_constant_value, which means it
can fold more than it previously could.  In this testcase it means that
cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able
to fold op1 to an INTEGER_CST.  But then when actually performing the
shortening we crashed because cp_fold_rvalue wasn't able to fold as much
as f_f_w and so tree_int_cst_sgn crashed on a NOP_EXPR.  Therefore the
calls should probably match.



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


OK.


PR c++/94955
* typeck.c (cp_build_binary_op): Use fold_for_warn instead of
cp_fold_rvalue.

* g++.dg/cpp0x/constexpr-shift2.C: New test.
---
  gcc/cp/typeck.c   |  4 +++-
  gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C | 12 
  2 files changed, 15 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 8e3188a415d..b468e92896a 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -5606,7 +5606,9 @@ cp_build_binary_op (const op_location_t ,
{
  int unsigned_arg;
  tree arg0 = get_narrower (op0, _arg);
- tree const_op1 = cp_fold_rvalue (op1);
+ /* We're not really warning here but when we set short_shift we
+used fold_for_warn to fold the operand.  */
+ tree const_op1 = fold_for_warn (op1);
  
  	  final_type = result_type;
  
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C

new file mode 100644
index 000..9b3490a66a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-shift2.C
@@ -0,0 +1,12 @@
+// PR c++/94955
+// { dg-do compile { target c++11 } }
+
+struct S {
+  static constexpr char foo() { return 10; }
+};
+
+short int
+fn (short int e)
+{
+  return e >> S::foo();
+}

base-commit: 319eafce3e54c8cb10e3fddce6823a6a558fca8b

Re: [PATCH v2] c++: ICE with -Wall and constexpr if [PR94937]

[Jason Merrill via Gcc-patches]

On 5/7/20 10:55 AM, Marek Polacek wrote:

On Wed, May 06, 2020 at 05:26:32PM -0400, Jason Merrill wrote:

On 5/5/20 6:17 PM, Marek Polacek wrote:

An ICE arises here because we call cp_get_callee_fndecl_nofold in a
template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK.
This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee.

Jakub said in the PR that he'd hit a similar problem too and dealt
with it in omp_declare_variant_finalize_one.  I considered tweaking
is_std_constant_evaluated_p to return false for a BASELINK, since the
std::is_constant_evaluated call we're looking for can't be a member
function, but perhaps we could get another unexpected CALL_EXPR and
crash the same.  In which case it might be better to make out the
omp_* code into a new routine and use that, as below.


Why not adjust cp_get_fndecl_from_callee to, say, return null instead of
aborting when !INDIRECT_TYPE_P?


It's often hard (for me, anyway) to decide if an assert should stay or can
be turned into a condition.  In this case we could argue that initially
cp_get_fndecl_from_callee wasn't meant to be called in a template, but now
we have reasonable use cases where it actually is called in a template, so
should cope instead of crashing.  Is that a fair assesment?


Yes, when we hit an assert we always have to decide whether the assert 
is catching a problem elsewhere or being too strict.  I think the 
unsuitability to template trees was accidental rather than deliberate.



I suspect one could argue that if we see a BASELINK, we might want to use
BASELINK_FUNCTIONS to get the FUNCTION_DECL, but I don't have a test where
that would make a difference.


In a template we end up with CALL_EXPR_FN that refers to the overload 
set; even if we were able to do overload resolution and chose a function 
to call, we've discarded that information.


We could restrict the added null return to

  processing_template_decl && is_overloaded_fn (fn)

but I'm not sure that retaining that much of the assert is actually 
valuable.



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


OK.


-- >8 --
An ICE arises here because we call cp_get_callee_fndecl_nofold in a
template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK.
This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee.

Fixed by turning the assert into a condition and returning NULL_TREE
in that case.

PR c++/94937
* cvt.c (cp_get_fndecl_from_callee): Return NULL_TREE if the function
type is not INDIRECT_TYPE_P.
* decl.c (omp_declare_variant_finalize_one): Call
cp_get_callee_fndecl_nofold instead of looking for the function decl
manually.

* g++.dg/cpp1z/constexpr-if34.C: New test.
* g++.dg/cpp2a/is-constant-evaluated10.C: New test.
---
  gcc/cp/cvt.c  |  3 +-
  gcc/cp/decl.c | 12 +---
  gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C   | 15 ++
  .../g++.dg/cpp2a/is-constant-evaluated10.C| 30 +++
  4 files changed, 47 insertions(+), 13 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated10.C

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index 656e7fd3ec0..371002833d0 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -995,9 +995,8 @@ cp_get_fndecl_from_callee (tree fn, bool fold /* = true */)
if (TREE_CODE (fn) == FUNCTION_DECL)
  return fn;
tree type = TREE_TYPE (fn);
-  if (type == unknown_type_node)
+  if (type == NULL_TREE || !INDIRECT_TYPE_P (type))
  return NULL_TREE;
-  gcc_assert (INDIRECT_TYPE_P (type));
if (fold)
  fn = maybe_constant_init (fn);
STRIP_NOPS (fn);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 232d7ed4a14..cbdef3e3365 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7297,17 +7297,7 @@ omp_declare_variant_finalize_one (tree decl, tree attr)
if (variant == error_mark_node && !processing_template_decl)
  return true;
  
-  variant = cp_get_callee (variant);

-  if (variant)
-{
-  if (TREE_CODE (variant) == FUNCTION_DECL)
-   ;
-  else if (TREE_TYPE (variant) && INDIRECT_TYPE_P (TREE_TYPE (variant)))
-   variant = cp_get_fndecl_from_callee (variant, false);
-  else
-   variant = NULL_TREE;
-}
-
+  variant = cp_get_callee_fndecl_nofold (variant);
input_location = save_loc;
  
if (variant)

diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C 
b/gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C
new file mode 100644
index 000..6e0b2597a53
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if34.C
@@ -0,0 +1,15 @@
+// PR c++/94937 - ICE with -Wall and constexpr if.
+// { dg-do compile { target c++17 } }
+// { dg-options "-Wall" }
+
+struct B {
+  static constexpr bool foo() { return false; }
+};
+
+template
+struct C {
+  static void bar ()
+  {
+if constexpr (B::foo()) ;
+  }

Re: [C++ Patch] PR 90915 [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

[Jason Merrill via Gcc-patches]

On 5/7/20 9:57 PM, Marek Polacek wrote:

On Thu, May 07, 2020 at 06:09:30PM -0600, Martin Sebor wrote:

On 5/7/20 5:03 PM, Marek Polacek via Gcc-patches wrote:

On Wed, Jan 29, 2020 at 10:06:51PM +0100, Paolo Carlini wrote:

Hi,

On 29/01/20 19:00, Jason Merrill wrote:

On 1/29/20 4:31 AM, Paolo Carlini wrote:

Hi,

in this regression we issue a diagnostic about an incomplete type
(only a warning by default) and then we crash when we try to query
has_attribute on a member of the type because in such cases the
member remains an IDENTIFIER_NODE which of course doesn't have a
TREE_TYPE neither a DECL_ATTRIBUTES... Simply recognizing
IDENTIFIER_NODEs and returning false works fine, not sure if we want
to do something more sophisticated. Tested x86_64-linux.


Why are we getting to has_attribute at all for a type-dependent argument?


Because the implementation of __builtin_has_attribute, largely shared with
the C front-end, doesn't know about templates at all? :-/

Not sure it's the best time to complete it, but shouldn't be too difficult.


This ICEs even with a more reasonable test like

template
void foo ()
{
static_assert(!__builtin_has_attribute(T::a, aligned));
}

The problem here is that __builtin_has_attribute doesn't handle type-dependent
arguments at all.  To handle type-dependent arguments we'd have to introduce
a new template code, like STATIC_ASSERT or ADDRESSOF_EXPR (or a new generic
template code for built-ins?), but that's always a pain.

Or, meanwhile, we could just sorry.  Martin, what do you think?


I never did implement the template handling and I didn't think to put
in a stopgap like the one below.  It makes sense until I get around to
implementing it, hopefully for GCC 11.


Ah, and we have PR92104 to track that.   Here's a complete patch then:

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


OK.


 From 7ed334b7998314bab12fe4741bc311a47457ea3a Mon Sep 17 00:00:00 2001
From: Marek Polacek 
Date: Thu, 7 May 2020 21:10:42 -0400
Subject: [PATCH] c++: Sorry about type-dependent arg for
  __builtin_has_attribute [PR90915]

Until 92104 is fixed, let's sorry rather than crash.

PR c++/90915
* parser.c (cp_parser_has_attribute_expression): Sorry on a
type-dependent argument.

* g++.dg/ext/builtin-has-attribute.C: New test.
---
  gcc/cp/parser.c  | 7 ++-
  gcc/testsuite/g++.dg/ext/builtin-has-attribute.C | 8 
  2 files changed, 14 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/ext/builtin-has-attribute.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d67fa3b13d1..f586c89b109 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8682,7 +8682,12 @@ cp_parser_has_attribute_expression (cp_parser *parser)
location_t atloc = cp_lexer_peek_token (parser->lexer)->location;
if (tree attr = cp_parser_gnu_attribute_list (parser, /*exactly_one=*/true))
  {
-  if (oper != error_mark_node)
+  if (oper == error_mark_node)
+   /* Nothing.  */;
+  else if (type_dependent_expression_p (oper))
+   sorry_at (atloc, "%<__builtin_has_attribute%> with dependent argument "
+ "not supported yet");
+  else
{
  /* Fold constant expressions used in attributes first.  */
  cp_check_const_attributes (attr);
diff --git a/gcc/testsuite/g++.dg/ext/builtin-has-attribute.C 
b/gcc/testsuite/g++.dg/ext/builtin-has-attribute.C
new file mode 100644
index 000..3438dd59ba3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/builtin-has-attribute.C
@@ -0,0 +1,8 @@
+// PR c++/90915
+// { dg-do compile { target c++11 } }
+
+template
+void foo ()
+{
+  static_assert(!__builtin_has_attribute(T::a, aligned), ""); // { dg-message 
"sorry, unimplemented: .__builtin_has_attribute. with dependent argument not supported 
yet" }
+}

base-commit: 74d58ad2c208c9c445bb3e8288db08e092a66316

Re: [C++ Patch] PR 90915 [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221

[Jason Merrill via Gcc-patches]

On 5/7/20 7:03 PM, Marek Polacek wrote:

On Wed, Jan 29, 2020 at 10:06:51PM +0100, Paolo Carlini wrote:

Hi,

On 29/01/20 19:00, Jason Merrill wrote:

On 1/29/20 4:31 AM, Paolo Carlini wrote:

Hi,

in this regression we issue a diagnostic about an incomplete type
(only a warning by default) and then we crash when we try to query
has_attribute on a member of the type because in such cases the
member remains an IDENTIFIER_NODE which of course doesn't have a
TREE_TYPE neither a DECL_ATTRIBUTES... Simply recognizing
IDENTIFIER_NODEs and returning false works fine, not sure if we want
to do something more sophisticated. Tested x86_64-linux.


Why are we getting to has_attribute at all for a type-dependent argument?


Because the implementation of __builtin_has_attribute, largely shared with
the C front-end, doesn't know about templates at all? :-/

Not sure it's the best time to complete it, but shouldn't be too difficult.


This ICEs even with a more reasonable test like

template
void foo ()
{
   static_assert(!__builtin_has_attribute(T::a, aligned));
}

The problem here is that __builtin_has_attribute doesn't handle type-dependent
arguments at all.  To handle type-dependent arguments we'd have to introduce
a new template code, like STATIC_ASSERT or ADDRESSOF_EXPR (or a new generic
template code for built-ins?), but that's always a pain.


Adding an internal_fn might be easier; see where tsubst_copy_and_build 
handles IFN_LAUNDER.



Or, meanwhile, we could just sorry.  Martin, what do you think?

--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8682,7 +8682,12 @@ cp_parser_has_attribute_expression (cp_parser *parser)
location_t atloc = cp_lexer_peek_token (parser->lexer)->location;
if (tree attr = cp_parser_gnu_attribute_list (parser, /*exactly_one=*/true))
  {
-  if (oper != error_mark_node)
+  if (oper == error_mark_node)
+   /* Nothing.  */;
+  else if (type_dependent_expression_p (oper))
+   sorry_at (atloc, "%<__builtin_has_attribute%> with dependent argument "
+ "not supported yet");
+  else
 {
   /* Fold constant expressions used in attributes first.  */
   cp_check_const_attributes (attr);


This is certainly an improvement over an ICE.

Jason

Re: [PATCH] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

[Marek Polacek via Gcc-patches]

On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/13/20 12:22 PM, Marek Polacek wrote:
> > DR 2289 clarified that since structured bindings have no C compatibility
> > implications, they should be unique in their declarative region, see
> > [basic.scope.declarative]/4.2.
> > 
> > The duplicate_decls hunk is the gist of the patch, but that alone would
> > not be enough to detect the 'A' case: cp_parser_decomposition_declaration
> > uses
> > 
> > 13968   tree decl2 = start_decl (declarator, _specs, 
> > SD_INITIALIZED,
> > 13969NULL_TREE, NULL_TREE, 
> > _pushed_scope);
> > 
> > to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we
> > don't do fit_decomposition_lang_decl because the declarator kind is not
> > cdk_decomp
> 
> Why isn't it?  I see
> 
>   cp_declarator *declarator = make_declarator (cdk_decomp);
> 
> a few lines up.

Right, and we use that for the underlying decomp base VAR_DECL.  But each of
the named variables used in a structured binding are created in the
FOR_EACH_VEC_ELT loop, and that creates a cdk_id declarator for them:

13963   if (i == 0)
13964 declarator = make_id_declarator (NULL_TREE, e.get_value (),
13965  sfk_none, e.get_location ());


Marek

Re: Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

[Segher Boessenkool]

Hi!

On Mon, May 18, 2020 at 11:54:31AM -0700, Joel Brobecker wrote:
> > (Don't forget the changelog?)
> 
> Thank you, Segher. Pushed to master, and for 8, 9 and 10.

Thanks!

> I did include the ChangeLog indeed. I tend to avoid sending them
> in the diff, because they usually don't apply out of the box. I know
> there are some ways to resolve the conflicts automatically. I haven't
> gotten around to setting that up, but if this is causing any confusion
> here, I'll make sure to include the ChangeLog diff in the patch as well.

Well, you *never* should have had the changelog as part of the patch...
This has been the policy since forever.  The usual place to put it was
as text between your introductory message and the patch.  With the new
changelog policies that still holds: you no longer will patch and check
in the changelog files, but you will put the changelog at the end of
your commit message, and the rest is magic.  If I understand it all
correctly :-)  We'll hear details soon enough I bet :-)


Segher

Re: [PATCH] handle std::byte in -Wclass-memaccess (PR 94923)

[Jason Merrill via Gcc-patches]

On 5/8/20 2:16 PM, Martin Sebor wrote:

-Wclass-memaccess is suppressed for write accesses to trivially
copyable but otherwise nontrivial class types by character types
but the suppression neglects to consider the equivalent accesses
by std::byte.  The attached patch extends the same privilege also
to it.

I couldn't find a utility function to check if a type is one of
the four "special" byte types so I added one.  If there already
isn't one hiding somewhere and this type of a query is done in
other places maybe the function should be moved to cp-tree.h.

Rather than adding a new test I extended the existing one that
has all the infrastructure in place to comprehensively exercise
this (maybe even overly so).



+/* Returns true if TYPE is a character type of std::byte.  */


"or"

Let's name the new function is_byte_access_type to clarify that it 
doesn't just mean std::byte.


Let's use the new function in build_cplus_array_type in the initializer 
of "typeless_storage".


OK with those changes.

Jason

Re: [PATCH] c++: explain fn template argument type/value mismatch failures

[Jason Merrill via Gcc-patches]

On 5/7/20 12:47 PM, Patrick Palka wrote:

In fn_type_unifcation, we are passing NULL_TREE as the 'in_decl'
parameter to coerce_template_parms, and this is causing template
type/value mismatch error messages to get suppressed regardless of the
value of 'complain'.

This means that when substitution into a function template fails due to
a type/value mismatch between a template parameter and the provided
template argument, we just say "template argument deduction/substitution
failed:" without a followup explanation of the failure.

Fix this by passing 'fn' instead of NULL_TREE to coerce_template_parms.
Passes 'make check-c++', does this look OK to commit after a full
bootstrap and regtest?


OK.


gcc/cp/ChangeLog:

* pt.c (fn_type_unification): Pass 'fn' instead of NULL_TREE as
the 'in_decl' parameter to coerce_template_parms.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-ts4.C: Expect a "type/value mismatch"
diagnostic.
* g++.dg/cpp2a/concepts-ts6.C: Likewise.
* g++.dg/template/error56.C: Likewise.
* g++.dg/template/error59.C: New test.

libstdc++-v3/ChangeLog:

* testsuite/20_util/pair/astuple/get_neg.cc: Prune "type/value
mismatch" messages.
* testsuite/20_util/tuple/element_access/get_neg.cc: Likewise.
---
  gcc/cp/pt.c   |  2 +-
  gcc/testsuite/g++.dg/cpp2a/concepts-ts4.C |  2 ++
  gcc/testsuite/g++.dg/cpp2a/concepts-ts6.C |  4 +++-
  gcc/testsuite/g++.dg/template/error56.C   |  2 ++
  gcc/testsuite/g++.dg/template/error59.C   | 11 +++
  .../testsuite/20_util/pair/astuple/get_neg.cc |  1 +
  .../testsuite/20_util/tuple/element_access/get_neg.cc |  1 +
  7 files changed, 21 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/template/error59.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index c6091127225..52bb6f34d6a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21088,7 +21088,7 @@ fn_type_unification (tree fn,
/* Adjust any explicit template arguments before entering the
 substitution context.  */
explicit_targs
-   = (coerce_template_parms (tparms, explicit_targs, NULL_TREE,
+   = (coerce_template_parms (tparms, explicit_targs, fn,
  complain|tf_partial,
  /*require_all_args=*/false,
  /*use_default_args=*/false));
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-ts4.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-ts4.C
index aa96621d9cf..2b0fd1b8deb 100644
--- a/gcc/testsuite/g++.dg/cpp2a/concepts-ts4.C
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-ts4.C
@@ -31,4 +31,6 @@ void driver()
fn<0>(); // OK
fn<-1>(); // { dg-error "" }
fn(); // { dg-error "no matching function" }
+  // { dg-error "type/value mismatch at argument 1" "" { target *-*-* } .-1 }
+  // { dg-message "expected a constant of type .int., got .int." "" { target 
*-*-* } .-2 }
  }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-ts6.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-ts6.C
index bf665aa6308..e3dff54c83d 100644
--- a/gcc/testsuite/g++.dg/cpp2a/concepts-ts6.C
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-ts6.C
@@ -25,6 +25,8 @@ void driver1() {
  
f();

f(); // { dg-error "no matching function for call" }
+  // { dg-error "type/value mismatch at argument 1" "" { target *-*-* } .-1 }
+  // { dg-message "expected a class template, got .int." "" { target *-*-* } 
.-2 }
  
S2 s2a;

S2 s2b;
@@ -69,4 +71,4 @@ void driver2()
S6 s6a;
S6 s6c; // { dg-error "template constraint failure" }
S6 s6b; // { dg-error "wrong number of template 
arguments" }
-}
\ No newline at end of file
+}
diff --git a/gcc/testsuite/g++.dg/template/error56.C 
b/gcc/testsuite/g++.dg/template/error56.C
index 3eda04c3225..e85471a50b0 100644
--- a/gcc/testsuite/g++.dg/template/error56.C
+++ b/gcc/testsuite/g++.dg/template/error56.C
@@ -9,4 +9,6 @@ struct A
  int main()
  {
A().f<1>();   // { dg-error "f<1>" }
+  // { dg-error "type/value mismatch at argument 1" "" { target *-*-* } .-1 }
+  // { dg-message "expected a type, got .1." "" { target *-*-* } .-2 }
  }
diff --git a/gcc/testsuite/g++.dg/template/error59.C 
b/gcc/testsuite/g++.dg/template/error59.C
new file mode 100644
index 000..f81a28c2f1a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/error59.C
@@ -0,0 +1,11 @@
+template struct S { };
+
+template class TT>
+void foo();
+
+void bar()
+{
+  foo(); // { dg-error "no matching function" }
+  // { dg-error "type/value mismatch at argument 1" "" { target *-*-* } .-1 }
+  // { dg-message "expected a template of type .template class TT., got .template struct S." "" { target *-*-* } .-2 }
+}
diff --git a/libstdc++-v3/testsuite/20_util/pair/astuple/get_neg.cc 
b/libstdc++-v3/testsuite/20_util/pair/astuple/get_neg.cc
index bcf3940e16d..1f76aef6d73 100644
--- 

Re: [PATCH] c++: Enable spec_hasher table sanitization [PR87847]

[Jason Merrill via Gcc-patches]

On 5/11/20 9:10 AM, Patrick Palka wrote:

It looks like hash table sanitization is now safe to enable for the
decl_specializations and type_specializations tables, probably ever
since PR94454 was fixed.

Bootstrapped and regtested on x86_64-pc-linux-gnu with the attached
debugging patch that makes all entries hash to 0, and also successfully
built the range-v3 testsuite and a number of other libraries with this
debugging patch.  Does this look OK to commit?


OK.


gcc/cp/ChangeLog:

PR c++/87847
* pt.c (init_template_processing): Enable sanitization for
decl_specializations and type_specializations.
---
  gcc/cp/pt.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index c6091127225..2d1869816c5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29441,9 +29441,8 @@ declare_integer_pack (void)
  void
  init_template_processing (void)
  {
-  /* FIXME: enable sanitization (PR87847) */
-  decl_specializations = hash_table::create_ggc (37, false);
-  type_specializations = hash_table::create_ggc (37, false);
+  decl_specializations = hash_table::create_ggc (37);
+  type_specializations = hash_table::create_ggc (37);
  
if (cxx_dialect >= cxx11)

  declare_integer_pack ();

Re: [PATCH] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

[Jason Merrill via Gcc-patches]

On 5/13/20 12:22 PM, Marek Polacek wrote:

DR 2289 clarified that since structured bindings have no C compatibility
implications, they should be unique in their declarative region, see
[basic.scope.declarative]/4.2.

The duplicate_decls hunk is the gist of the patch, but that alone would
not be enough to detect the 'A' case: cp_parser_decomposition_declaration
uses

13968   tree decl2 = start_decl (declarator, _specs, SD_INITIALIZED,
13969NULL_TREE, NULL_TREE, _pushed_scope);

to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we
don't do fit_decomposition_lang_decl because the declarator kind is not
cdk_decomp


Why isn't it?  I see

  cp_declarator *declarator = make_declarator (cdk_decomp);

a few lines up.

Jason

Re: [PATCH] Implement no_stack_protect attribute.

[Martin Sebor via Gcc-patches]

On 5/18/20 4:37 AM, Martin Liška wrote:

Hi.

The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_protect because we already
have stack_protect attribute (used with -fstack-protector-explicit).

First part of the patch contains a small refactoring of an enum, second
implements the functionality.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

0002-Implement-no_stack_protect-attribute.patch

 From 6b3e9d32150fe17acb271b7bedee7dc95cad7dc8 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 15 May 2020 14:42:12 +0200
Subject: [PATCH 2/2] Implement no_stack_protect attribute.

gcc/ChangeLog:

2020-05-18  Martin Liska

PR c/94722
* cfgexpand.c (stack_protect_decl_phase):
Guard with lookup_attribute("no_stack_protect") at
various places.
(expand_used_vars): Likewise here.
* doc/extend.texi: Document no_stack_protect attribute.

gcc/ada/ChangeLog:

2020-05-18  Martin Liska

PR c/94722
* gcc-interface/utils.c (handle_no_stack_protect_attribute):
New.
(handle_stack_protect_attribute): Add error message for a
no_stack_protect function.

gcc/c-family/ChangeLog:

2020-05-18  Martin Liska

PR c/94722
* c-attribs.c (handle_no_stack_protect_function_attribute): New.
(handle_stack_protect_attribute): Add error message for a
no_stack_protect function.

gcc/testsuite/ChangeLog:

2020-05-18  Martin Liska

PR c/94722
* g++.dg/no-stack-protect-attr-2.C: New test.
* g++.dg/no-stack-protect-attr-3.C: New test.
* g++.dg/no-stack-protect-attr.C: New test.
---
  gcc/ada/gcc-interface/utils.c | 32 
  gcc/c-family/c-attribs.c  | 33 
  gcc/cfgexpand.c   | 82 ++-
  gcc/doc/extend.texi   |  4 +
  .../g++.dg/no-stack-protect-attr-2.C  |  7 ++
  .../g++.dg/no-stack-protect-attr-3.C  | 23 ++
  gcc/testsuite/g++.dg/no-stack-protect-attr.C  | 16 
  7 files changed, 158 insertions(+), 39 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/no-stack-protect-attr-2.C
  create mode 100644 gcc/testsuite/g++.dg/no-stack-protect-attr-3.C
  create mode 100644 gcc/testsuite/g++.dg/no-stack-protect-attr.C

diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
index 1527be4f6d1..144afe37d78 100644
--- a/gcc/ada/gcc-interface/utils.c
+++ b/gcc/ada/gcc-interface/utils.c
@@ -91,6 +91,7 @@ static tree handle_nonnull_attribute (tree *, tree, tree, 
int, bool *);
  static tree handle_sentinel_attribute (tree *, tree, tree, int, bool *);
  static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
  static tree handle_stack_protect_attribute (tree *, tree, tree, int, bool *);
+static tree handle_no_stack_protect_attribute (tree *, tree, tree, int, bool 
*);
  static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
  static tree handle_noclone_attribute (tree *, tree, tree, int, bool *);
  static tree handle_noicf_attribute (tree *, tree, tree, int, bool *);
@@ -141,6 +142,8 @@ const struct attribute_spec gnat_internal_attribute_table[] 
=
  handle_noreturn_attribute, NULL },
{ "stack_protect",0, 0, true,  false, false, false,
  handle_stack_protect_attribute, NULL },
+  { "no_stack_protect",0, 0, true,  false, false, false,
+handle_no_stack_protect_attribute, NULL },
{ "noinline", 0, 0,  true,  false, false, false,
  handle_noinline_attribute, NULL },
{ "noclone",  0, 0,  true,  false, false, false,
@@ -6523,10 +6526,39 @@ handle_stack_protect_attribute (tree *node, tree name, 
tree, int,
warning (OPT_Wattributes, "%qE attribute ignored", name);
*no_add_attrs = true;
  }
+  else if (lookup_attribute ("no_stack_protect", DECL_ATTRIBUTES (*node)))
+{
+  warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
+  "with %qs attribute", name, "no_stack_protect");
+  *no_add_attrs = true;


I know there are some somewhat complex cases the attribute exclusion
mechanism isn't general enough to handle but this seems simple enough
that it should work.  Unless I'm missing something that makes it not
feasible I would suggest to use it.


diff --git a/gcc/testsuite/g++.dg/no-stack-protect-attr-2.C 
b/gcc/testsuite/g++.dg/no-stack-protect-attr-2.C
new file mode 100644
index 000..dcac6f9d389
--- /dev/null
+++ b/gcc/testsuite/g++.dg/no-stack-protect-attr-2.C
@@ -0,0 +1,7 @@
+/* PR c/94722 */
+/* { dg-do compile } */
+
+int __attribute__((no_stack_protect, stack_protect)) c() /* { dg-warning 
"'stack_protect' attribute ignored due to conflict with 'no_stack_protect' 
attribute" } */


The more likely misuse than applying incompatible 

Re: [PATCH] c++: Implement DR 1512, Pointer comparison vs qual convs [PR87699]

[Marek Polacek via Gcc-patches]

On Mon, May 18, 2020 at 03:50:55PM -0400, Jason Merrill via Gcc-patches wrote:
> On 5/16/20 6:32 PM, Marek Polacek wrote:
> > +  const int q1 = cp_type_quals (pointee1);
> > +  const int q2 = cp_type_quals (pointee2);
> > +  const int quals = q1 | q2;
> > result_type = cp_build_qualified_type (result_type,
> > -(cp_type_quals (pointee1)
> > - | cp_type_quals (pointee2)));
> > +(quals | (*add_const
> > +  ? TYPE_QUAL_CONST
> > +  : TYPE_UNQUALIFIED)));
> 
> Since you're splitting out some of the arithmetic into local variables, why
> not handle *add_const there as well?

I didn't do that because right after this line we have

  if (quals != q1 || quals != q2)

and I didn't want 'add_const' to interfere with 'quals'.  It actually couldn't
do anything bad, just set 'add_const' unnecessarily.  I guess I'll leave it
as-is, but I don't feel strongly about it.

> OK either way.

Thanks,

Marek

[pushed] c++: Create fewer SAVE_EXPR.

[Jason Merrill via Gcc-patches]

In a couple of places in build_over_call we were calling
cp_stabilize_reference but only using the result once, so it isn't needed.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog
2020-05-18  Jason Merrill  

* call.c (build_over_call): Remove unnecessary
cp_stabilize_reference.
---
 gcc/cp/call.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index b96bc06a364..0b0eaa65ad8 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -9003,8 +9003,7 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
   else if ((trivial || TREE_CODE (arg) == TARGET_EXPR)
   && !unsafe)
{
- tree to = cp_stabilize_reference (cp_build_fold_indirect_ref (fa));
-
+ tree to = cp_build_fold_indirect_ref (fa);
  val = build2 (INIT_EXPR, DECL_CONTEXT (fn), to, arg);
  return val;
}
@@ -9013,8 +9012,7 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
   && DECL_OVERLOADED_OPERATOR_IS (fn, NOP_EXPR)
   && trivial_fn_p (fn))
 {
-  tree to = cp_stabilize_reference
-   (cp_build_fold_indirect_ref (argarray[0]));
+  tree to = cp_build_fold_indirect_ref (argarray[0]);
   tree type = TREE_TYPE (to);
   tree as_base = CLASSTYPE_AS_BASE (type);
   tree arg = argarray[1];
@@ -9043,6 +9041,7 @@ build_over_call (struct z_candidate *cand, int flags, 
tsubst_flags_t complain)
  tree array_type, alias_set;
 
  arg2 = TYPE_SIZE_UNIT (as_base);
+ to = cp_stabilize_reference (to);
  arg0 = cp_build_addr_expr (to, complain);
 
  array_type = build_array_type (unsigned_char_type_node,

base-commit: 100fdb1f09b484ef100b638b28a260857d85f9dd
-- 
2.18.1

Re: [PATCH] c++: Change the default dialect to C++17.

[Marek Polacek via Gcc-patches]

On Mon, May 18, 2020 at 10:04:07PM +0200, Jakub Jelinek wrote:
> On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote:
> > > --- a/libgomp/testsuite/libgomp.c++/for-27.C
> > > +++ b/libgomp/testsuite/libgomp.c++/for-27.C
> > > @@ -151,6 +151,12 @@ f4 (const I , const I )
> > >   else if (results[i])\
> > > abort ()
> > > +// FIXME: OpenMP seems to count on this being instantiated; the copy
> > > +// constructor is called in functions fn2/fn3/fn4.  But in C++17 we
> > > +// elide this copy constructor, so it's never been instantiated.  For
> > > +// now instantiate it explicitly.
> > 
> > This sounds like a bug that needs to be fixed before the default can change.
> > I guess the openmp code needs to mark_used the copy constructor or the like.
> 
> I'll have a look, though no guarantee I manage it this week.

Thanks, do you want a PR for it?

Marek

Re: [PATCH] c++: Change the default dialect to C++17.

[Jakub Jelinek via Gcc-patches]

On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote:
> > --- a/libgomp/testsuite/libgomp.c++/for-27.C
> > +++ b/libgomp/testsuite/libgomp.c++/for-27.C
> > @@ -151,6 +151,12 @@ f4 (const I , const I )
> >   else if (results[i])  \
> > abort ()
> > +// FIXME: OpenMP seems to count on this being instantiated; the copy
> > +// constructor is called in functions fn2/fn3/fn4.  But in C++17 we
> > +// elide this copy constructor, so it's never been instantiated.  For
> > +// now instantiate it explicitly.
> 
> This sounds like a bug that needs to be fixed before the default can change.
> I guess the openmp code needs to mark_used the copy constructor or the like.

I'll have a look, though no guarantee I manage it this week.

Jakub

Re: [PATCH] c++: Change the default dialect to C++17.

[Jason Merrill via Gcc-patches]

On 5/16/20 6:34 PM, Marek Polacek wrote:

Since GCC 9, C++17 support is no longer experimental.  It was too late
to change the default C++ dialect to C++17 in GCC 10, but I think now
it's time to pull the trigger (C++14 was made the default in GCC 6.1).
We're still missing two C++17 library features, but that shouldn't stop
us.  See

and

for the C++17 status.

I won't list all C++17 features here, but just a few heads-up:

- trigraphs were removed (hardly anyone cares, unless your keyboard is
   missing the # key),
- operator++(bool) was removed (so some tests now run in C++14 and down
   only),
- the keyword register was removed (some legacy code might trip on
   this),
- noexcept specification is now part of the type system and C++17 does
   not allow dynamic exception specifications anymore (the empty throw
   specification is still available, but it is deprecated),
- the evaluation order rules are different in C++17,
- static constexpr data members are now implicitly inline (which makes
   them definitions),
- C++17 requires guaranteed copy elision, meaning that a copy/move
   constructor call might be elided completely.  That means that if
   something relied on a constructor being instantiated via e.g. copying
   a function parameter, it might now fail.

Jakub, the last point is actually what I encountered in for-27.C and it
looks like an OpenMP issue, in that it wrongly depends on an implicit
instantiation.  Am I mistaken?

Due to the 'register' removal, this patch depends on the regenerated
cfns.h version I posted earlier today.

I'll post an update for cxx-status.html and add a new caveat to changes.html
once this is in.

Bootstrapped/regtested on x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu,
and powerpc64le-unknown-linux-gnu.  Ok for trunk?

* doc/invoke.texi (C Dialect Options): Adjust -std default for C++.
* doc/standards.texi (C Language): Correct the default dialect.
(C++ Language): Update the default for C++ to gnu++17.

* c-opts.c (c_common_init_options): Default to gnu++17.

* c-c++-common/torture/vector-subscript-3.c: Remove the register
keywords.
* g++.dg/cpp1z/attributes-enum-1a.C: Update for C++17.
* g++.dg/cpp1z/fold7a.C: Likewise.
* g++.dg/cpp1z/nontype3a.C: Likewise.
* g++.dg/cpp1z/utf8-2a.C: Likewise.
* g++.dg/parse/error11.C: Use c++14_down.
* g++.dg/torture/pr34850.C: Add -Wno-attribute-warning.
* g++.dg/torture/pr49394.C: Add dg-warning.
* g++.dg/torture/pr82154.C: Use -std=c++14.
* g++.dg/ubsan/pr85029.C: Use -Wno-register.
* g++.dg/ubsan/vptr-12.C: Use -fstrong-eval-order=some.
* lib/target-supports.exp: Set to C++17.
* obj-c++.dg/try-catch-9.mm: Use -Wno-register.

* testsuite/libgomp.c++/atomic-3.C: Use -std=gnu++14.
* testsuite/libgomp.c++/for-27.C: Explicitly instantiate the
copy constructor for I.
---
  gcc/c-family/c-opts.c   | 4 ++--
  gcc/doc/invoke.texi | 2 +-
  gcc/doc/standards.texi  | 4 ++--
  gcc/testsuite/c-c++-common/torture/vector-subscript-3.c | 6 +++---
  gcc/testsuite/g++.dg/cpp1z/attributes-enum-1a.C | 4 ++--
  gcc/testsuite/g++.dg/cpp1z/fold7a.C | 4 ++--
  gcc/testsuite/g++.dg/cpp1z/nontype3a.C  | 4 ++--
  gcc/testsuite/g++.dg/cpp1z/utf8-2a.C| 4 ++--
  gcc/testsuite/g++.dg/parse/error11.C| 5 +++--
  gcc/testsuite/g++.dg/torture/pr34850.C  | 2 +-
  gcc/testsuite/g++.dg/torture/pr49394.C  | 2 +-
  gcc/testsuite/g++.dg/torture/pr82154.C  | 3 ++-
  gcc/testsuite/g++.dg/ubsan/pr85029.C| 2 +-
  gcc/testsuite/g++.dg/ubsan/vptr-12.C| 2 +-
  gcc/testsuite/lib/target-supports.exp   | 2 +-
  gcc/testsuite/obj-c++.dg/try-catch-9.mm | 2 +-
  libgomp/testsuite/libgomp.c++/atomic-3.C| 3 ++-
  libgomp/testsuite/libgomp.c++/for-27.C  | 6 ++
  18 files changed, 35 insertions(+), 26 deletions(-)

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 7695e88c130..5b266c06f3b 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -256,9 +256,9 @@ c_common_init_options (unsigned int decoded_options_count,
  }
  }
  
-  /* Set C++ standard to C++14 if not specified on the command line.  */

+  /* Set C++ standard to C++17 if not specified on the command line.  */
if (c_dialect_cxx ())
-set_std_cxx14 (/*ISO*/false);
+set_std_cxx17 (/*ISO*/false);
  
global_dc->colorize_source_p = true;

  }
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 850aeac033d..97e13421323 100644
--- 

Re: [PATCH] c++: Implement DR 1512, Pointer comparison vs qual convs [PR87699]

[Jason Merrill via Gcc-patches]

On 5/16/20 6:32 PM, Marek Polacek wrote:

+  const int q1 = cp_type_quals (pointee1);
+  const int q2 = cp_type_quals (pointee2);
+  const int quals = q1 | q2;
result_type = cp_build_qualified_type (result_type,
-(cp_type_quals (pointee1)
- | cp_type_quals (pointee2)));
+(quals | (*add_const
+  ? TYPE_QUAL_CONST
+  : TYPE_UNQUALIFIED)));


Since you're splitting out some of the arithmetic into local variables, 
why not handle *add_const there as well?


OK either way.

Jason

[committed] Replace in the release notes by .

[Gerald Pfeifer]

The validator triggered on another file that was recently edited,
and searching our whole tree for similar occurrences these two are
the remaining ones.

The only drawback is that ids must not start with a digit, so I used
ids in line with what we have in gcc-3.2/changes.html and later.

(I believe I may have missed the GCC 10 instance when originally making 
this kind of change, and as part of the GCC 10.1 release process the 
GCC 11 page was then cloned.)

Address thusly.

Gerald
---
 htdocs/gcc-10/changes.html | 2 +-
 htdocs/gcc-11/changes.html | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index fc58a471..0959e4c4 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -1075,7 +1075,7 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
 
 
 
-GCC 10.1
+GCC 10.1
 
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDresolution=FIXEDtarget_milestone=10.0;>list
 of problem reports (PRs) from GCC's bug tracking system that are
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 235d1f86..92920476 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -144,7 +144,7 @@ a work-in-progress.
 
 
 
-
+
 
 
 
-- 
2.26.2

Re: [PATCH] c++: Don't add built-in operator for ++ on bool.

[Jason Merrill via Gcc-patches]

On 5/16/20 6:33 PM, Marek Polacek wrote:

This feels extremely obscure but at least it's an opportunity to fix the
comments.  P0002R1 removed deprecated operator++(bool) in C++17 so let's
avoid adding a builtin overload candidate for ++ when the type is bool.

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


OK.


* call.c (add_builtin_candidate): Don't create a builtin overload
candidate for ++ when type is bool in C++17.

* g++.dg/overload/builtin5.C: New test.
---
  gcc/cp/call.c| 18 +++---
  gcc/testsuite/g++.dg/overload/builtin5.C | 21 +
  2 files changed, 32 insertions(+), 7 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/overload/builtin5.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c5871974eb1..b96bc06a364 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -2672,19 +2672,19 @@ add_builtin_candidate (struct z_candidate **candidates, 
enum tree_code code,
switch (code)
  {
  
-/* 4 For every pair T, VQ), where T is an arithmetic or  enumeration  type,

+/* 4 For every pair (T, VQ), where T is an arithmetic type other than bool,
   and  VQ  is  either  volatile or empty, there exist candidate operator
   functions of the form
 VQ T&   operator++(VQ T&);
 T   operator++(VQ T&, int);
-   5 For every pair T, VQ), where T is an enumeration type or an arithmetic
- type  other than bool, and VQ is either volatile or empty, there exist
- candidate operator functions of the form
+   5 For every pair (T, VQ), where T is an arithmetic type other than bool,
+ and VQ is either volatile or empty, there exist candidate operator
+ functions of the form
 VQ T&   operator--(VQ T&);
 T   operator--(VQ T&, int);
-   6 For every pair T, VQ), where T is  a  cv-qualified  or  cv-unqualified
- complete  object type, and VQ is either volatile or empty, there exist
- candidate operator functions of the form
+   6 For every pair (T, VQ), where T is a cv-qualified or cv-unqualified object
+ type, and VQ is either volatile or empty, there exist candidate operator
+ functions of the form
 T*VQ&   operator++(T*VQ&);
 T*VQ&   operator--(T*VQ&);
 T*  operator++(T*VQ&, int);
@@ -2697,6 +2697,10 @@ add_builtin_candidate (struct z_candidate **candidates, 
enum tree_code code,
/* FALLTHRU */
  case POSTINCREMENT_EXPR:
  case PREINCREMENT_EXPR:
+  /* P0002R1, Remove deprecated operator++(bool) added "other than bool"
+to p4.  */
+  if (TREE_CODE (type1) == BOOLEAN_TYPE && cxx_dialect >= cxx17)
+   return;
if (ARITHMETIC_TYPE_P (type1) || TYPE_PTROB_P (type1))
{
  type1 = build_reference_type (type1);
diff --git a/gcc/testsuite/g++.dg/overload/builtin5.C 
b/gcc/testsuite/g++.dg/overload/builtin5.C
new file mode 100644
index 000..a30251dc79d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/overload/builtin5.C
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++17 } }
+// Don't add built-in operator for ++ on bool.
+
+template
+struct S { operator T&(); };
+
+template void
+foo (S& s)
+{
+  --s; // { dg-error "no match for" }
+  ++s; // { dg-error "no match for" }
+  s++; // { dg-error "declared for postfix" }
+  s--; // { dg-error "declared for postfix" }
+}
+
+void
+bar ()
+{
+  S s;
+  foo<0> (s);
+}

base-commit: f5b461d453043c6b6dda50db0439e4c78b241f03

Re: [PATCH] c++: Regenerate cp/cfns.h.

[Jason Merrill via Gcc-patches]

On 5/16/20 6:33 PM, Marek Polacek wrote:

Current cfns.h includes register-qualified variables and that wouldn't
play well when bootstrapping with GCC that uses the C++17 dialect,
because 'register' was removed in C++17.  Regenerating it using the
command specified in cfns.h luckily cleaned this up.

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


OK.


* cfns.h: Regenerated.
---
  gcc/cp/cfns.h | 36 ++--
  1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h
index 55a962c8b91..26d90c26497 100644
--- a/gcc/cp/cfns.h
+++ b/gcc/cp/cfns.h
@@ -1,4 +1,4 @@
-/* C++ code produced by gperf version 3.0.4 */
+/* C++ code produced by gperf version 3.1 */
  /* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L C++ 
--output-file cfns.h cfns.gperf  */
  
  #if !((' ' == 32) && ('!' == 33) && ('"' == 34) && ('#' == 35) \

@@ -25,7 +25,7 @@
&& ('w' == 119) && ('x' == 120) && ('y' == 121) && ('z' == 122) \
&& ('{' == 123) && ('|' == 124) && ('}' == 125) && ('~' == 126))
  /* The character set is not based on ISO-646.  */
-#error "gperf generated tables don't work with this execution character set. Please 
report a bug to ."
+#error "gperf generated tables don't work with this execution character set. Please 
report a bug to ."
  #endif
  
  #line 4 "cfns.gperf"

@@ -54,13 +54,13 @@ struct libc_name_struct { const char *name; int c_ver; };
  class libc_name
  {
  private:
-  static inline unsigned int hash (const char *str, unsigned int len);
+  static inline unsigned int hash (const char *str, size_t len);
  public:
-  static const struct libc_name_struct *libc_name_p (const char *str, unsigned 
int len);
+  static const struct libc_name_struct *libc_name_p (const char *str, size_t 
len);
  };
  
  inline unsigned int

-libc_name::hash (register const char *str, register unsigned int len)
+libc_name::hash (const char *str, size_t len)
  {
static const unsigned short asso_values[] =
  {
@@ -91,34 +91,34 @@ libc_name::hash (register const char *str, register 
unsigned int len)
1488, 1488, 1488, 1488, 1488, 1488, 1488, 1488, 1488, 1488,
1488, 1488, 1488, 1488, 1488, 1488, 1488
  };
-  register int hval = len;
+  unsigned int hval = len;
  
switch (hval)

  {
default:
-hval += asso_values[(unsigned char)str[5]+1];
+hval += asso_values[static_cast(str[5]+1)];
/*FALLTHROUGH*/
case 5:
-hval += asso_values[(unsigned char)str[4]];
+hval += asso_values[static_cast(str[4])];
/*FALLTHROUGH*/
case 4:
-hval += asso_values[(unsigned char)str[3]];
+hval += asso_values[static_cast(str[3])];
/*FALLTHROUGH*/
case 3:
-hval += asso_values[(unsigned char)str[2]];
+hval += asso_values[static_cast(str[2])];
/*FALLTHROUGH*/
case 2:
-hval += asso_values[(unsigned char)str[1]+1];
+hval += asso_values[static_cast(str[1]+1)];
/*FALLTHROUGH*/
case 1:
-hval += asso_values[(unsigned char)str[0]];
+hval += asso_values[static_cast(str[0])];
  break;
  }
-  return hval + asso_values[(unsigned char)str[len - 1]];
+  return hval + asso_values[static_cast(str[len - 1])];
  }
  
  const struct libc_name_struct *

-libc_name::libc_name_p (register const char *str, register unsigned int len)
+libc_name::libc_name_p (const char *str, size_t len)
  {
enum
  {
@@ -1116,15 +1116,15 @@ libc_name::libc_name_p (register const char *str, 
register unsigned int len)
  
if (len <= MAX_WORD_LENGTH && len >= MIN_WORD_LENGTH)

  {
-  register int key = hash (str, len);
+  unsigned int key = hash (str, len);
  
-  if (key <= MAX_HASH_VALUE && key >= 0)

+  if (key <= MAX_HASH_VALUE)
  {
-  register int index = lookup[key];
+  int index = lookup[key];
  
if (index >= 0)

  {
-  register const char *s = wordlist[index].name;
+  const char *s = wordlist[index].name;
  
if (*str == *s && !strcmp (str + 1, s + 1))

  return [index];

base-commit: f5b461d453043c6b6dda50db0439e4c78b241f03

Re: Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

[Joel Brobecker]

Hi Peter and Segher,

> > You should always CC the PPC maintainers on PPC patches.
> > I've CC'd both Segher and David.

Thanks a lot for doing that. And well understood for future patches.

> > >>> This commit adds a powerpc_vsx_ok dg-require-effective-target directive
> > >>> to that test, and thus making it UNSUPPORTED instead.
> 
> > >>> * gcc.target/powerpc/pr71763.c: Require powerpc_vsx_ok.
> > >>> OK for master?
> 
> Yes.  Also okay for backports (8, 9, 10).
> 
> Thanks!
> 
> (Don't forget the changelog?)

Thank you, Segher. Pushed to master, and for 8, 9 and 10.

I did include the ChangeLog indeed. I tend to avoid sending them
in the diff, because they usually don't apply out of the box. I know
there are some ways to resolve the conflicts automatically. I haven't
gotten around to setting that up, but if this is causing any confusion
here, I'll make sure to include the ChangeLog diff in the patch as well.

Thanks again!
-- 
Joel

Re: [PATCH] Describe coding conventions surrounding "auto"

[Jason Merrill via Gcc-patches]

On 5/18/20 2:02 PM, Richard Sandiford wrote:

Martin Sebor  writes:

On 5/16/20 4:43 AM, Richard Sandiford wrote:

Sorry for the empty subject line earlier...

Jason Merrill  writes:

On Fri, May 15, 2020 at 9:47 PM Martin Sebor  wrote:


On 5/15/20 8:08 AM, Richard Sandiford wrote:

Those are all good examples.  Mind putting that into a patch
for the coding conventions?

How's this?  I added "new" expressions as another example of the
first category.

I'm sure I've missed other good uses, but we can always add to the
list later if necessary.

Thanks,
Richard


0001-Describe-coding-conventions-surrounding-auto.patch

   From 10b27e367de0fa9d5bf91544385401cdcbdb8c00 Mon Sep 17 00:00:00 2001
From: Richard Sandiford
Date: Fri, 15 May 2020 14:58:46 +0100
Subject: [PATCH] Describe coding conventions surrounding "auto"

---
htdocs/codingconventions.html | 53 +++
htdocs/codingrationale.html   | 17 +++
2 files changed, 70 insertions(+)

diff --git a/htdocs/codingconventions.html

b/htdocs/codingconventions.html

index f4732ef6..ae49fb91 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -51,6 +51,7 @@ the conventions separately from any other changes to

the code.

Language Use

Variable Definitions
+Use of auto
Struct Definitions
Class Definitions
Constructors and

Destructors

@@ -884,6 +885,58 @@ Variables may be simultaneously defined and tested

in control expressions.

Rationale and Discussion


+Use of auto
+
+auto should be used in the following circumstances:
+
+  when the expression gives the C++ type explicitly.  For

example

+
+
+if (auto *table = dyn_cast rtx_jump_table_data

* (insn)) // OK

+  ...
+if (rtx_jump_table_data *table = dyn_cast rtx_jump_table_data *

(insn))  // Avoid

+  ...
+auto *map = new hash_map tree, size_t;

  // OK

+hash_map tree, size_t *map = new hash_map tree, size_t;

// Avoid

+
+This rule does not apply to abbreviated type names embedded in
+an identifier, such as the result of tree_to_shwi.
+  
+  
+when the expression simply provides an alternative view of an

object

+and is bound to a read-only temporary.  For example:
+
+
+auto wioff = wi::to_wide (off); // OK
+wide_int wioff = wi::to_wide (off); // Avoid if wioff is read-only
+auto minus1 = std::shwi (-1, prec); // OK
+wide_int minus1 = std::shwi (-1, prec); // Avoid if minus1 is

read-only

+
+In principle this rule applies to other views of an object too,
+such as a reversed view of a list, or a sequential view of a
+hash_set.  It does not apply to general

temporaries.

+  
+  
+the type of an iterator.  For example:
+
+
+auto it = std::find (names.begin (), names.end (),

needle);// OK

+vector name_map::iterator it = std::find (names.begin (),
+names.end (), needle); //

Avoid

+  
+  
+the type of a lambda expression.  For example:
+
+
+auto f = [] (int x) { return x + 1; }; //

OK

+  
+
+
+auto should not be used in other contexts.


This seems like a severe (and unnecessary) restriction...


+
+
+Rationale and Discussion
+

Struct Definitions

diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..a919023c 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -50,6 +50,23 @@ if (info *q = get_any_available_info ()) {
}


+Use of auto
+
+The reason for preferring auto in expressions like:
+auto wioff = wi::to_wide (off);
+is that using the natural type of the expression is more efficient than
+converting it to types like wide_int.
+
+The reason for excluding other uses of auto is that
+in most other cases the type carries useful information.  For example:
+for (const std::pair const char *, tree

elt : indirect_pool)

+  ...
+makes it obvious that elt is a pair and gives the types of
+elt.first and elt.second.  In contrast:
+for (const auto elt : indirect_pool)
+  ...
+gives no immediate indication what elt is or what can
+be done with it.


...there are countless constructs in C++ 98 as well in C where there
is no such indication yet we don't (and very well can't) try to avoid
using them.  Examples include macros, members of structures defined
far away from the point of their use, results of ordinary function
calls, results of overloaded functions or templates, default function
arguments, default template parameters, etc.

By way of a random example from genrecog.c:

   int_set::iterator end
  = std::set_union (trans1->labels.begin (), trans1->labels.end (),
combined->begin (), combined->end (),
next->begin ());

There is no immediate indication precisely what type int_set::iterator
is.  All we can tell is that that it's some sort of an iterator, and
that should 

[patch] move array bounds checking into its own file

[Aldy Hernandez via Gcc-patches]

As a follow-up to the patch moving array bounds checking into its own 
class, this moves the class into its own files.  As I've mentioned 
previously, having it in tree-vrp just pollutes the file with unrelated 
stuff.


Jeff, I know you've mentioned you'd like to move the array bounds 
checking to the path isolation pass at some point.  Would the current 
approach work for you?  I'm ok, inasmuch as it's gone from tree-vrp.c, 
the file is bloated enough as it is.


Aldy
commit 6bc1b4c62b2704e18f5c8564e7fad144b63314b7
Author: Aldy Hernandez 
Date:   Sun May 17 15:03:20 2020 +0200

Move array bounds checking into its own file.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 60ff1ffceef..7e42099e03d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-05-17  Aldy Hernandez  
+
+	* Makefile.in (gimple-array-bounds.o): New.
+	* tree-vrp.h/cc: Move array bounds code...
+	* gimple-array-bounds.h/cc: ...here.
+
 2020-05-17  Aldy Hernandez  
 
 	Revert:
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 9ba21f735f6..fcf6db8afb4 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1349,6 +1349,7 @@ OBJS = \
 	ggc-common.o \
 	ggc-tests.o \
 	gimple.o \
+	gimple-array-bounds.o \
 	gimple-builder.o \
 	gimple-expr.o \
 	gimple-iterator.o \
diff --git a/gcc/gimple-array-bounds.cc b/gcc/gimple-array-bounds.cc
new file mode 100644
index 000..68ca1c5ee7a
--- /dev/null
+++ b/gcc/gimple-array-bounds.cc
@@ -0,0 +1,714 @@
+/* Array bounds checking.
+   Copyright (C) 2005-2020 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
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "tree.h"
+#include "gimple.h"
+#include "ssa.h"
+#include "gimple-array-bounds.h"
+#include "gimple-iterator.h"
+#include "gimple-walk.h"
+#include "tree-dfa.h"
+#include "fold-const.h"
+#include "diagnostic-core.h"
+#include "intl.h"
+#include "tree-vrp.h"
+#include "alloc-pool.h"
+#include "vr-values.h"
+#include "domwalk.h"
+#include "tree-cfg.h"
+
+// This purposely returns a value_range, not a value_range_equiv, to
+// break the dependency on equivalences for this pass.
+
+const value_range *
+array_bounds_checker::get_value_range (const_tree op)
+{
+  return ranges->get_value_range (op);
+}
+
+/* Checks one ARRAY_REF in REF, located at LOCUS. Ignores flexible
+   arrays and "struct" hacks. If VRP can determine that the array
+   subscript is a constant, check if it is outside valid range.  If
+   the array subscript is a RANGE, warn if it is non-overlapping with
+   valid range.  IGNORE_OFF_BY_ONE is true if the ARRAY_REF is inside
+   a ADDR_EXPR.  Returns true if a warning has been issued.  */
+
+bool
+array_bounds_checker::check_array_ref (location_t location, tree ref,
+   bool ignore_off_by_one)
+{
+  if (TREE_NO_WARNING (ref))
+return false;
+
+  tree low_sub = TREE_OPERAND (ref, 1);
+  tree up_sub = low_sub;
+  tree up_bound = array_ref_up_bound (ref);
+
+  /* Referenced decl if one can be determined.  */
+  tree decl = NULL_TREE;
+
+  /* Set for accesses to interior zero-length arrays.  */
+  bool interior_zero_len = false;
+
+  tree up_bound_p1;
+
+  if (!up_bound
+  || TREE_CODE (up_bound) != INTEGER_CST
+  || (warn_array_bounds < 2
+	  && array_at_struct_end_p (ref)))
+{
+  /* Accesses to trailing arrays via pointers may access storage
+	 beyond the types array bounds.  For such arrays, or for flexible
+	 array members, as well as for other arrays of an unknown size,
+	 replace the upper bound with a more permissive one that assumes
+	 the size of the largest object is PTRDIFF_MAX.  */
+  tree eltsize = array_ref_element_size (ref);
+
+  if (TREE_CODE (eltsize) != INTEGER_CST
+	  || integer_zerop (eltsize))
+	{
+	  up_bound = NULL_TREE;
+	  up_bound_p1 = NULL_TREE;
+	}
+  else
+	{
+	  tree ptrdiff_max = TYPE_MAX_VALUE (ptrdiff_type_node);
+	  tree maxbound = ptrdiff_max;
+	  tree arg = TREE_OPERAND (ref, 0);
+
+	  const bool compref = TREE_CODE (arg) == COMPONENT_REF;
+	  if (compref)
+	{
+	  /* Try to determine the size of the trailing array from
+		 its initializer (if it has one).  */
+	  if (tree refsize = component_ref_size (arg, _zero_len))
+		if (TREE_CODE (refsize) == INTEGER_CST)
+		  maxbound = refsize;
+	}
+
+	  if (maxbound == ptrdiff_max)
+	{
+	  /* Try to determine the 

Re: [patch] substitute_and_fold_engine merge with evrp domwalker

[Richard Biener via Gcc-patches]

On May 18, 2020 7:59:45 PM GMT+02:00, Aldy Hernandez via Gcc-patches 
 wrote:
>Howdy.
>
>The main evrp domwalker seems cut and pasted from the 
>substitute_and_fold_engine (or was it the other way around?).   Albeit,
>
>there are a few things that evrp does, like set up ranges, but these
>can 
>be set up with virtuals, and thus provide a general repository to do
>all 
>things subst & fold, which I think was the main idea.
>
>You will notice that the resulting evrp code becomes a handful of lines
>
>calling evrp_analyze to set up ranges.
>
>We've been playing with this approach on the ranger branch, and have 
>been able to use it to implement ranger-vrp in 24 lines, all while 
>sharing all the evrp folding code.  Granted, the ranger also needs 
>access to vr_values::simplify_using_ranges* which I have abstracted
>into 
>an independent class and will post as a follow-up.
>
>Also, for future-proofing, I have added a gimple statement argument to 
>get_value().  This provides context where a future ranger (evrp, VRP, 
>ranger, whatever) can provide better values depending on the statement 
>we are processing.

Ranges before or after the stmt?  There are currently conflicting uses... (I 
did have a patch to expose non-zeroness for integer division dividend but that 
causes some code to think this holds for the stmt itself).  So this has to be 
appearant from the API. 

Richard. 

>
>OK for mainline?
>
>Aldy

[patch] move value_range_equiv class to own file

[Aldy Hernandez via Gcc-patches]

We already moved the value_range class into its own class in the last 
release.  I think it's time to move the value_range_equiv stuff into its 
own class, as it's a distraction from the VRP code.


I've moved it to value-range-equiv.*, and gave it a semblance of order, 
by putting the constructors and setters at the beginning, the dumpers at 
the bottom, etc.


No functional changes.

OK for mainline?
Aldy
commit 10bcfd4659a32b1ef31eaa48f866311d53445de6
Author: Aldy Hernandez 
Date:   Sun May 17 14:55:51 2020 +0200

Move value_range_equiv code to its own file.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 9ba21f735f6..711d1fe308e 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1641,6 +1641,7 @@ OBJS = \
 	unique-ptr-tests.o \
 	valtrack.o \
 	value-range.o \
+	value-range-equiv.o \
 	value-prof.o \
 	var-tracking.o \
 	varasm.o \
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 4b5df543c00..953ca508fa2 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -67,6 +67,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "vr-values.h"
 #include "builtins.h"
 #include "range-op.h"
+#include "value-range-equiv.h"
 
 /* Set of SSA names found live during the RPO traversal of the function
for still active basic-blocks.  */
@@ -309,210 +310,6 @@ private:
 			const void *);
 };
 
-void
-value_range_equiv::set_equiv (bitmap equiv)
-{
-  if (undefined_p () || varying_p ())
-equiv = NULL;
-  /* Since updating the equivalence set involves deep copying the
- bitmaps, only do it if absolutely necessary.
-
- All equivalence bitmaps are allocated from the same obstack.  So
- we can use the obstack associated with EQUIV to allocate vr->equiv.  */
-  if (m_equiv == NULL
-  && equiv != NULL)
-m_equiv = BITMAP_ALLOC (equiv->obstack);
-
-  if (equiv != m_equiv)
-{
-  if (equiv && !bitmap_empty_p (equiv))
-	bitmap_copy (m_equiv, equiv);
-  else
-	bitmap_clear (m_equiv);
-}
-}
-
-/* Initialize value_range.  */
-
-void
-value_range_equiv::set (tree min, tree max, bitmap equiv,
-			value_range_kind kind)
-{
-  value_range::set (min, max, kind);
-  set_equiv (equiv);
-  if (flag_checking)
-check ();
-}
-
-value_range_equiv::value_range_equiv (tree min, tree max, bitmap equiv,
-  value_range_kind kind)
-{
-  m_equiv = NULL;
-  set (min, max, equiv, kind);
-}
-
-value_range_equiv::value_range_equiv (const value_range )
-{
-  m_equiv = NULL;
-  set (other.min(), other.max (), NULL, other.kind ());
-}
-
-/* Like set, but keep the equivalences in place.  */
-
-void
-value_range_equiv::update (tree min, tree max, value_range_kind kind)
-{
-  set (min, max,
-   (kind != VR_UNDEFINED && kind != VR_VARYING) ? m_equiv : NULL, kind);
-}
-
-/* Copy value_range in FROM into THIS while avoiding bitmap sharing.
-
-   Note: The code that avoids the bitmap sharing looks at the existing
-   this->m_equiv, so this function cannot be used to initalize an
-   object.  Use the constructors for initialization.  */
-
-void
-value_range_equiv::deep_copy (const value_range_equiv *from)
-{
-  set (from->min (), from->max (), from->m_equiv, from->m_kind);
-}
-
-void
-value_range_equiv::move (value_range_equiv *from)
-{
-  set (from->min (), from->max (), NULL, from->m_kind);
-  m_equiv = from->m_equiv;
-  from->m_equiv = NULL;
-}
-
-void
-value_range_equiv::check ()
-{
-  value_range::check ();
-  switch (m_kind)
-{
-case VR_UNDEFINED:
-case VR_VARYING:
-  gcc_assert (!m_equiv || bitmap_empty_p (m_equiv));
-default:;
-}
-}
-
-/* Return true if the bitmaps B1 and B2 are equal.  */
-
-static bool
-vrp_bitmap_equal_p (const_bitmap b1, const_bitmap b2)
-{
-  return (b1 == b2
-	  || ((!b1 || bitmap_empty_p (b1))
-	  && (!b2 || bitmap_empty_p (b2)))
-	  || (b1 && b2
-	  && bitmap_equal_p (b1, b2)));
-}
-
-/* Returns TRUE if THIS == OTHER.  Ignores the equivalence bitmap if
-   IGNORE_EQUIVS is TRUE.  */
-
-bool
-value_range_equiv::equal_p (const value_range_equiv ,
-			bool ignore_equivs) const
-{
-  return (value_range::equal_p (other)
-	  && (ignore_equivs
-	  || vrp_bitmap_equal_p (m_equiv, other.m_equiv)));
-}
-
-void
-value_range_equiv::set_undefined ()
-{
-  set (NULL, NULL, NULL, VR_UNDEFINED);
-}
-
-void
-value_range_equiv::set_varying (tree type)
-{
-  value_range::set_varying (type);
-  equiv_clear ();
-}
-
-void
-value_range_equiv::equiv_clear ()
-{
-  if (m_equiv)
-bitmap_clear (m_equiv);
-}
-
-/* Add VAR and VAR's equivalence set (VAR_VR) to the equivalence
-   bitmap.  If no equivalence table has been created, OBSTACK is the
-   obstack to use (NULL for the default obstack).
-
-   This is the central point where equivalence processing can be
-   turned on/off.  */
-
-void
-value_range_equiv::equiv_add (const_tree var,
-			  const value_range_equiv *var_vr,
-			  bitmap_obstack *obstack)
-{
-  if (!m_equiv)
-m_equiv = BITMAP_ALLOC (obstack);
-  unsigned ver = SSA_NAME_VERSION (var);
-  bitmap_set_bit 

Re: [PATCH] Describe coding conventions surrounding "auto"

[Richard Sandiford]

Martin Sebor  writes:
> On 5/16/20 4:43 AM, Richard Sandiford wrote:
>> Sorry for the empty subject line earlier...
>> 
>> Jason Merrill  writes:
>>> On Fri, May 15, 2020 at 9:47 PM Martin Sebor  wrote:
>>>
 On 5/15/20 8:08 AM, Richard Sandiford wrote:
>> Those are all good examples.  Mind putting that into a patch
>> for the coding conventions?
> How's this?  I added "new" expressions as another example of the
> first category.
>
> I'm sure I've missed other good uses, but we can always add to the
> list later if necessary.
>
> Thanks,
> Richard
>
>
> 0001-Describe-coding-conventions-surrounding-auto.patch
>
>   From 10b27e367de0fa9d5bf91544385401cdcbdb8c00 Mon Sep 17 00:00:00 2001
> From: Richard Sandiford
> Date: Fri, 15 May 2020 14:58:46 +0100
> Subject: [PATCH] Describe coding conventions surrounding "auto"
>
> ---
>htdocs/codingconventions.html | 53 +++
>htdocs/codingrationale.html   | 17 +++
>2 files changed, 70 insertions(+)
>
> diff --git a/htdocs/codingconventions.html
 b/htdocs/codingconventions.html
> index f4732ef6..ae49fb91 100644
> --- a/htdocs/codingconventions.html
> +++ b/htdocs/codingconventions.html
> @@ -51,6 +51,7 @@ the conventions separately from any other changes to
 the code.
>Language Use
>
>Variable Definitions
> +Use of auto
>Struct Definitions
>Class Definitions
>Constructors and
 Destructors
> @@ -884,6 +885,58 @@ Variables may be simultaneously defined and tested
 in control expressions.
>Rationale and Discussion
>
>
> +Use of auto
> +
> +auto should be used in the following circumstances:
> +
> +  when the expression gives the C++ type explicitly.  For
 example
> +
> +
> +if (auto *table = dyn_cast rtx_jump_table_data
 * (insn)) // OK
> +  ...
> +if (rtx_jump_table_data *table = dyn_cast rtx_jump_table_data *
 (insn))  // Avoid
> +  ...
> +auto *map = new hash_map tree, size_t;
  // OK
> +hash_map tree, size_t *map = new hash_map tree, size_t;
 // Avoid
> +
> +This rule does not apply to abbreviated type names embedded in
> +an identifier, such as the result of tree_to_shwi.
> +  
> +  
> +when the expression simply provides an alternative view of an
 object
> +and is bound to a read-only temporary.  For example:
> +
> +
> +auto wioff = wi::to_wide (off); // OK
> +wide_int wioff = wi::to_wide (off); // Avoid if wioff is read-only
> +auto minus1 = std::shwi (-1, prec); // OK
> +wide_int minus1 = std::shwi (-1, prec); // Avoid if minus1 is
 read-only
> +
> +In principle this rule applies to other views of an object too,
> +such as a reversed view of a list, or a sequential view of a
> +hash_set.  It does not apply to general
 temporaries.
> +  
> +  
> +the type of an iterator.  For example:
> +
> +
> +auto it = std::find (names.begin (), names.end (),
 needle);// OK
> +vector name_map::iterator it = std::find (names.begin (),
> +names.end (), needle); //
 Avoid
> +  
> +  
> +the type of a lambda expression.  For example:
> +
> +
> +auto f = [] (int x) { return x + 1; }; //
 OK
> +  
> +
> +
> +auto should not be used in other contexts.

 This seems like a severe (and unnecessary) restriction...

> +
> +
> +Rationale and Discussion
> +
>
>Struct Definitions
>
> diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
> index 0b44f1da..a919023c 100644
> --- a/htdocs/codingrationale.html
> +++ b/htdocs/codingrationale.html
> @@ -50,6 +50,23 @@ if (info *q = get_any_available_info ()) {
>}
>
>
> +Use of auto
> +
> +The reason for preferring auto in expressions like:
> +auto wioff = wi::to_wide (off);
> +is that using the natural type of the expression is more efficient than
> +converting it to types like wide_int.
> +
> +The reason for excluding other uses of auto is that
> +in most other cases the type carries useful information.  For example:
> +for (const std::pair const char *, tree
 elt : indirect_pool)
> +  ...
> +makes it obvious that elt is a pair and gives the types of
> +elt.first and elt.second.  In contrast:
> +for (const auto elt : indirect_pool)
> +  ...
> +gives no immediate indication what elt is or what can
> +be done with it.

 ...there are countless constructs in C++ 98 as well in C where there
 

[patch] substitute_and_fold_engine merge with evrp domwalker

[Aldy Hernandez via Gcc-patches]

Howdy.

The main evrp domwalker seems cut and pasted from the 
substitute_and_fold_engine (or was it the other way around?).   Albeit, 
there are a few things that evrp does, like set up ranges, but these can 
be set up with virtuals, and thus provide a general repository to do all 
things subst & fold, which I think was the main idea.


You will notice that the resulting evrp code becomes a handful of lines 
calling evrp_analyze to set up ranges.


We've been playing with this approach on the ranger branch, and have 
been able to use it to implement ranger-vrp in 24 lines, all while 
sharing all the evrp folding code.  Granted, the ranger also needs 
access to vr_values::simplify_using_ranges* which I have abstracted into 
an independent class and will post as a follow-up.


Also, for future-proofing, I have added a gimple statement argument to 
get_value().  This provides context where a future ranger (evrp, VRP, 
ranger, whatever) can provide better values depending on the statement 
we are processing.


OK for mainline?

Aldy
commit f90d4a08986e98cbcb827665d91759488c714075
Author: Aldy Hernandez 
Date:   Tue May 5 13:45:39 2020 +0200

Merge evrp uses of substitute_and_fold_engine into the engine itself.

This patch merges the evrp uses of the substitute and fold engine into
the engine itself, at least the parts that can be re-used by other
engine uses.  It also adds a context parameter to get_value() for
further use.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 51b5b6c908d..19e2509ab0e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,37 @@
+2020-05-18  Aldy Hernandez  
+
+	* gimple-loop-versioning.cc (loop_versioning::name_prop::get_value):
+	Add stmt parameter.
+	* gimple-ssa-evrp.c (class evrp_folder): New.
+	(class evrp_dom_walker): Remove.
+	(execute_early_vrp): Use evrp_folder instead of evrp_dom_walker.
+	* tree-ssa-ccp.c (ccp_folder::get_value): Add stmt parameter.
+	* tree-ssa-copy.c (copy_folder::get_value): Same.
+	* tree-ssa-propagate.c (substitute_and_fold_engine::replace_uses_in):
+	Pass stmt to get_value.
+	(substitute_and_fold_engine::replace_phi_args_in): Same.
+	(substitute_and_fold_dom_walker::after_dom_children): Call
+	post_fold_bb.
+	(substitute_and_fold_dom_walker::foreach_new_stmt_in_bb): New.
+	(substitute_and_fold_dom_walker::propagate_into_phi_args): New.
+	(substitute_and_fold_dom_walker::before_dom_children): Adjust to
+	call virtual functions for folding, pre_folding, and post folding.
+	Call get_value with PHI.  Tweak dump.
+	* tree-ssa-propagate.h (class substitute_and_fold_engine):
+	New argument to get_value.
+	New virtual function pre_fold_bb.
+	New virtual function post_fold_bb.
+	New virtual function pre_fold_stmt.
+	New virtual function post_new_stmt.
+	New function propagate_into_phi_args.
+	* tree-vrp.c (vrp_folder::get_value): Add stmt argument.
+	* vr-values.c (vr_values::extract_range_from_stmt): Adjust dump
+	output.
+	(vr_values::fold_cond): New.
+	(vr_values::simplify_cond_using_ranges_1): Call fold_cond.
+	* vr-values.h (class vr_values): Add
+	simplify_cond_using_ranges_when_edge_is_known.
+
 2020-05-18  Carl Love  
 
 	PR target/94833
diff --git a/gcc/gimple-loop-versioning.cc b/gcc/gimple-loop-versioning.cc
index ff6c561f9e2..002b2a68b96 100644
--- a/gcc/gimple-loop-versioning.cc
+++ b/gcc/gimple-loop-versioning.cc
@@ -277,7 +277,7 @@ private:
   {
   public:
 name_prop (loop_info ) : m_li (li) {}
-tree get_value (tree) FINAL OVERRIDE;
+tree get_value (tree, gimple *) FINAL OVERRIDE;
 
   private:
 /* Information about the versioning we've performed on the loop.  */
@@ -534,7 +534,8 @@ loop_versioning::lv_dom_walker::after_dom_children (basic_block bb)
Return the new value if so, otherwise return null.  */
 
 tree
-loop_versioning::name_prop::get_value (tree val)
+loop_versioning::name_prop::get_value (tree val,
+   gimple *stmt ATTRIBUTE_UNUSED)
 {
   if (TREE_CODE (val) == SSA_NAME
   && bitmap_bit_p (_li.unity_names, SSA_NAME_VERSION (val)))
diff --git a/gcc/gimple-ssa-evrp.c b/gcc/gimple-ssa-evrp.c
index 599e1459f00..af780fd0519 100644
--- a/gcc/gimple-ssa-evrp.c
+++ b/gcc/gimple-ssa-evrp.c
@@ -43,273 +43,68 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple-ssa-evrp-analyze.h"
 
 class evrp_folder : public substitute_and_fold_engine
-{
- public:
-  tree get_value (tree) FINAL OVERRIDE;
-  evrp_folder (class vr_values *vr_values_) : vr_values (vr_values_) { }
-  bool simplify_stmt_using_ranges (gimple_stmt_iterator *gsi)
-{ return vr_values->simplify_stmt_using_ranges (gsi); }
-  class vr_values *vr_values;
-
- private:
-  DISABLE_COPY_AND_ASSIGN (evrp_folder);
-};
-
-tree
-evrp_folder::get_value (tree op)
-{
-  return vr_values->op_with_constant_singleton_value_range (op);
-}
-
-/* evrp_dom_walker visits the basic blocks in the dominance order and set
-   the Value Ranges (VR) for SSA_NAMEs in the scope.  Use this VR to
-   discover more VRs.  */
-

[committed] c++: Add test for c++/95143

[Marek Polacek via Gcc-patches]

Already fixed by r10-8124-gceae6a13366d9646e172fc943fe8e221b70f0920.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/95143
* g++.dg/cpp0x/sfinae66.C: New test.
---
 gcc/testsuite/g++.dg/cpp0x/sfinae66.C | 32 +++
 1 file changed, 32 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/sfinae66.C

diff --git a/gcc/testsuite/g++.dg/cpp0x/sfinae66.C 
b/gcc/testsuite/g++.dg/cpp0x/sfinae66.C
new file mode 100644
index 000..49067cd35d0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/sfinae66.C
@@ -0,0 +1,32 @@
+// PR c++/95143
+// { dg-do compile { target c++11 } }
+
+struct false_type {
+  static constexpr bool value = false;
+};
+
+struct true_type{
+  static constexpr bool value = true;
+};
+
+template
+T&& declval() noexcept;
+
+template
+struct is_static_castable : false_type
+{};
+template
+struct is_static_castable(declval()))> : 
true_type
+{};
+
+class Base { };
+struct A { };
+class B: public Base { };
+
+int main()
+{
+  constexpr auto canCast = is_static_castable::value;
+  static_assert(!canCast, "");
+  constexpr auto canCast2 = is_static_castable::value;
+  static_assert(canCast2, "");
+}

base-commit: 24f68831d25bad739a6fe167a58b5b4c0c3cbf9a
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=. [wwwdocs]

[Eric Gallager via Gcc-patches]

On 5/10/20, Eric Gallager  wrote:
> On 1/10/20, Jason Merrill  wrote:
>> Back in 2009 Manuel sent a patch to avoid useless -Wconversion warnings
>> on compound assignment of types that get promoted to int:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2009-08/msg00582.html
>>
>> Joseph argued that those warnings are sometimes useful, and that they
>> should be controlled by a separate flag.  So this patch introduces
>> -Warith-conversion, which is off by default in this patch.
>>
>> Joseph, is that default OK with you?  If not, can you explain your
>> reasoning more about why the warnings are desirable?  It seems to me
>> that even in cases where you don't know the ranges involved, it's wrong
>> for e.g. 'mychar += 1' to warn when 'myint += 1' doesn't.  In both
>> cases, the addition might overflow the range of the target type, but
>> that isn't about the conversion; the result is the same as if the
>> operation had been done in the operand/target type rather than the
>> promoted type.
>>
>> The change to cp/typeck.c is a placeholder to use if the default setting
>> changes; even if we end up warning by default for mychar = mychar + 1, I
>> really don't want to warn about mychar += 1.
>>
>> sign.diff is a prerequisite tidying that moves the warnings from
>> unsafe_conversion_p back into conversion_warning with the others.
>>
>> rshift.diff restores the short_shift code to the C++ front end so that C
>> and C++ give the same warnings with -Warith-conversion.
>>
>> Tested x86_64-pc-linux-gnu.  Comments?
>>
>
> Hi Jason, thanks for this new flag. Now that GCC 10 has been released
> I was checking the release notes to review everything new in GCC 10,
> and I didn't see any mention of -Warith-conversion on it. Could you
> add a quick note about -Warith-conversion to changes.html please?
>
> Thanks,
> Eric
>

Something just like "Some warnings that -Wconversion previously issued
now also require -Warith-conversion" or something would be fine.

Re: [PATCH] Implement no_stack_protect attribute.

[Andreas Schwab]

On Mai 18 2020, Florian Weimer via Gcc-patches wrote:

> * Michael Matz:
>
>>> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at 
>>> all for some reason, the frame pointer is always missing?
>>
>> Not for me:
>
> I see.  I didn't know that -fno-omit-frame-pointer only applies to
> non-leaf functions.  For them, the behavior I see matches yours.

There is also -momit-leaf-frame-pointer.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] Fixes documentation for gimple_assign functions

[Erick Ochoa]

Hi,

I do not have write permissions. I was wondering if I could get write 
after approval permissions. I'm new to GCC but I would like to 
contribute as much as I can, even if it is just small fixes on 
documentations like the ones discussed here.


Thanks!

On 16/05/2020 19:57, Richard Biener wrote:

On May 16, 2020 11:42:02 AM GMT+02:00, Erick Ochoa 
 wrote:

Fixes documentation for gimple_assign functions

This patch corrects the documented function signatures of
gimple_assign*
functions.


OK.

Richard.


ChangeLog:

2020-05-16  Erick Ochoa 

* gcc/gimple.h (gimple_assign_rhs_code): Fix signature
(gimple_assign_rhs_class): same
(gimple_assign_lhs): same
(gimple_assign_lhs_ptr): same
(gimple_assign_rhs): same
(gimple_assign_rhs_ptr): same
(gimple_assign_rhs2): same
(gimple_assign_rh2_ptr): same
(gimple_assign_rhs3): same
(gimple_assign_rh3_ptr): same
(gimple_assign_set_lhs): same
(gimple_assign_set_rhs1): same
(gimple_assign_set_rhs2): same
(gimple_assign_set_rhs3): same
(gimple_assign_cast_p): same

diff --git a/gcc/doc/gimple.texi b/gcc/doc/gimple.texi
index 5e0fc2e0dc5..18264871e88 100644
--- a/gcc/doc/gimple.texi
+++ b/gcc/doc/gimple.texi
@@ -1184,73 +1184,73 @@ case they will be converted to a gimple operand

if necessary.

  This function returns the newly created @code{GIMPLE_ASSIGN} tuple.

-@deftypefn {GIMPLE function} {enum tree_code} gimple_assign_rhs_code
(gimple g)
+@deftypefn {GIMPLE function} {enum tree_code} gimple_assign_rhs_code
(const gimple *g)
  Return the code of the expression computed on the @code{RHS} of
  assignment statement @code{G}.
  @end deftypefn


-@deftypefn {GIMPLE function} {enum gimple_rhs_class}
gimple_assign_rhs_class (gimple g)
+@deftypefn {GIMPLE function} {enum gimple_rhs_class}
gimple_assign_rhs_class (const gimple *g)
  Return the gimple rhs class of the code for the expression
computed on the rhs of assignment statement @code{G}.  This will never
  return @code{GIMPLE_INVALID_RHS}.
  @end deftypefn

-@deftypefn {GIMPLE function} tree gimple_assign_lhs (gimple g)
+@deftypefn {GIMPLE function} tree gimple_assign_lhs (const gimple *g)
  Return the @code{LHS} of assignment statement @code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} {tree *} gimple_assign_lhs_ptr (gimple g)
+@deftypefn {GIMPLE function} {tree *} gimple_assign_lhs_ptr (gimple
*g)
  Return a pointer to the @code{LHS} of assignment statement @code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} tree gimple_assign_rhs1 (gimple g)
+@deftypefn {GIMPLE function} tree gimple_assign_rhs1 (const gimple *g)
  Return the first operand on the @code{RHS} of assignment statement
@code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} {tree *} gimple_assign_rhs1_ptr (gimple
g)
+@deftypefn {GIMPLE function} {tree *} gimple_assign_rhs1_ptr (gimple
*g)
Return the address of the first operand on the @code{RHS} of assignment
  statement @code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} tree gimple_assign_rhs2 (gimple g)
+@deftypefn {GIMPLE function} tree gimple_assign_rhs2 (const gimple *g)
  Return the second operand on the @code{RHS} of assignment statement
@code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} {tree *} gimple_assign_rhs2_ptr (gimple
g)
+@deftypefn {GIMPLE function} {tree *} gimple_assign_rhs2_ptr (gimple
*g)
Return the address of the second operand on the @code{RHS} of
assignment
  statement @code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} tree gimple_assign_rhs3 (gimple g)
+@deftypefn {GIMPLE function} tree gimple_assign_rhs3 (const gimple *g)
  Return the third operand on the @code{RHS} of assignment statement
@code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} {tree *} gimple_assign_rhs3_ptr (gimple
g)
+@deftypefn {GIMPLE function} {tree *} gimple_assign_rhs3_ptr (gimple
*g)
Return the address of the third operand on the @code{RHS} of assignment
  statement @code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} void gimple_assign_set_lhs (gimple g,
tree
lhs)
+@deftypefn {GIMPLE function} void gimple_assign_set_lhs (gimple *g,
tree lhs)
  Set @code{LHS} to be the @code{LHS} operand of assignment statement
@code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} void gimple_assign_set_rhs1 (gimple g,
tree rhs)
+@deftypefn {GIMPLE function} void gimple_assign_set_rhs1 (gimple *g,
tree rhs)
Set @code{RHS} to be the first operand on the @code{RHS} of assignment
  statement @code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} void gimple_assign_set_rhs2 (gimple g,
tree rhs)
+@deftypefn {GIMPLE function} void gimple_assign_set_rhs2 (gimple *g,
tree rhs)
Set @code{RHS} to be the second operand on the @code{RHS} of assignment
  statement @code{G}.
  @end deftypefn

-@deftypefn {GIMPLE function} void gimple_assign_set_rhs3 (gimple g,
tree rhs)
+@deftypefn {GIMPLE function} void gimple_assign_set_rhs3 (gimple *g,
tree rhs)
Set @code{RHS} 

Re: [PATCH] Describe coding conventions surrounding "auto"

[Martin Sebor via Gcc-patches]

On 5/16/20 4:43 AM, Richard Sandiford wrote:

Sorry for the empty subject line earlier...

Jason Merrill  writes:

On Fri, May 15, 2020 at 9:47 PM Martin Sebor  wrote:


On 5/15/20 8:08 AM, Richard Sandiford wrote:

Those are all good examples.  Mind putting that into a patch
for the coding conventions?

How's this?  I added "new" expressions as another example of the
first category.

I'm sure I've missed other good uses, but we can always add to the
list later if necessary.

Thanks,
Richard


0001-Describe-coding-conventions-surrounding-auto.patch

  From 10b27e367de0fa9d5bf91544385401cdcbdb8c00 Mon Sep 17 00:00:00 2001
From: Richard Sandiford
Date: Fri, 15 May 2020 14:58:46 +0100
Subject: [PATCH] Describe coding conventions surrounding "auto"

---
   htdocs/codingconventions.html | 53 +++
   htdocs/codingrationale.html   | 17 +++
   2 files changed, 70 insertions(+)

diff --git a/htdocs/codingconventions.html

b/htdocs/codingconventions.html

index f4732ef6..ae49fb91 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -51,6 +51,7 @@ the conventions separately from any other changes to

the code.

   Language Use
   
   Variable Definitions
+Use of auto
   Struct Definitions
   Class Definitions
   Constructors and

Destructors

@@ -884,6 +885,58 @@ Variables may be simultaneously defined and tested

in control expressions.

   Rationale and Discussion
   

+Use of auto
+
+auto should be used in the following circumstances:
+
+  when the expression gives the C++ type explicitly.  For

example

+
+
+if (auto *table = dyn_cast rtx_jump_table_data

* (insn)) // OK

+  ...
+if (rtx_jump_table_data *table = dyn_cast rtx_jump_table_data *

(insn))  // Avoid

+  ...
+auto *map = new hash_map tree, size_t;

 // OK

+hash_map tree, size_t *map = new hash_map tree, size_t;

// Avoid

+
+This rule does not apply to abbreviated type names embedded in
+an identifier, such as the result of tree_to_shwi.
+  
+  
+when the expression simply provides an alternative view of an

object

+and is bound to a read-only temporary.  For example:
+
+
+auto wioff = wi::to_wide (off); // OK
+wide_int wioff = wi::to_wide (off); // Avoid if wioff is read-only
+auto minus1 = std::shwi (-1, prec); // OK
+wide_int minus1 = std::shwi (-1, prec); // Avoid if minus1 is

read-only

+
+In principle this rule applies to other views of an object too,
+such as a reversed view of a list, or a sequential view of a
+hash_set.  It does not apply to general

temporaries.

+  
+  
+the type of an iterator.  For example:
+
+
+auto it = std::find (names.begin (), names.end (),

needle);// OK

+vector name_map::iterator it = std::find (names.begin (),
+names.end (), needle); //

Avoid

+  
+  
+the type of a lambda expression.  For example:
+
+
+auto f = [] (int x) { return x + 1; }; //

OK

+  
+
+
+auto should not be used in other contexts.


This seems like a severe (and unnecessary) restriction...


+
+
+Rationale and Discussion
+

   Struct Definitions

diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..a919023c 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -50,6 +50,23 @@ if (info *q = get_any_available_info ()) {
   }
   

+Use of auto
+
+The reason for preferring auto in expressions like:
+auto wioff = wi::to_wide (off);
+is that using the natural type of the expression is more efficient than
+converting it to types like wide_int.
+
+The reason for excluding other uses of auto is that
+in most other cases the type carries useful information.  For example:
+for (const std::pair const char *, tree

elt : indirect_pool)

+  ...
+makes it obvious that elt is a pair and gives the types of
+elt.first and elt.second.  In contrast:
+for (const auto elt : indirect_pool)
+  ...
+gives no immediate indication what elt is or what can
+be done with it.


...there are countless constructs in C++ 98 as well in C where there
is no such indication yet we don't (and very well can't) try to avoid
using them.  Examples include macros, members of structures defined
far away from the point of their use, results of ordinary function
calls, results of overloaded functions or templates, default function
arguments, default template parameters, etc.

By way of a random example from genrecog.c:

  int_set::iterator end
 = std::set_union (trans1->labels.begin (), trans1->labels.end (),
   combined->begin (), combined->end (),
   next->begin ());

There is no immediate indication precisely what type int_set::iterator
is.  All we can tell is that that it's some sort of an iterator, and
that should be good enough.  It lets us (even forces us to) write code
that satisfies the 

[committed] wwwdocs: add GCC 10 jit changes

[David Malcolm via Gcc-patches]

I've gone ahead and pushed this patch to the website.

No new validation errors.

---
 htdocs/gcc-10/changes.html | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 2bc25d92..abbafa58 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -632,7 +632,21 @@ int get_naïve_pi() {
 
 
 
-
+libgccjit
+
+  
+The libgccjit API gained four new entry points:
+
+  
+   https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#c.gcc_jit_version_major;>gcc_jit_version_major,
+   https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#c.gcc_jit_version_minor;>gcc_jit_version_minor,
 and
+   https://gcc.gnu.org/onlinedocs/jit/topics/compatibility.html#c.gcc_jit_version_patchlevel;>gcc_jit_version_patchlevel
+   for programmatically checking the libgccjit version from client code, 
and
+  
+  https://gcc.gnu.org/onlinedocs/jit/topics/types.html#c.gcc_jit_context_new_bitfield;>gcc_jit_context_new_bitfield
+
+  
+
 
 
 New Targets and Target Specific Improvements
-- 
2.21.0

Re: [PATCH] Implement no_stack_protect attribute.

[Michael Matz]

Hello,

On Mon, 18 May 2020, Florian Weimer wrote:

> * Michael Matz:
> 
> >> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at 
> >> all for some reason, the frame pointer is always missing?
> >
> > Not for me:
> 
> I see.  I didn't know that -fno-omit-frame-pointer only applies to
> non-leaf functions.

Yeah, I actually consider this a bug as well (unrelated though).  The user 
of that flag quite surely has good reasons to want to have a frame 
pointer, and those good reasons usually extend to all functions, not just 
to leaf ones.  (E.g. ensuring that backtraces from async signal handlers 
are meaningful, for instance for poor mans profiling).


Ciao,
Michael.

Re: [PATCH] Implement no_stack_protect attribute.

[Florian Weimer via Gcc-patches]

* Michael Matz:

>> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at 
>> all for some reason, the frame pointer is always missing?
>
> Not for me:

I see.  I didn't know that -fno-omit-frame-pointer only applies to
non-leaf functions.  For them, the behavior I see matches yours.

Thanks,
Florian

[committed] i386: Avoid reversing a non-trapping comparison to a trapping one [PR95169]

[Uros Bizjak via Gcc-patches]

gcc/ChangeLog:

2020-05-18  Uroš Bizjak  

PR target/95169
* config/i386/i386-expand.c (ix86_expand_int_movcc):
 Avoid reversing a non-trapping comparison to a trapping one.

testsuite/ChangeLog:

2020-05-18  Uroš Bizjak  

PR target/95169
* gcc.target/i386/pr95169.c: New test.

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

Uros.
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 2865cced66c..79f827fd653 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -3057,11 +3057,14 @@ ix86_expand_int_movcc (rtx operands[])
{
  gcc_assert (!DECIMAL_FLOAT_MODE_P (cmp_mode));
 
- /* We may be reversing unordered compare to normal compare, that
-is not valid in general (we may convert non-trapping condition
-to trapping one), however on i386 we currently emit all
-comparisons unordered.  */
- new_code = reverse_condition_maybe_unordered (code);
+ /* We may be reversing a non-trapping
+comparison to a trapping comparison.  */
+ if (HONOR_NANS (cmp_mode) && flag_trapping_math
+ && code != EQ && code != NE
+ && code != ORDERED && code != UNORDERED)
+   new_code = UNKNOWN;
+ else
+   new_code = reverse_condition_maybe_unordered (code);
}
  else
new_code = ix86_reverse_condition (code, cmp_mode);
@@ -3213,11 +3216,15 @@ ix86_expand_int_movcc (rtx operands[])
{
  gcc_assert (!DECIMAL_FLOAT_MODE_P (cmp_mode));
 
- /* We may be reversing unordered compare to normal compare,
-that is not valid in general (we may convert non-trapping
-condition to trapping one), however on i386 we currently
-emit all comparisons unordered.  */
- new_code = reverse_condition_maybe_unordered (code);
+ /* We may be reversing a non-trapping
+comparison to a trapping comparison.  */
+ if (HONOR_NANS (cmp_mode) && flag_trapping_math
+ && code != EQ && code != NE
+ && code != ORDERED && code != UNORDERED)
+   new_code = UNKNOWN;
+ else
+   new_code = reverse_condition_maybe_unordered (code);
+
}
  else
{
diff --git a/gcc/testsuite/gcc.target/i386/pr95169.c 
b/gcc/testsuite/gcc.target/i386/pr95169.c
new file mode 100644
index 000..91411744228
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr95169.c
@@ -0,0 +1,28 @@
+/* PR target/95169 */
+/* { dg-do run { target ia32 } } */
+/* { dg-options "-O0 -march=i386 -mtune=generic" } */
+/* { dg-require-effective-target fenv_exceptions } */
+
+#include 
+
+void
+f (double y)
+{
+  if (__builtin_expect (y == 0.0, 0))
+__builtin_abort ();
+}
+
+int
+main (void)
+{
+  double y = __builtin_nan ("");
+
+  feclearexcept (FE_INVALID);
+
+  f (y);
+
+  if (fetestexcept (FE_INVALID))
+__builtin_abort ();
+
+  return 0;
+}

Re: [PATCH] Implement no_stack_protect attribute.

[Michael Matz]

Hello,

On Mon, 18 May 2020, Florian Weimer wrote:

> >> In glibc, we already have this:
> >> 
> >> /* Used to disable stack protection in sensitive places, like ifunc
> >>resolvers and early static TLS init.  */
> >> #ifdef HAVE_CC_NO_STACK_PROTECTOR
> >> # define inhibit_stack_protector \
> >> __attribute__ ((__optimize__ ("-fno-stack-protector")))
> >> #else
> >> # define inhibit_stack_protector
> >> #endif
> >> 
> >> Is it broken?
> >
> > Depends on what your expectations are.  It completely overrides all 
> > options given on the command line (including things like 
> > fno-omit-frame-pointer and -O2!).  At least I was very surprised by that 
> > even though the current docu can be read that way; if you're similarly 
> > surprised, then yes, the above is broken, it does not only disable stack 
> > protection (but also e.g. all optimizations, despite the attributes name 
> > :-) ).
> 
> Yes, that would qualify as broken.
> 
> This is not what I observe with gcc-9.3.1-2.fc31.x86_64 from Fedora.
> -O2 still has an effect.

Indeed, I definitely remember an interaction with the attribute and -O{,2} 
(or something that I interpreted as such) but it obviously isn't as simple 
as plain disabling it, and right now I can't recreate the situation :-/
(It might be disabling of some further cmdline flags that I conflated in 
my brain with "effect of -O2")

> So does -fcf-protection. -fno-omit-frame-pointer does not work for me at 
> all for some reason, the frame pointer is always missing?

Not for me:

% cat simple.c
extern int bla(int *);
int
#ifdef ATTR
__attribute__((__optimize__ ("-fno-stack-protector")))
#endif
foo(int a, int b)
{
  int c = b;
  return a * 42 + bla();
}
% gcc-9 -fno-omit-frame-pointer -O -S -o - tryme.c | grep bp
pushq   %rbp
movq%rsp, %rbp
movl%esi, -20(%rbp)
leaq-20(%rbp), %rdi
popq%rbp
% gcc-9 -fstack-protector-all -fno-omit-frame-pointer -O -S -o - tryme.c | grep 
bp
pushq   %rbp
movq%rsp, %rbp
movq%rax, -24(%rbp)
movl%esi, -28(%rbp)
leaq-28(%rbp), %rdi
movq-24(%rbp), %rdx
popq%rbp

But using the attr:

% gcc-9 -DATTR -fstack-protector-all -fno-omit-frame-pointer -O -S -o - tryme.c 
| grep bp
% 

(gcc9 is gcc9-9.2.1+r275327-1.1.x86_64 on opensuse)


Ciao,
Michael.

RE: [PATCH] [arm] Don't generate invalid LDRD insns

[Alex Coplan]

> -Original Message-
> From: Kyrylo Tkachov 
> Sent: 15 May 2020 11:57
> To: Alex Coplan ; gcc-patches@gcc.gnu.org
> Cc: nd ; ni...@redhat.com; Richard Earnshaw
> ; Ramana Radhakrishnan 
> 
> Subject: RE: [PATCH] [arm] Don't generate invalid LDRD insns
> 
> Hi Alex,
> 
> > -Original Message-
> > From: Alex Coplan 
> > Sent: 15 May 2020 11:36
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; ni...@redhat.com; Richard Earnshaw
> > ; Ramana Radhakrishnan
> > ; Kyrylo Tkachov
> > 
> > Subject: [PATCH] [arm] Don't generate invalid LDRD insns
> >
> > Hello,
> >
> > This patch fixes a bug in the arm backend where GCC generates invalid LDRD
> > instructions. The LDRD instruction requires the first transfer register to 
> > be
> > even, but GCC attempts to use odd registers here. For example, with the
> > following C code:
> >
> > struct c {
> >   double a;
> > } __attribute((aligned)) __attribute((packed));
> > struct c d;
> > struct c f(struct c);
> > void e() { f(d); }
> >
> > The struct d is passed in registers r1 and r2 to the function f, and GCC
> > attempts to do this with a LDRD instruction when compiling with -
> > march=armv7-a
> > on a soft float toolchain.
> >
> > The fix is analogous to the corresponding one for STRD in the same function:
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=52057dc4ac5295caebf83147f6
> > 88d769c93cbc8d
> >
> > Testing:
> >  - New unit tests which pass after applying the patch.
> >  - Tested on an x64 -> arm-none-eabi cross.
> >  - Bootstrapped and regtested on arm-none-linux-gnueabihf (in both thumb
> > and arm
> >modes).
> >
> > OK for master?
> 
> Ok.
> Please apply for write-after-approval commit access to the repo by filling the
> form at:
> https://sourceware.org/cgi-bin/pdw/ps_form.cgi
> listing me as your sponsor.
> You can then push the patch yourself.

OK, I've pushed the patch to master.

Thanks,
Alex

> 
> Thanks,
> Kyrill
> 
> >
> > Thanks,
> > Alex
> >
> > ---
> >
> > gcc/ChangeLog:
> >
> > 2020-05-15  Alex Coplan  
> > * config/arm/arm.c (output_move_double): Fix codegen when loading
> > into
> > a register pair with an odd base register.
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2020-05-15  Alex Coplan  
> > * gcc.c-torture/compile/packed-aligned-1.c: New test.
> > * gcc.c-torture/execute/packed-aligned.c: New test.
> 

Re: [PATCH][RFC] enfoce SLP_TREE_VECTYPE on invariants

[Richard Sandiford]

Richard Biener  writes:
> Hi,
>
> I'm trying to enforce SLP_TREE_VECTYPE being set (correctly) on
> external and invariant SLP nodes to avoid (re-)computing that
> in other places.

Nice.

> The responsible entity for specifying the
> desired vector type is vectorizable_* - vectorization analysis
> of the user (when we start to share those nodes between multiple
> users a user can then also unshare such a node if an existing
> vector type conflicts with its own requirements).
>
> The previous patch 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545938.html
> set up things so that vect_slp_analyze_node_operations would
> use such type information during costing and also pick up
> unshared nodes.
>
> Now as you can see below where I started to enforce SLP_TREE_VECTYPE
> for the special boolean case in vect_get_constant_vectors I seemingly
> only had to fixup two places, vectorizable_operation (saw bool & bool)
> and vectorizable_comparison doing testing on x86_64 and aarch64
> (cross cc1 on aarch64-sve.exp and vect.exp).  There obviously will
> be more places and I was thinking of less ugly (and more correct?)
> ways than doing
>
> + FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (slp_node), i, child)
> +   if (SLP_TREE_DEF_TYPE (child) != vect_internal_def)
> + SLP_TREE_VECTYPE (child) = vectype;
>
> in each vectorizable_*.  In principle it is the vect_is_simple_use
> that would need adjustment to associate the correct SLP child with
> a vectype so I can't think of sth better than refactoring things
> to sth like
>
>   vect_simple_uses (vinfo, stmt_info, slp_node, , )
>
> and process all operans at once transparently for stmt_info/slp_node
> (where the actual vect_is_simple_use check is redundant for SLP
> nodes anyway).  The index into the array would then match up
> with the SLP child (if SLP) or the stmt operand (if not SLP - with
> SLP the order can be different on the stmt).
>
> Any better ideas or comments on the general direction?  Richard,
> which vectorizable_* do you remember being the "worst" with respect
> to vector type determining for invariants?

I think most of the struggles I had were from different code ending
up with different results when recomputing the vectype.  IIRC the
vectorizable_* routines usually got it right and it was the other
code that got it wrong.  So yeah, can imagine that we don't need
many changes if the vectoriable_* routines get the final say.

Not related to invariants specifically, but the routines I remember
being most awkward for vector type choices were vectorizable_condition
(because of the embedded comparison) and vectorizable_conversion (because
there could be multiple stages, with the intermediate vector types not
being recorded).

OTOH, I think calculating the ideal vector types requires
propagating the vector type in both directions, rather than
just upwards from the roots.  E.g. for:

  double d1, d2, d3, d4;
  float f1, f2, f3;

  f1 = d1 == d2 & d3 == d4 ? f2 : f3;

when operating on full vectors, there needs to be a conversion
somewhere between "d-booleans" and "f-booleans".  For this case
it probably should happen as early as possible, e.g.:

  b1_lo = d1_lo == d2_lo
  b1_hi = d1_hi == d2_hi

  b2_lo = d3_lo == d4_lo
  b2_hi = d3_hi == d4_hi

  b1 = pack (b1_lo, b1_hi)

  b2 = pack (b2_lo, b2_hi)

  b3 = b1 & b2

  f1 = b3 ? f2 : f3;

But if the roles are reversed:

  float f1, f2, f3, f4;
  double d1, d2, d3;

  d1 = f1 == f2 & f3 == f4 ? d2 : d3;

it should happen after the "&":

  b1 = f1 == f2

  b2 = f3 == f4

  b3 = b1 & b2

  b3_lo = unpack_lo (b3)
  b3_hi = unpack_hi (b3)

  d1_lo = b3_lo ? d2_lo : d3_lo;
  d1_hi = b3_hi ? d2_hi : d3_hi;

At the moment we rely on pattern matching for that.  But it basically
means that the pattern matcher has to "predict" what vector types the
vectorizable_* routines would calculate, so that it knows whether to
create pattern statements that enforce a different choice.

IMO it'd be really good to get rid of that and unify the vector
type calculation.  But that probably means not doing it during
vectorizable_*, or at least changing the way that the vectorizable_*
functions are called during analysis, so that information can flow in
both directions.

Thanks,
Richard

[committed] i386: Improve vector mode and TFmode ABS and NEG patterns

[Uros Bizjak via Gcc-patches]

gcc/ChangeLog:

2020-05-18  Uroš Bizjak  

* config/i386/i386-expand.c (ix86_expand_fp_absneg_operator):
Do not emit FLAGS_REG clobber for TFmode.
* config/i386/i386.md (*tf2_1): Rewrite as
define_insn_and_split.  Mark operands 1 and 2 commutative.
(*nabstf2_1): Ditto.
(absneg SSE splitter): Use MODEF mode iterator instead of SSEMODEF.
Do not swap memory operands.  Simplify RTX generation.
(neg abs SSE splitter): Ditto.
* config/i386/sse.md (*2): Mark operands 1 and 2
commutative.  Do not swap operands.  Simplify RTX generation.
(*nabs2): Ditto.

No functional changes.

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

Uros.
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 26531585c5f..2865cced66c 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -1716,9 +1716,7 @@ ix86_expand_fp_absneg_operator (enum rtx_code code, 
machine_mode mode,
   machine_mode vmode = mode;
   rtvec par;
 
-  if (vector_mode)
-use_sse = true;
-  else if (mode == TFmode)
+  if (vector_mode || mode == TFmode)
 use_sse = true;
   else if (TARGET_SSE_MATH)
 {
@@ -1743,7 +1741,7 @@ ix86_expand_fp_absneg_operator (enum rtx_code code, 
machine_mode mode,
 Create the appropriate mask now.  */
   mask = ix86_build_signbit_mask (vmode, vector_mode, code == ABS);
   use = gen_rtx_USE (VOIDmode, mask);
-  if (vector_mode)
+  if (vector_mode || mode == TFmode)
par = gen_rtvec (2, set, use);
   else
{
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 9fd32f28bf3..aa4f25b7065 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -10005,32 +10005,6 @@
   [(set_attr "type" "negnot")
(set_attr "mode" "")])
 
-(define_expand "tf2"
-  [(set (match_operand:TF 0 "register_operand")
-   (absneg:TF (match_operand:TF 1 "register_operand")))]
-  "TARGET_SSE"
-  "ix86_expand_fp_absneg_operator (, TFmode, operands); DONE;")
-
-(define_insn "*tf2_1"
-  [(set (match_operand:TF 0 "register_operand" "=x,x,Yv,Yv")
-   (absneg:TF
- (match_operand:TF 1 "vector_operand" "0,xBm,Yv,m")))
-   (use (match_operand:TF 2 "vector_operand" "xBm,0,Yvm,Yv"))
-   (clobber (reg:CC FLAGS_REG))]
-  "TARGET_SSE"
-  "#"
-  [(set_attr "isa" "noavx,noavx,avx,avx")])
-
-(define_insn "*nabstf2_1"
-  [(set (match_operand:TF 0 "register_operand" "=x,x,Yv,Yv")
-   (neg:TF
- (abs:TF
-   (match_operand:TF 1 "vector_operand" "0,xBm,Yv,m"
-   (use (match_operand:TF 2 "vector_operand" "xBm,0,Yvm,Yv"))]
-  "TARGET_SSE"
-  "#"
-  [(set_attr "isa" "noavx,noavx,avx,avx")])
-
 ;; Special expand pattern to handle integer mode abs
 
 (define_expand "abs2"
@@ -10056,6 +10030,39 @@
 DONE;
   })
 
+(define_expand "tf2"
+  [(set (match_operand:TF 0 "register_operand")
+   (absneg:TF (match_operand:TF 1 "register_operand")))]
+  "TARGET_SSE"
+  "ix86_expand_fp_absneg_operator (, TFmode, operands); DONE;")
+
+(define_insn_and_split "*tf2_1"
+  [(set (match_operand:TF 0 "register_operand" "=x,Yv")
+   (absneg:TF
+ (match_operand:TF 1 "vector_operand" "%0,Yv")))
+   (use (match_operand:TF 2 "vector_operand" "xBm,Yvm"))]
+  "TARGET_SSE"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 0)
+   (:TF (match_dup 1) (match_dup 2)))]
+  ""
+  [(set_attr "isa" "noavx,avx")])
+
+(define_insn_and_split "*nabstf2_1"
+  [(set (match_operand:TF 0 "register_operand" "=x,Yv")
+   (neg:TF
+ (abs:TF
+   (match_operand:TF 1 "vector_operand" "%0,Yv"
+   (use (match_operand:TF 2 "vector_operand" "xBm,Yvm"))]
+  "TARGET_SSE"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 0)
+   (ior:TF (match_dup 1) (match_dup 2)))]
+  ""
+  [(set_attr "isa" "noavx,avx")])
+
 (define_expand "2"
   [(set (match_operand:X87MODEF 0 "register_operand")
(absneg:X87MODEF (match_operand:X87MODEF 1 "register_operand")))]
@@ -10108,36 +10115,24 @@
 (symbol_ref "false"])
 
 (define_split
-  [(set (match_operand:SSEMODEF 0 "sse_reg_operand")
-   (absneg:SSEMODEF
- (match_operand:SSEMODEF 1 "vector_operand")))
+  [(set (match_operand:MODEF 0 "sse_reg_operand")
+   (absneg:MODEF
+ (match_operand:MODEF 1 "vector_operand")))
(use (match_operand: 2 "vector_operand"))
(clobber (reg:CC FLAGS_REG))]
-  "((SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
-|| (TARGET_SSE && (mode == TFmode)))
+  "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH
&& reload_completed"
-  [(set (match_dup 0) (match_dup 3))]
+  [(set (match_dup 0)
+   (: (match_dup 1) (match_dup 2)))]
 {
   machine_mode mode = mode;
   machine_mode vmode = mode;
-  enum rtx_code absneg_op =  == ABS ? AND : XOR;
 
   operands[0] = lowpart_subreg (vmode, operands[0], mode);
   operands[1] = lowpart_subreg (vmode, operands[1], mode);
 
-  if (TARGET_AVX)
-{
-  if (MEM_P (operands[1]))
-std::swap (operands[1], operands[2]);
-}

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

[Mark Wielaard]

Hi David,

On Mon, May 18, 2020 at 11:09:18AM -0400, David Malcolm wrote:
> On Mon, 2020-05-18 at 16:47 +0200, Mark Wielaard wrote:
> > On Mon, May 18, 2020 at 08:45:36AM -0400, David Malcolm wrote:
> > > Also, m_unsafe_fndecl is a field of signal_unsafe_call, so we can
> > > delay
> > > calling replacement_fn until inside signal_unsafe_call::emit, after
> > > the
> > > warning has been emitted.
> > > 
> > > It could even become a member function of signal_unsafe_call,
> > > giving
> > > something like this for signal_unsafe_call::emit:
> > 
> > Thanks for all the hints. I adopted all your suggestions and the
> > warning plus note now looks like:
> > [...] 
> > bzip2.c:874:4: note: ‘_exit’ is a possible signal-safe alternative
> > for ‘exit’
> >   874 |exit(exitValue);
> >   |^~~
> >   |_exit
> > 
> > I also added a testcase. How about the attached?
> 
> Overall, I like it, but it looks like there's a problem with the
> location of the fix-it hint: it looks like it might be replacing the
> whole of the underlined section of the call, argument, parentheses and
> all, with "_exit", rather than just the "exit" token.  I wonder if the
> location of that token is still available in the middle-end by the time
> the analyzer runs.
> 
> What does -fdiagnostics-generate-patch emit?

--- bzip2.c
+++ bzip2.c
@@ -871,7 +871,7 @@
   terribly wrong. Trying to clean up might fail spectacularly. */
 
if (opMode == OM_Z) setExit(3); else setExit(2);
-   exit(exitValue);
+   _exit;
 }

Hmmm, back to the drawing board it seems.

Thanks,

Mark

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

[David Malcolm via Gcc-patches]

On Mon, 2020-05-18 at 16:47 +0200, Mark Wielaard wrote:
> Hi David,
> 
> On Mon, May 18, 2020 at 08:45:36AM -0400, David Malcolm wrote:
> > Also, m_unsafe_fndecl is a field of signal_unsafe_call, so we can
> > delay
> > calling replacement_fn until inside signal_unsafe_call::emit, after
> > the
> > warning has been emitted.
> > 
> > It could even become a member function of signal_unsafe_call,
> > giving
> > something like this for signal_unsafe_call::emit:
> 
> Thanks for all the hints. I adopted all your suggestions and the
> warning plus note now looks like:
> 
> /opt/local/gcc/bin/gcc -g -O2 -fanalyzer -c bzip2.c
> bzip2.c: In function ‘mySIGSEGVorSIGBUScatcher’:
> bzip2.c:874:4: warning: call to ‘exit’ from within signal handler
> [CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler]
>   874 |exit(exitValue);
>   |^~~
>   ‘main’: events 1-2
> |
> | 1784 | IntNative main ( IntNative argc, Char *argv[] )
> |  |   ^~~~
> |  |   |
> |  |   (1) entry to ‘main’
> |..
> | 1800 |smallMode   = False;
> |  |~
> |  ||
> |  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal
> handler
> |
>   event 3
> |
> |cc1:
> | (3): later on, when the signal is delivered to the process
> |
> +--> ‘mySIGSEGVorSIGBUScatcher’: events 4-5
>|
>|  816 | void mySIGSEGVorSIGBUScatcher ( IntNative n )
>|  |  ^~~~
>|  |  |
>|  |  (4) entry to ‘mySIGSEGVorSIGBUScatcher’
>|..
>|  874 |exit(exitValue);
>|  |~~~
>|  ||
>|  |(5) call to ‘exit’ from within signal handler
>|
> bzip2.c:874:4: note: ‘_exit’ is a possible signal-safe alternative
> for ‘exit’
>   874 |exit(exitValue);
>   |^~~
>   |_exit
> 
> I also added a testcase. How about the attached?

Thanks Mark.

Overall, I like it, but it looks like there's a problem with the
location of the fix-it hint: it looks like it might be replacing the
whole of the underlined section of the call, argument, parentheses and
all, with "_exit", rather than just the "exit" token.  I wonder if the
location of that token is still available in the middle-end by the time
the analyzer runs.

What does -fdiagnostics-generate-patch emit?


David

Re: [PATCH] Implement no_stack_protect attribute.

[Florian Weimer via Gcc-patches]

* Michael Matz:

> Hello,
>
> On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:
>
>> > The patch adds new no_stack_protect attribute. The change is requested
>> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
>> > Unlike Clang, I chose to name it no_stack_protect because we already
>> > have stack_protect attribute (used with -fstack-protector-explicit).
>> >
>> > First part of the patch contains a small refactoring of an enum, second
>> > implements the functionality.
>> 
>> In glibc, we already have this:
>> 
>> /* Used to disable stack protection in sensitive places, like ifunc
>>resolvers and early static TLS init.  */
>> #ifdef HAVE_CC_NO_STACK_PROTECTOR
>> # define inhibit_stack_protector \
>> __attribute__ ((__optimize__ ("-fno-stack-protector")))
>> #else
>> # define inhibit_stack_protector
>> #endif
>> 
>> Is it broken?
>
> Depends on what your expectations are.  It completely overrides all 
> options given on the command line (including things like 
> fno-omit-frame-pointer and -O2!).  At least I was very surprised by that 
> even though the current docu can be read that way; if you're similarly 
> surprised, then yes, the above is broken, it does not only disable stack 
> protection (but also e.g. all optimizations, despite the attributes name 
> :-) ).

Yes, that would qualify as broken.

This is not what I observe with gcc-9.3.1-2.fc31.x86_64 from Fedora.
-O2 still has an effect.  So does -fcf-protection.
-fno-omit-frame-pointer does not work for me at all for some reason, the
frame pointer is always missing?

Not sure what is going on here …

Thanks,
Florian

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

[Mark Wielaard]

Hi David,

On Mon, May 18, 2020 at 08:45:36AM -0400, David Malcolm wrote:
> Also, m_unsafe_fndecl is a field of signal_unsafe_call, so we can delay
> calling replacement_fn until inside signal_unsafe_call::emit, after the
> warning has been emitted.
> 
> It could even become a member function of signal_unsafe_call, giving
> something like this for signal_unsafe_call::emit:

Thanks for all the hints. I adopted all your suggestions and the
warning plus note now looks like:

/opt/local/gcc/bin/gcc -g -O2 -fanalyzer -c bzip2.c
bzip2.c: In function ‘mySIGSEGVorSIGBUScatcher’:
bzip2.c:874:4: warning: call to ‘exit’ from within signal handler [CWE-479] 
[-Wanalyzer-unsafe-call-within-signal-handler]
  874 |exit(exitValue);
  |^~~
  ‘main’: events 1-2
|
| 1784 | IntNative main ( IntNative argc, Char *argv[] )
|  |   ^~~~
|  |   |
|  |   (1) entry to ‘main’
|..
| 1800 |smallMode   = False;
|  |~
|  ||
|  |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
|
  event 3
|
|cc1:
| (3): later on, when the signal is delivered to the process
|
+--> ‘mySIGSEGVorSIGBUScatcher’: events 4-5
   |
   |  816 | void mySIGSEGVorSIGBUScatcher ( IntNative n )
   |  |  ^~~~
   |  |  |
   |  |  (4) entry to ‘mySIGSEGVorSIGBUScatcher’
   |..
   |  874 |exit(exitValue);
   |  |~~~
   |  ||
   |  |(5) call to ‘exit’ from within signal handler
   |
bzip2.c:874:4: note: ‘_exit’ is a possible signal-safe alternative for ‘exit’
  874 |exit(exitValue);
  |^~~
  |_exit

I also added a testcase. How about the attached?

Thanks,

Mark>From de08b1f0e1db85241bce22cdd920b351489af446 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Sun, 17 May 2020 23:50:41 +0200
Subject: [PATCH] analyzer: Add exit, and _exit replacement, to sm-signal.

Warn about usage of exit in signal handler and offer _exit as alternative.

gcc/analyzer/ChangeLog:
	* sm-signal.cc(signal_unsafe_call::emit): Possibly add
	gcc_rich_location note for replacement.
	(signal_unsafe_call::get_replacement_fn): New private function.
	(get_async_signal_unsafe_fns): Add "exit".

gcc/testsuite/ChangeLog:
	* gcc.dg/analyzer/signal-exit.c: New testcase.
---
 gcc/analyzer/sm-signal.cc   | 40 ++---
 gcc/testsuite/gcc.dg/analyzer/signal-exit.c | 23 
 2 files changed, 59 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/signal-exit.c

diff --git a/gcc/analyzer/sm-signal.cc b/gcc/analyzer/sm-signal.cc
index 5935e229e77c..d267548324e8 100644
--- a/gcc/analyzer/sm-signal.cc
+++ b/gcc/analyzer/sm-signal.cc
@@ -58,6 +58,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "analyzer/exploded-graph.h"
 #include "analyzer/function-set.h"
 #include "analyzer/analyzer-selftests.h"
+#include "gcc-rich-location.h"
 
 #if ENABLE_ANALYZER
 
@@ -123,13 +124,28 @@ public:
 
   bool emit (rich_location *rich_loc) FINAL OVERRIDE
   {
+auto_diagnostic_group d;
 diagnostic_metadata m;
 /* CWE-479: Signal Handler Use of a Non-reentrant Function.  */
 m.add_cwe (479);
-return warning_meta (rich_loc, m,
-			 OPT_Wanalyzer_unsafe_call_within_signal_handler,
-			 "call to %qD from within signal handler",
-			 m_unsafe_fndecl);
+if (warning_meta (rich_loc, m,
+		  OPT_Wanalyzer_unsafe_call_within_signal_handler,
+		  "call to %qD from within signal handler",
+		  m_unsafe_fndecl))
+  {
+	/* If we know a possible alternative function, add a note
+	   suggesting the replacement.  */
+	if (const char *replacement = get_replacement_fn ())
+	  {
+	gcc_rich_location note_rich_loc (gimple_location (m_unsafe_call));
+	note_rich_loc.add_fixit_replace (replacement);
+	inform (_rich_loc,
+		"%qs is a possible signal-safe alternative for %qD",
+		replacement, m_unsafe_fndecl);
+	  }
+	return true;
+  }
+return false;
   }
 
   label_text describe_state_change (const evdesc::state_change )
@@ -156,6 +172,21 @@ private:
   const signal_state_machine _sm;
   const gcall *m_unsafe_call;
   tree m_unsafe_fndecl;
+
+  /* Returns a replacement function as text if it exists.  Currently
+ only "exit" has a signal-safe replacement "_exit", which does
+ slightly less, but can be used in a signal handler.  */
+  const char *
+  get_replacement_fn ()
+  {
+gcc_assert (m_unsafe_fndecl && DECL_P (m_unsafe_fndecl));
+
+if (strcmp ("exit",
+		IDENTIFIER_POINTER (DECL_NAME (m_unsafe_fndecl))) == 0)
+  return "_exit";
+
+return NULL;
+  }
 };
 
 /* signal_state_machine's ctor.  */
@@ -259,6 +290,7 @@ get_async_signal_unsafe_fns ()
   // TODO: populate this list more fully
   static const 

Re: [PATCH] aarch64: Change the definition of Pmode [pr95182]

[Richard Earnshaw]

On 18/05/2020 04:20, duanbo (C) wrote:
> Hi,
> 
> This changes the definition of Pmode for aarch64 port.
> Unlike x86, S390 etc., Pmode is always set to DImode for aarch64 port even 
> under ILP32.
> Because of that definition,  machine mode of symbol_ref which is supposed to 
> be SImode becomes DImode under target ILP32.
> Definition of Pmode should depend on the current ABI, i.e., SImode for ILP32 
> and DImode for LP64.
> Attached please find the proposed patch .
> Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
> Any suggestion?
>  
> Thanks,
> Duanbo
> 

I don't think this is right.  In aarch64 addresses are ALWAYS 64 bits,
even in ILP32.  Language level pointers can be 32-bit but addresses on
the bus must always be 64-bit.  As Andrew points out, without this
distinction things will fail to work properly.

Where is the testcase for the problem you are trying to solve?  Your
patch lacks tests...

R.

[PATCH][RFC] enfoce SLP_TREE_VECTYPE on invariants

[Richard Biener]

Hi,

I'm trying to enforce SLP_TREE_VECTYPE being set (correctly) on
external and invariant SLP nodes to avoid (re-)computing that
in other places.  The responsible entity for specifying the
desired vector type is vectorizable_* - vectorization analysis
of the user (when we start to share those nodes between multiple
users a user can then also unshare such a node if an existing
vector type conflicts with its own requirements).

The previous patch 
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545938.html
set up things so that vect_slp_analyze_node_operations would
use such type information during costing and also pick up
unshared nodes.

Now as you can see below where I started to enforce SLP_TREE_VECTYPE
for the special boolean case in vect_get_constant_vectors I seemingly
only had to fixup two places, vectorizable_operation (saw bool & bool)
and vectorizable_comparison doing testing on x86_64 and aarch64
(cross cc1 on aarch64-sve.exp and vect.exp).  There obviously will
be more places and I was thinking of less ugly (and more correct?)
ways than doing

+ FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (slp_node), i, child)
+   if (SLP_TREE_DEF_TYPE (child) != vect_internal_def)
+ SLP_TREE_VECTYPE (child) = vectype;

in each vectorizable_*.  In principle it is the vect_is_simple_use
that would need adjustment to associate the correct SLP child with
a vectype so I can't think of sth better than refactoring things
to sth like

  vect_simple_uses (vinfo, stmt_info, slp_node, , )

and process all operans at once transparently for stmt_info/slp_node
(where the actual vect_is_simple_use check is redundant for SLP
nodes anyway).  The index into the array would then match up
with the SLP child (if SLP) or the stmt operand (if not SLP - with
SLP the order can be different on the stmt).

Any better ideas or comments on the general direction?  Richard,
which vectorizable_* do you remember being the "worst" with respect
to vector type determining for invariants?

Thanks,
Richard.


---
 gcc/tree-vect-slp.c   | 17 +++--
 gcc/tree-vect-stmts.c | 22 ++
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 69a2002717f..32e0b6677b3 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3640,9 +3640,22 @@ vect_get_constant_vectors (vec_info *vinfo,
   tree stmt_vectype = STMT_VINFO_VECTYPE (stmt_vinfo);
   if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
   && vect_mask_constant_operand_p (vinfo, stmt_vinfo, op_num))
-vector_type = truth_type_for (stmt_vectype);
+{
+  /* We always want SLP_TREE_VECTYPE (op_node) here correctly set
+as first step.  */
+  vector_type = SLP_TREE_VECTYPE (op_node);
+  gcc_assert (vector_type
+ && types_compatible_p (vector_type,
+truth_type_for (stmt_vectype)));
+}
   else
-vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op), op_node);
+{
+  vector_type = get_vectype_for_scalar_type (vinfo,
+TREE_TYPE (op), op_node);
+  gcc_assert (!SLP_TREE_VECTYPE (op_node)
+ || types_compatible_p (SLP_TREE_VECTYPE (op_node),
+vector_type));
+}
 
   poly_uint64 vf = 1;
   if (loop_vec_info loop_vinfo = dyn_cast  (vinfo))
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 94f233e2e27..c21fba84ec1 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -6169,6 +6169,15 @@ vectorizable_operation (vec_info *vinfo,
   vectype, NULL);
}
 
+  /* Put types on constant and invariant SLP children.  */
+  if (slp_node)
+   {
+ slp_tree child;
+ FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (slp_node), i, child)
+   if (SLP_TREE_DEF_TYPE (child) != vect_internal_def)
+ SLP_TREE_VECTYPE (child) = vectype;
+   }
+
   STMT_VINFO_TYPE (stmt_info) = op_vec_info_type;
   DUMP_VECT_SCOPE ("vectorizable_operation");
   vect_model_simple_cost (vinfo, stmt_info,
@@ -10654,6 +10663,19 @@ vectorizable_comparison (vec_info *vinfo,
}
}
 
+  /* Ideally vect_is_simple_use would return the corresponding SLP
+nodes as well.  But a reorg of that is for when we make SLP
+only reality.  */
+  if ((!vectype1 || !vectype2) && slp_node)
+   for (unsigned i = 0; i < 2; ++i)
+ {
+   slp_tree child = SLP_TREE_CHILDREN (slp_node)[i];
+   if (SLP_TREE_DEF_TYPE (child) != vect_internal_def)
+ /* ???  If we share invariant nodes look for existing
+vectype and on mismatch unshare the child node.  */
+ SLP_TREE_VECTYPE (child) = vectype;
+ }
+
   STMT_VINFO_TYPE (stmt_info) = comparison_vec_info_type;
   vect_model_simple_cost (vinfo, stmt_info,
  

[PATCH] cost invariant nodes from vect_slp_analyze_node_operations SLP walk

[Richard Biener]

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2020-05-18  Richard Biener  

* tree-vectorizer.h (_slp_tree::vectype): Add field.
(SLP_TREE_VECTYPE): New.
* tree-vect-slp.c (vect_create_new_slp_node): Initialize
SLP_TREE_VECTYPE.
(vect_create_new_slp_node): Likewise.
(vect_prologue_cost_for_slp): Move here from tree-vect-stmts.c
and simplify.
(vect_slp_analyze_node_operations): Walk nodes children for
invariant costing.
(vect_get_constant_vectors): Use local scope op variable.
* tree-vect-stmts.c (vect_prologue_cost_for_slp_op): Remove here.
(vect_model_simple_cost): Adjust.
(vect_model_store_cost): Likewise.
(vectorizable_store): Likewise.
---
 gcc/tree-vect-slp.c   | 84 ++
 gcc/tree-vect-stmts.c | 93 ++-
 gcc/tree-vectorizer.h |  2 +
 3 files changed, 90 insertions(+), 89 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 276d9604855..69a2002717f 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -129,6 +129,7 @@ vect_create_new_slp_node (vec scalar_stmts)
   SLP_TREE_LOAD_PERMUTATION (node) = vNULL;
   SLP_TREE_TWO_OPERATORS (node) = false;
   SLP_TREE_DEF_TYPE (node) = vect_internal_def;
+  SLP_TREE_VECTYPE (node) = NULL_TREE;
   node->refcnt = 1;
   node->max_nunits = 1;
 
@@ -155,6 +156,7 @@ vect_create_new_slp_node (vec ops)
   SLP_TREE_LOAD_PERMUTATION (node) = vNULL;
   SLP_TREE_TWO_OPERATORS (node) = false;
   SLP_TREE_DEF_TYPE (node) = vect_external_def;
+  SLP_TREE_VECTYPE (node) = NULL_TREE;
   node->refcnt = 1;
   node->max_nunits = 1;
 
@@ -2720,6 +2722,66 @@ vect_slp_convert_to_external (vec_info *vinfo, slp_tree 
node,
   return true;
 }
 
+/* Compute the prologue cost for invariant or constant operands represented
+   by NODE.  */
+
+static void
+vect_prologue_cost_for_slp (vec_info *vinfo,
+   slp_tree node,
+   stmt_vector_for_cost *cost_vec)
+{
+  /* Without looking at the actual initializer a vector of
+ constants can be implemented as load from the constant pool.
+ When all elements are the same we can use a splat.  */
+  tree vectype = SLP_TREE_VECTYPE (node);
+  /* ???  Ideally we'd want all invariant nodes to have a vectype.  */
+  if (!vectype)
+vectype = get_vectype_for_scalar_type (vinfo,
+  TREE_TYPE (SLP_TREE_SCALAR_OPS
+ (node)[0]), node);
+  unsigned group_size = SLP_TREE_SCALAR_OPS (node).length ();
+  unsigned num_vects_to_check;
+  unsigned HOST_WIDE_INT const_nunits;
+  unsigned nelt_limit;
+  if (TYPE_VECTOR_SUBPARTS (vectype).is_constant (_nunits)
+  && ! multiple_p (const_nunits, group_size))
+{
+  num_vects_to_check = SLP_TREE_NUMBER_OF_VEC_STMTS (node);
+  nelt_limit = const_nunits;
+}
+  else
+{
+  /* If either the vector has variable length or the vectors
+are composed of repeated whole groups we only need to
+cost construction once.  All vectors will be the same.  */
+  num_vects_to_check = 1;
+  nelt_limit = group_size;
+}
+  tree elt = NULL_TREE;
+  unsigned nelt = 0;
+  for (unsigned j = 0; j < num_vects_to_check * nelt_limit; ++j)
+{
+  unsigned si = j % group_size;
+  if (nelt == 0)
+   elt = SLP_TREE_SCALAR_OPS (node)[si];
+  /* ???  We're just tracking whether all operands of a single
+vector initializer are the same, ideally we'd check if
+we emitted the same one already.  */
+  else if (elt != SLP_TREE_SCALAR_OPS (node)[si])
+   elt = NULL_TREE;
+  nelt++;
+  if (nelt == nelt_limit)
+   {
+ record_stmt_cost (cost_vec, 1,
+   SLP_TREE_DEF_TYPE (node) == vect_external_def
+   ? (elt ? scalar_to_vec : vec_construct)
+   : vector_load,
+   NULL, vectype, 0, vect_prologue);
+ nelt = 0;
+   }
+}
+}
+
 /* Analyze statements contained in SLP tree NODE after recursively analyzing
the subtree.  NODE_INSTANCE contains NODE and VINFO contains INSTANCE.
 
@@ -2735,6 +2797,7 @@ vect_slp_analyze_node_operations (vec_info *vinfo, 
slp_tree node,
   int i, j;
   slp_tree child;
 
+  /* Assume we can code-generate all invariants.  */
   if (SLP_TREE_DEF_TYPE (node) != vect_internal_def)
 return true;
 
@@ -2798,6 +2861,26 @@ vect_slp_analyze_node_operations (vec_info *vinfo, 
slp_tree node,
 if (SLP_TREE_SCALAR_STMTS (child).length () != 0)
   STMT_VINFO_DEF_TYPE (SLP_TREE_SCALAR_STMTS (child)[0]) = dt[j];
 
+  /* When the node can be vectorized cost invariant nodes it references.
+ This is not done in DFS order to allow the refering node
+ vectorizable_* calls to nail down the invariant nodes vector type
+ and 

Re: [PATCH] Implement no_stack_protect attribute.

[Michael Matz]

Hello,

On Mon, 18 May 2020, Florian Weimer via Gcc-patches wrote:

> > The patch adds new no_stack_protect attribute. The change is requested
> > from kernel folks and is direct equivalent of Clang's no_stack_protector.
> > Unlike Clang, I chose to name it no_stack_protect because we already
> > have stack_protect attribute (used with -fstack-protector-explicit).
> >
> > First part of the patch contains a small refactoring of an enum, second
> > implements the functionality.
> 
> In glibc, we already have this:
> 
> /* Used to disable stack protection in sensitive places, like ifunc
>resolvers and early static TLS init.  */
> #ifdef HAVE_CC_NO_STACK_PROTECTOR
> # define inhibit_stack_protector \
> __attribute__ ((__optimize__ ("-fno-stack-protector")))
> #else
> # define inhibit_stack_protector
> #endif
> 
> Is it broken?

Depends on what your expectations are.  It completely overrides all 
options given on the command line (including things like 
fno-omit-frame-pointer and -O2!).  At least I was very surprised by that 
even though the current docu can be read that way; if you're similarly 
surprised, then yes, the above is broken, it does not only disable stack 
protection (but also e.g. all optimizations, despite the attributes name 
:-) ).

And given that there's no possibility to express "and please only _add_ to 
the cmdline options" (which implies also being able to override values 
from the cmdline with -fno-xxx or other -fyyy options) I consider our 
current GCC behaviour for the optimize attribute basically unusable.

(One work-around would be to define a macro containing all cmdline options 
in string form in the build system.  Obviously that's a silly solution.)

So, yeah, IMHO the semantics of that attribute should be revised to be 
more useful by default (with the possibility to express the current 
behaviour, for whomever would like to have that (but who?)).


Ciao,
Michael.

Re: [PATCH] contrib: Remove rs6000-ibm-aix5.3.0 from config-list.mk

[David Edelsohn via Gcc-patches]

On Mon, May 18, 2020 at 9:38 AM Iain Buclaw  wrote:
>
> Hi,
>
> Looking at the results of building all targets (with D the front-end),
> I noticed this configuration failed due to support being removed in
> SVN r263506.
>
> OK?
>
> Regards,
> Iain.
>
> ---
> contrib/ChangeLog:
>
> * config-list.mk (LIST): Remove rs6000-ibm-aix5.3.0.

Okay.

We probably should remove AIX 6.1 as well.

Thanks, David

[PATCH] contrib: Remove rs6000-ibm-aix5.3.0 from config-list.mk

[Iain Buclaw via Gcc-patches]

Hi,

Looking at the results of building all targets (with D the front-end),
I noticed this configuration failed due to support being removed in
SVN r263506.

OK?

Regards,
Iain.

---
contrib/ChangeLog:

* config-list.mk (LIST): Remove rs6000-ibm-aix5.3.0.
---
 contrib/config-list.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index d154286a497..c1c2fd162b1 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -83,7 +83,7 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
   powerpc-lynxos powerpcle-elf \
   powerpcle-eabisim powerpcle-eabi \
   riscv32-unknown-linux-gnu riscv64-unknown-linux-gnu \
-  rs6000-ibm-aix5.3.0 rs6000-ibm-aix6.1 rs6000-ibm-aix7.1 \
+  rs6000-ibm-aix6.1 rs6000-ibm-aix7.1 \
   rl78-elf rx-elf s390-linux-gnu s390x-linux-gnu s390x-ibm-tpf sh-elf \
   shle-linux sh-netbsdelf sh-superh-elf \
   sh-rtems sh-wrs-vxworks sparc-elf \
-- 
2.20.1

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

[Mark Wielaard]

Hi David,

On Sun, 2020-05-17 at 18:53 -0400, David Malcolm wrote:
> BTW, it looks like it's using the wrong location for event (2).  It
> ought to be showing a call to "signal", not an assignment.  Please can
> you file a bug about this, and attach the source in question so I can
> take a look at some point.

As briefly discussed on irc, this is an independent issue, it can be
shown with pristine gcc 10.1 and bzip2 1.0.8 source code:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188

A workaround is to use -fanalyzer-fine-grained.

Cheers,

Mark

[PATCH][v2] fixup BB vectorization constant generation place

[Richard Biener]

This adjusts the way we compute the stmt insert location for
invariants in BB vectorization context to deal with eventually
sharing invariant SLP nodes for multiple uses.  We can no longer
use a single use stmt location then but there's a simple way out.

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

Richard.

2020-05-18  Richard Biener  

* tree-vect-slp.c (vect_slp_bb): Start after labels.
(vect_get_constant_vectors): Really place init stmt after scalar defs.
* tree-vect-stmts.c (vect_init_vector_1): Insert before
region begin.
---
 gcc/tree-vect-slp.c   | 32 
 gcc/tree-vect-stmts.c |  9 ++---
 2 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 15eea74d8d1..276d9604855 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3310,7 +3310,7 @@ vect_slp_bb (basic_block bb)
   gimple_stmt_iterator gsi;
   bool any_vectorized = false;
 
-  gsi = gsi_start_bb (bb);
+  gsi = gsi_after_labels (bb);
   while (!gsi_end_p (gsi))
 {
   gimple_stmt_iterator region_begin = gsi;
@@ -3597,7 +3597,7 @@ vect_get_constant_vectors (vec_info *vinfo,
   constant_p = true;
   tree_vector_builder elts (vector_type, nunits, 1);
   elts.quick_grow (nunits);
-  bool place_after_defs = false;
+  stmt_vec_info insert_after = NULL;
   for (j = 0; j < number_of_copies; j++)
 {
   for (i = group_size - 1; op_node->ops.iterate (i, ); i--)
@@ -3656,12 +3656,20 @@ vect_get_constant_vectors (vec_info *vinfo,
  elts[number_of_places_left_in_vector] = op;
  if (!CONSTANT_CLASS_P (op))
constant_p = false;
+ /* For BB vectorization we have to compute an insert location
+when a def is inside the analyzed region since we cannot
+simply insert at the BB start in this case.  */
+ stmt_vec_info opdef;
  if (TREE_CODE (orig_op) == SSA_NAME
  && !SSA_NAME_IS_DEFAULT_DEF (orig_op)
  && is_a  (vinfo)
- && (as_a  (vinfo)->bb
- == gimple_bb (SSA_NAME_DEF_STMT (orig_op
-   place_after_defs = true;
+ && (opdef = vinfo->lookup_def (orig_op)))
+   {
+ if (!insert_after)
+   insert_after = opdef;
+ else
+   insert_after = get_later_stmt (insert_after, opdef);
+   }
 
   if (number_of_places_left_in_vector == 0)
 {
@@ -3678,12 +3686,11 @@ vect_get_constant_vectors (vec_info *vinfo,
  vec_cst = permute_results[number_of_vectors - j - 1];
}
  tree init;
- gimple_stmt_iterator gsi;
- if (place_after_defs)
+ if (insert_after)
{
- stmt_vec_info last_stmt_info
-   = vect_find_last_scalar_stmt_in_slp (slp_node);
- gsi = gsi_for_stmt (last_stmt_info->stmt);
+ gimple_stmt_iterator gsi = gsi_for_stmt (insert_after->stmt);
+ /* vect_init_vector inserts before.  */
+ gsi_next ();
  init = vect_init_vector (vinfo, stmt_vinfo, vec_cst,
   vector_type, );
}
@@ -3692,12 +3699,13 @@ vect_get_constant_vectors (vec_info *vinfo,
 vector_type, NULL);
  if (ctor_seq != NULL)
{
- gsi = gsi_for_stmt (SSA_NAME_DEF_STMT (init));
+ gimple_stmt_iterator gsi
+   = gsi_for_stmt (SSA_NAME_DEF_STMT (init));
  gsi_insert_seq_before (, ctor_seq, GSI_SAME_STMT);
  ctor_seq = NULL;
}
  voprnds.quick_push (init);
- place_after_defs = false;
+ insert_after = NULL;
   number_of_places_left_in_vector = nunits;
  constant_p = true;
  elts.new_vector (vector_type, nunits, 1);
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index b735c04061f..7c4afea32f8 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -1425,13 +1425,8 @@ vect_init_vector_1 (vec_info *vinfo, stmt_vec_info 
stmt_vinfo, gimple *new_stmt,
   else
{
   bb_vec_info bb_vinfo = dyn_cast  (vinfo);
-  basic_block bb;
-  gimple_stmt_iterator gsi_bb_start;
-
-  gcc_assert (bb_vinfo);
-  bb = BB_VINFO_BB (bb_vinfo);
-  gsi_bb_start = gsi_after_labels (bb);
-  gsi_insert_before (_bb_start, new_stmt, GSI_SAME_STMT);
+ gimple_stmt_iterator gsi_region_begin = bb_vinfo->region_begin;
+ gsi_insert_before (_region_begin, new_stmt, GSI_SAME_STMT);
}
 }
 
-- 
2.16.4

[committed][GCC9] d: Fix multiple definition error when using mixins and interfaces (PR92216, PR95184)

[Iain Buclaw via Gcc-patches]

Hi,

This patch for PR d/92216 was already applied to mainline before the
GCC-10 release, however due to a second bug report (PR d/95184)
against the GCC-9 release, I've decided it's best to apply it there too.

Backport is a merge of r10-7199 and r10-7504.

Bootstrapped and regression tested on x86_64-linux-gnu, committed to
gcc-9 branch.

Regards
Iain.

---
gcc/d/ChangeLog:

PR d/92216
* decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target
function is external to the current compilation.

gcc/testsuite/ChangeLog:

PR d/92216
* gdc.dg/imports/pr92216.d: New.
* gdc.dg/pr92216.d: New test.
---
 gcc/d/ChangeLog|  9 +
 gcc/d/decl.cc  |  7 +--
 gcc/testsuite/ChangeLog|  9 +
 gcc/testsuite/gdc.dg/imports/pr92216.d | 22 ++
 gcc/testsuite/gdc.dg/pr92216.d | 13 +
 5 files changed, 58 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/imports/pr92216.d
 create mode 100644 gcc/testsuite/gdc.dg/pr92216.d

diff --git a/gcc/d/ChangeLog b/gcc/d/ChangeLog
index 5048d2ab400..9ef34dd7927 100644
--- a/gcc/d/ChangeLog
+++ b/gcc/d/ChangeLog
@@ -1,3 +1,12 @@
+2020-05-18  Iain Buclaw  
+
+   Backport from mainline
+   2020-03-16  Iain Buclaw  
+
+   PR d/92216
+   * decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target
+   function is external to the current compilation.
+
 2020-05-17  Iain Buclaw  
 
Backport from mainline
diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 49723649230..d1dfce25c68 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -1803,8 +1803,11 @@ make_thunk (FuncDeclaration *decl, int offset)
 
   DECL_CONTEXT (thunk) = d_decl_context (decl);
 
-  /* Thunks inherit the public access of the function they are targetting.  */
-  TREE_PUBLIC (thunk) = TREE_PUBLIC (function);
+  /* Thunks inherit the public access of the function they are targetting.
+ When the function is outside the current compilation unit however, then 
the
+ thunk must be kept private to not conflict.  */
+  TREE_PUBLIC (thunk) = TREE_PUBLIC (function) && !DECL_EXTERNAL (function);
+
   DECL_EXTERNAL (thunk) = 0;
 
   /* Thunks are always addressable.  */
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 984db29ccac..87e6df437c1 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,12 @@
+2020-05-18  Iain Buclaw  
+
+   Backport from mainline
+   2020-03-16  Iain Buclaw  
+
+   PR d/92216
+   * gdc.dg/imports/pr92216.d: New.
+   * gdc.dg/pr92216.d: New test.
+
 2020-05-17  Iain Buclaw  
 
Backport from mainline
diff --git a/gcc/testsuite/gdc.dg/imports/pr92216.d 
b/gcc/testsuite/gdc.dg/imports/pr92216.d
new file mode 100644
index 000..b8c71c03420
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/imports/pr92216.d
@@ -0,0 +1,22 @@
+module imports.pr92216;
+
+class B : I
+{
+protected override void getStruct(){}
+mixin A!();
+
+}
+
+mixin template A()
+{
+public void* getS()
+{
+return null;
+}
+}
+
+public interface I
+{
+public void* getS();
+protected void getStruct();
+}
diff --git a/gcc/testsuite/gdc.dg/pr92216.d b/gcc/testsuite/gdc.dg/pr92216.d
new file mode 100644
index 000..89a99e599be
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/pr92216.d
@@ -0,0 +1,13 @@
+// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216
+// { dg-options "-I $srcdir/gdc.dg" }
+// { dg-do compile }
+// { dg-final { scan-assembler 
"_DT(4|8|16)_D7imports7pr922161B8__mixin24getSMFZPv\[: \t\n\]" } }
+// { dg-final { scan-assembler-not "(.globl|.global)\[ 
\]+_DT(4|8|16)_D7imports7pr922161B8__mixin24getSMFZPv" } }
+module pr92216;
+
+private import imports.pr92216;
+
+class C : B
+{
+protected override void getStruct() {}
+}
-- 
2.20.1

Re: [PATCH] x86: Update Intel processor detection

[H.J. Lu via Gcc-patches]

On Mon, May 18, 2020 at 5:43 AM Uros Bizjak  wrote:
>
> On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
> >
> > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  wrote:
> > >
> > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  wrote:
> > > >
> > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> > > > and Tiger Lake processor families.
> > > >
> > > > OK for master?
> > >
> > > OK.
> >
> > I am checking in my patch.
> >
> > > Please also update cpuinfo.c from libgcc and corresponding
> >
> > I will take a look to see if we share the same CPU detection code between
> > libgcc and config/i386/driver-i386.c.
>
> I don't think it will bring any benefit, this is mainly one huge
> switch statement that maps to different stuff in libgcc and
> driver-i386.

libgcc and config/i386/driver-i386.c differ even before my patch.
I think we can do better.


-- 
H.J.

Re: [RFC] analyzer: Add exit, and _exit replacement, to sm-signal.

[David Malcolm via Gcc-patches]

On Sun, 2020-05-17 at 18:42 -0400, David Malcolm via Gcc-patches wrote:
> On Sun, 2020-05-17 at 18:39 -0400, David Malcolm via Gcc-patches
> wrote:
> > On Mon, 2020-05-18 at 00:05 +0200, Mark Wielaard wrote:
> 
> [...snip...]
> 
> > How about something like this (though I even haven't checked if it
> > compiles, and am not 100% sure what the wording should be):
> > 
> >   bool emit (rich_location *rich_loc) FINAL OVERRIDE
> >   {
> > diagnostic_metadata m;
> > /* CWE-479: Signal Handler Use of a Non-reentrant Function.  */
> > m.add_cwe (479);
> 
> ...and there should be this here:
>   auto_diagnostic_group d;
> 
> to associate the note with the warning.
> 
> > if (warning_meta (rich_loc, m,
> >   OPT_Wanalyzer_unsafe_call_within_signal_handler,
> >   "call to %qD from within signal handler",
> >   m_unsafe_fndecl))
> >   {
> > if (m_replacement)
> >   {
> > gcc_rich_location note_rich_loc (gimple_location
> > (m_unsafe_call));
> > note_rich_loc.add_fixit_replace (m_replacement);
> > inform (_rich_loc, "%qs is a signal-safe replacement
> > for %qD",
> > m_replacement, unsafe_fndecl);
> >   }
> > return true;
> >   }
> > return false;
> >   }

Also, m_unsafe_fndecl is a field of signal_unsafe_call, so we can delay
calling replacement_fn until inside signal_unsafe_call::emit, after the
warning has been emitted.

It could even become a member function of signal_unsafe_call, giving
something like this for signal_unsafe_call::emit:


  bool emit (rich_location *rich_loc) FINAL OVERRIDE
  {
auto_diagnostic_group d;
diagnostic_metadata m;
/* CWE-479: Signal Handler Use of a Non-reentrant Function.  */
m.add_cwe (479);
if (warning_meta (rich_loc, m,
  OPT_Wanalyzer_unsafe_call_within_signal_handler,
  "call to %qD from within signal handler",
  m_unsafe_fndecl))
  {
if (const char *replacement = get_replacement_fn ())
  {
gcc_rich_location note_rich_loc (gimple_location (m_unsafe_call));
note_rich_loc.add_fixit_replace (replacement);
inform (_rich_loc, "%qs is a signal-safe replacement for %qD",
replacement, m_unsafe_fndecl);
  }
return true;
  }
return false;
  }

Re: [PATCH] x86: Update Intel processor detection

[Uros Bizjak via Gcc-patches]

On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
>
> On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  wrote:
> >
> > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  wrote:
> > >
> > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> > > and Tiger Lake processor families.
> > >
> > > OK for master?
> >
> > OK.
>
> I am checking in my patch.
>
> > Please also update cpuinfo.c from libgcc and corresponding
>
> I will take a look to see if we share the same CPU detection code between
> libgcc and config/i386/driver-i386.c.

I don't think it will bring any benefit, this is mainly one huge
switch statement that maps to different stuff in libgcc and
driver-i386.

Uros.

Re: [PATCH] TESTSUITE: Fix tests for 16-bit targets

[Jozef Lawrynowicz]

On Fri, May 15, 2020 at 10:48:56PM +, Joseph Myers wrote:
> On Fri, 15 May 2020, Jozef Lawrynowicz wrote:
> 
> > The attached patch fixes many GCC and G++ tests for 16-bit targets. These
> > targets can have the following properties:
> > - "int", "size_t", "ptrdiff_t", "void *" are 16-bit types
> > - sizeof(int) == sizeof(short)
> 
> Some of the tests are disabled by the patch for the case where pointers 
> are the same size as int.  Were those tests all previously failing for 
> 32-bit targets where that's the case?  If not, ptr_eq_int seems an 
> inappropriate condition for disabling them.

Ah yes, regarding g++.dg/init/new44.C, it seems that i386-pc-linux-gnu
does require an array size cookie even though ptr_eq_int (in fact,
since the decision relates to size_t, a pointer size effective target shouldn't
have been used anyway). I'll amend the condition so it is skipped for msp430
only.

The other test using ptr_eq_int (g++.dg/init/const7.C) is also passing
on i386-pc-linux-gnu, so I'll amend that as well.

I'll make sure to do a full regtest on i386-pc-linux-gnu before
applying.

Thanks,
Jozef

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

Re: [PATCH] x86: Update Intel processor detection

[H.J. Lu via Gcc-patches]

On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  wrote:
>
> On Mon, May 18, 2020 at 1:58 PM H.J. Lu  wrote:
> >
> > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> > and Tiger Lake processor families.
> >
> > OK for master?
>
> OK.

I am checking in my patch.

> Please also update cpuinfo.c from libgcc and corresponding

I will take a look to see if we share the same CPU detection code between
libgcc and config/i386/driver-i386.c.

> gcc.target/i386/builtin_target.c testcase.
>
> Thanks,
> Uros.
>
> > Thanks.
> >
> > H.J.
> > --
> > * config/i386/driver-i386.c (host_detect_local_cpu): Support
> > Intel Airmont, Tremont, Comet Lake, Ice Lake and Tiger Lake
> > processor families.
> > ---
> >  gcc/config/i386/driver-i386.c | 30 +-
> >  1 file changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
> > index 6926f0beb0a..7612ddfb846 100644
> > --- a/gcc/config/i386/driver-i386.c
> > +++ b/gcc/config/i386/driver-i386.c
> > @@ -777,9 +777,12 @@ const char *host_detect_local_cpu (int argc, const 
> > char **argv)
> > case 0x37:
> > case 0x4a:
> > case 0x4d:
> > -   case 0x5a:
> > case 0x5d:
> >   /* Silvermont.  */
> > +   case 0x4c:
> > +   case 0x5a:
> > +   case 0x75:
> > + /* Airmont.  */
> >   cpu = "silvermont";
> >   break;
> > case 0x5c:
> > @@ -791,6 +794,12 @@ const char *host_detect_local_cpu (int argc, const 
> > char **argv)
> >   /* Goldmont Plus.  */
> >   cpu = "goldmont-plus";
> >   break;
> > +   case 0x86:
> > +   case 0x96:
> > +   case 0x9c:
> > + /* Tremont.  */
> > + cpu = "tremont";
> > + break;
> > case 0x0f:
> >   /* Merom.  */
> > case 0x17:
> > @@ -841,6 +850,9 @@ const char *host_detect_local_cpu (int argc, const char 
> > **argv)
> > case 0x8e:
> > case 0x9e:
> >   /* Kaby Lake.  */
> > +   case 0xa5:
> > +   case 0xa6:
> > + /* Comet Lake.  */
> >   cpu = "skylake";
> >   break;
> > case 0x55:
> > @@ -851,6 +863,22 @@ const char *host_detect_local_cpu (int argc, const 
> > char **argv)
> > /* Skylake with AVX-512.  */
> > cpu = "skylake-avx512";
> >   break;
> > +   case 0x6a:
> > +   case 0x6c:
> > + /* Ice Lake server.  */
> > + cpu = "icelake-server";
> > + break;
> > +   case 0x7e:
> > +   case 0x7d:
> > +   case 0x9d:
> > + /* Ice Lake client.  */
> > + cpu = "icelake-client";
> > + break;
> > +   case 0x8c:
> > +   case 0x8d:
> > + /* Tiger Lake.  */
> > + cpu = "tigerlake";
> > + break;
> > case 0x57:
> >   /* Knights Landing.  */
> >   cpu = "knl";
> > --
> > 2.26.2
> >



-- 
H.J.

Re: [PATCH] x86: Update Intel processor detection

[Uros Bizjak via Gcc-patches]

On Mon, May 18, 2020 at 1:58 PM H.J. Lu  wrote:
>
> Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
> and Tiger Lake processor families.
>
> OK for master?

OK.

Please also update cpuinfo.c from libgcc and corresponding
gcc.target/i386/builtin_target.c testcase.

Thanks,
Uros.

> Thanks.
>
> H.J.
> --
> * config/i386/driver-i386.c (host_detect_local_cpu): Support
> Intel Airmont, Tremont, Comet Lake, Ice Lake and Tiger Lake
> processor families.
> ---
>  gcc/config/i386/driver-i386.c | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
> index 6926f0beb0a..7612ddfb846 100644
> --- a/gcc/config/i386/driver-i386.c
> +++ b/gcc/config/i386/driver-i386.c
> @@ -777,9 +777,12 @@ const char *host_detect_local_cpu (int argc, const char 
> **argv)
> case 0x37:
> case 0x4a:
> case 0x4d:
> -   case 0x5a:
> case 0x5d:
>   /* Silvermont.  */
> +   case 0x4c:
> +   case 0x5a:
> +   case 0x75:
> + /* Airmont.  */
>   cpu = "silvermont";
>   break;
> case 0x5c:
> @@ -791,6 +794,12 @@ const char *host_detect_local_cpu (int argc, const char 
> **argv)
>   /* Goldmont Plus.  */
>   cpu = "goldmont-plus";
>   break;
> +   case 0x86:
> +   case 0x96:
> +   case 0x9c:
> + /* Tremont.  */
> + cpu = "tremont";
> + break;
> case 0x0f:
>   /* Merom.  */
> case 0x17:
> @@ -841,6 +850,9 @@ const char *host_detect_local_cpu (int argc, const char 
> **argv)
> case 0x8e:
> case 0x9e:
>   /* Kaby Lake.  */
> +   case 0xa5:
> +   case 0xa6:
> + /* Comet Lake.  */
>   cpu = "skylake";
>   break;
> case 0x55:
> @@ -851,6 +863,22 @@ const char *host_detect_local_cpu (int argc, const char 
> **argv)
> /* Skylake with AVX-512.  */
> cpu = "skylake-avx512";
>   break;
> +   case 0x6a:
> +   case 0x6c:
> + /* Ice Lake server.  */
> + cpu = "icelake-server";
> + break;
> +   case 0x7e:
> +   case 0x7d:
> +   case 0x9d:
> + /* Ice Lake client.  */
> + cpu = "icelake-client";
> + break;
> +   case 0x8c:
> +   case 0x8d:
> + /* Tiger Lake.  */
> + cpu = "tigerlake";
> + break;
> case 0x57:
>   /* Knights Landing.  */
>   cpu = "knl";
> --
> 2.26.2
>

[PATCH] x86: Update Intel processor detection

[H.J. Lu via Gcc-patches]

Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice Lake
and Tiger Lake processor families.

OK for master?

Thanks.

H.J.
--
* config/i386/driver-i386.c (host_detect_local_cpu): Support
Intel Airmont, Tremont, Comet Lake, Ice Lake and Tiger Lake
processor families.
---
 gcc/config/i386/driver-i386.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index 6926f0beb0a..7612ddfb846 100644
--- a/gcc/config/i386/driver-i386.c
+++ b/gcc/config/i386/driver-i386.c
@@ -777,9 +777,12 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
case 0x37:
case 0x4a:
case 0x4d:
-   case 0x5a:
case 0x5d:
  /* Silvermont.  */
+   case 0x4c:
+   case 0x5a:
+   case 0x75:
+ /* Airmont.  */
  cpu = "silvermont";
  break;
case 0x5c:
@@ -791,6 +794,12 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
  /* Goldmont Plus.  */
  cpu = "goldmont-plus";
  break;
+   case 0x86:
+   case 0x96:
+   case 0x9c:
+ /* Tremont.  */
+ cpu = "tremont";
+ break;
case 0x0f:
  /* Merom.  */
case 0x17:
@@ -841,6 +850,9 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
case 0x8e:
case 0x9e:
  /* Kaby Lake.  */
+   case 0xa5:
+   case 0xa6:
+ /* Comet Lake.  */
  cpu = "skylake";
  break;
case 0x55:
@@ -851,6 +863,22 @@ const char *host_detect_local_cpu (int argc, const char 
**argv)
/* Skylake with AVX-512.  */
cpu = "skylake-avx512";
  break;
+   case 0x6a:
+   case 0x6c:
+ /* Ice Lake server.  */
+ cpu = "icelake-server";
+ break;
+   case 0x7e:
+   case 0x7d:
+   case 0x9d:
+ /* Ice Lake client.  */
+ cpu = "icelake-client";
+ break;
+   case 0x8c:
+   case 0x8d:
+ /* Tiger Lake.  */
+ cpu = "tigerlake";
+ break;
case 0x57:
  /* Knights Landing.  */
  cpu = "knl";
-- 
2.26.2

Re: [PATCH] tsan: Add optional support for distinguishing volatiles

[Dmitry Vyukov via Gcc-patches]

On Wed, May 13, 2020 at 12:48 PM Marco Elver  wrote:
> > Hello, Jakub,
> >
> > On Tue, 28 Apr 2020 at 16:58, Dmitry Vyukov  wrote:
> > >
> > > On Tue, Apr 28, 2020 at 4:55 PM Jakub Jelinek  wrote:
> > > >
> > > > On Tue, Apr 28, 2020 at 04:48:31PM +0200, Dmitry Vyukov wrote:
> > > > > FWIW this is:
> > > > >
> > > > > Acked-by: Dmitry Vyukov 
> > > > >
> > > > > We just landed a similar change to llvm:
> > > > > https://github.com/llvm/llvm-project/commit/5a2c31116f412c3b6888be361137efd705e05814
> > > > >
> > > > > Do you have any objections?
> > > >
> > > > I don't have objections or anything right now, we are just trying to
> > > > finalize GCC 10 and once it branches, patches like this can be
> > > > reviewed/committed for GCC11.
> > >
> > > Thanks for clarification!
> > > Then we will just wait.
> >
> > Just saw the announcement that GCC11 is in development stage 1 [1]. In
> > case it is still too early, do let us know what time window we shall
> > follow up.
> >
> > Would it be useful to rebase and resend the patch?
>
> So, it's starting to look like we're really going to need this sooner
> than later. Given the feature is guarded behind a flag, and otherwise
> does not affect anything else, would it be possible to take this for
> GCC11? What do we need to do to make this happen?
>
> Thanks,
> -- Marco
>
> > [1] https://gcc.gnu.org/pipermail/gcc/2020-April/000505.html

Jakub, could you please give some update. Do we just wait? That's
fine, just want to understand because there are some interesting
discussions in the kernel re bumping compiler requirements.
Thanks

Re: [PATCH] Implement no_stack_protect attribute.

[Richard Biener via Gcc-patches]

On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches
 wrote:
>
> On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
> > > The optimize attribute is used to specify that a function is to be 
> > > compiled
> > > with different optimization options than specified on the command line.
> > > ```
> > >
> > > It's pretty clear about the command line arguments (that are ignored).
> >
> > That is not clear at all.  The difference is primarily in what the option
> > string says in there.
>
> And if we decide we want to keep existing behavior (haven't checked if we
> actually behave that way yet), we should add some syntax that will allow
> ammending command line options rather than replacing it.

We do behave this way - while we're running against the current
gcc_options we call decode_options which first does
default_options_optimization.  So it behaves inconsistently with
respect to options not explicitly listed in default_options_table.

But I also think doing the whole processing as in decode_options
is the only thing that's really tested.  And a fix would be to not
start from the current set of options but from a clean slate...

The code clearly thinks we're doing incremental changes:

  /* Save current options.  */
  cl_optimization_save (_opts, _options);

  /* If we previously had some optimization options, use them as the
 default.  */
  if (old_opts)
cl_optimization_restore (_options,
 TREE_OPTIMIZATION (old_opts));

  /* Parse options, and update the vector.  */
  parse_optimize_options (args, true);
  DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node)
= build_optimization_node (_options);

  /* Restore current options.  */
  cl_optimization_restore (_options, _opts);

so for example you should see -fipa-pta preserved from the
command-line while -fno-tree-pta would be overridden even
if not mentioned explicitely in the optimize attribute.

IMHO the current situation is far from useful...

Richard.

> Could be say start the optimize attribute string with + or something
> similar.
> Does target attribute behave that way too?
>
> Jakub
>

Re: [PATCH] Implement no_stack_protect attribute.

[Florian Weimer via Gcc-patches]

* Martin Liška:

> The patch adds new no_stack_protect attribute. The change is requested
> from kernel folks and is direct equivalent of Clang's no_stack_protector.
> Unlike Clang, I chose to name it no_stack_protect because we already
> have stack_protect attribute (used with -fstack-protector-explicit).
>
> First part of the patch contains a small refactoring of an enum, second
> implements the functionality.

In glibc, we already have this:

/* Used to disable stack protection in sensitive places, like ifunc
   resolvers and early static TLS init.  */
#ifdef HAVE_CC_NO_STACK_PROTECTOR
# define inhibit_stack_protector \
__attribute__ ((__optimize__ ("-fno-stack-protector")))
#else
# define inhibit_stack_protector
#endif

Is it broken?

Thanks,
Florian

[committed] MAINTAINERS: Add myself for write after approval

[Alex Coplan]

ChangeLog:

2020-05-18  Alex Coplan  
* MAINTAINERS (Write After Approval): Add myself.

---

diff --git a/MAINTAINERS b/MAINTAINERS
index 336346a37a5..5528aad5e23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -353,6 +353,7 @@ William Cohen   

 Michael Collison   
 Josh Conner
 R. Kelley Cook 
+Alex Coplan
 Andrea Corallo 
 Christian Cornelssen   
 Ludovic Courtès

Re: [PATCH] Implement no_stack_protect attribute.

[Jakub Jelinek via Gcc-patches]

On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote:
> > The optimize attribute is used to specify that a function is to be compiled
> > with different optimization options than specified on the command line.
> > ```
> > 
> > It's pretty clear about the command line arguments (that are ignored).
> 
> That is not clear at all.  The difference is primarily in what the option
> string says in there.

And if we decide we want to keep existing behavior (haven't checked if we
actually behave that way yet), we should add some syntax that will allow
ammending command line options rather than replacing it.
Could be say start the optimize attribute string with + or something
similar.
Does target attribute behave that way too?

Jakub

Re: [PATCH] Implement no_stack_protect attribute.

[Jakub Jelinek via Gcc-patches]

On Mon, May 18, 2020 at 01:00:01PM +0200, Martin Liška wrote:
> On 5/18/20 12:41 PM, Jakub Jelinek wrote:
> > On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
> > > The patch adds new no_stack_protect attribute. The change is requested
> > > from kernel folks and is direct equivalent of Clang's no_stack_protector.
> > > Unlike Clang, I chose to name it no_stack_protect because we already
> > > have stack_protect attribute (used with -fstack-protector-explicit).
> > 
> > Wouldn't it be better to look at the optimize attribute to see if it really
> > does what has been said in the thread and if we don't want to change it,
> > such that a function with optimize attribute xyz stands for the option
> > defaults + command line options + xyz, rather than option defaults + xyz
> > only?
> 
> It's documented behavior what we do:
> 
> ```
> The optimize attribute is used to specify that a function is to be compiled
> with different optimization options than specified on the command line.
> ```
> 
> It's pretty clear about the command line arguments (that are ignored).

That is not clear at all.  The difference is primarily in what the option
string says in there.

Jakub

Re: [PATCH] Implement no_stack_protect attribute.

[Martin Liška]

On 5/18/20 12:41 PM, Jakub Jelinek wrote:

On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:

The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_protect because we already
have stack_protect attribute (used with -fstack-protector-explicit).


Wouldn't it be better to look at the optimize attribute to see if it really
does what has been said in the thread and if we don't want to change it,
such that a function with optimize attribute xyz stands for the option
defaults + command line options + xyz, rather than option defaults + xyz
only?


It's documented behavior what we do:

```
The optimize attribute is used to specify that a function is to be compiled
with different optimization options than specified on the command line.
```

It's pretty clear about the command line arguments (that are ignored).

Martin



Jakub

Re: [PATCH] Implement no_stack_protect attribute.

[Jakub Jelinek via Gcc-patches]

On Mon, May 18, 2020 at 12:37:58PM +0200, Martin Liška wrote:
> The patch adds new no_stack_protect attribute. The change is requested
> from kernel folks and is direct equivalent of Clang's no_stack_protector.
> Unlike Clang, I chose to name it no_stack_protect because we already
> have stack_protect attribute (used with -fstack-protector-explicit).

Wouldn't it be better to look at the optimize attribute to see if it really
does what has been said in the thread and if we don't want to change it,
such that a function with optimize attribute xyz stands for the option
defaults + command line options + xyz, rather than option defaults + xyz
only?

Jakub

[PATCH] Implement no_stack_protect attribute.

[Martin Liška]

Hi.

The patch adds new no_stack_protect attribute. The change is requested
from kernel folks and is direct equivalent of Clang's no_stack_protector.
Unlike Clang, I chose to name it no_stack_protect because we already
have stack_protect attribute (used with -fstack-protector-explicit).

First part of the patch contains a small refactoring of an enum, second
implements the functionality.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 6b3e9d32150fe17acb271b7bedee7dc95cad7dc8 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 15 May 2020 14:42:12 +0200
Subject: [PATCH 2/2] Implement no_stack_protect attribute.

gcc/ChangeLog:

2020-05-18  Martin Liska  

	PR c/94722
	* cfgexpand.c (stack_protect_decl_phase):
	Guard with lookup_attribute("no_stack_protect") at
	various places.
	(expand_used_vars): Likewise here.
	* doc/extend.texi: Document no_stack_protect attribute.

gcc/ada/ChangeLog:

2020-05-18  Martin Liska  

	PR c/94722
	* gcc-interface/utils.c (handle_no_stack_protect_attribute):
	New.
	(handle_stack_protect_attribute): Add error message for a
	no_stack_protect function.

gcc/c-family/ChangeLog:

2020-05-18  Martin Liska  

	PR c/94722
	* c-attribs.c (handle_no_stack_protect_function_attribute): New.
	(handle_stack_protect_attribute): Add error message for a
	no_stack_protect function.

gcc/testsuite/ChangeLog:

2020-05-18  Martin Liska  

	PR c/94722
	* g++.dg/no-stack-protect-attr-2.C: New test.
	* g++.dg/no-stack-protect-attr-3.C: New test.
	* g++.dg/no-stack-protect-attr.C: New test.
---
 gcc/ada/gcc-interface/utils.c | 32 
 gcc/c-family/c-attribs.c  | 33 
 gcc/cfgexpand.c   | 82 ++-
 gcc/doc/extend.texi   |  4 +
 .../g++.dg/no-stack-protect-attr-2.C  |  7 ++
 .../g++.dg/no-stack-protect-attr-3.C  | 23 ++
 gcc/testsuite/g++.dg/no-stack-protect-attr.C  | 16 
 7 files changed, 158 insertions(+), 39 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/no-stack-protect-attr-2.C
 create mode 100644 gcc/testsuite/g++.dg/no-stack-protect-attr-3.C
 create mode 100644 gcc/testsuite/g++.dg/no-stack-protect-attr.C

diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
index 1527be4f6d1..144afe37d78 100644
--- a/gcc/ada/gcc-interface/utils.c
+++ b/gcc/ada/gcc-interface/utils.c
@@ -91,6 +91,7 @@ static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
 static tree handle_sentinel_attribute (tree *, tree, tree, int, bool *);
 static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
 static tree handle_stack_protect_attribute (tree *, tree, tree, int, bool *);
+static tree handle_no_stack_protect_attribute (tree *, tree, tree, int, bool *);
 static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
 static tree handle_noclone_attribute (tree *, tree, tree, int, bool *);
 static tree handle_noicf_attribute (tree *, tree, tree, int, bool *);
@@ -141,6 +142,8 @@ const struct attribute_spec gnat_internal_attribute_table[] =
 handle_noreturn_attribute, NULL },
   { "stack_protect",0, 0, true,  false, false, false,
 handle_stack_protect_attribute, NULL },
+  { "no_stack_protect",0, 0, true,  false, false, false,
+handle_no_stack_protect_attribute, NULL },
   { "noinline", 0, 0,  true,  false, false, false,
 handle_noinline_attribute, NULL },
   { "noclone",  0, 0,  true,  false, false, false,
@@ -6523,10 +6526,39 @@ handle_stack_protect_attribute (tree *node, tree name, tree, int,
   warning (OPT_Wattributes, "%qE attribute ignored", name);
   *no_add_attrs = true;
 }
+  else if (lookup_attribute ("no_stack_protect", DECL_ATTRIBUTES (*node)))
+{
+  warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
+	   "with %qs attribute", name, "no_stack_protect");
+  *no_add_attrs = true;
+}
+
+  return NULL_TREE;
+}
+
+/* Handle a "no_stack_protect" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+handle_no_stack_protect_attribute (tree *node, tree name, tree, int,
+   bool *no_add_attrs)
+{
+  if (TREE_CODE (*node) != FUNCTION_DECL)
+{
+  warning (OPT_Wattributes, "%qE attribute ignored", name);
+  *no_add_attrs = true;
+}
+  else if (lookup_attribute ("stack_protect", DECL_ATTRIBUTES (*node)))
+{
+  warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
+	   "with %qs attribute", name, "stack_protect");
+  *no_add_attrs = true;
+}
 
   return NULL_TREE;
 }
 
+
 /* Handle a "noinline" attribute; arguments as in
struct attribute_spec.handler.  */
 
diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 7a6fb9af6da..3c22576035b 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -63,6 +63,8 @@ static tree handle_no_sanitize_undefined_attribute (tree *, 

[PATCH] middle-end/95171 - inlining of trapping compare into non-call EH fn

[Richard Biener]

This fixes always-inlining across -fnon-call-exception boundaries
for conditions which we do not allow to throw.

Bootstrapped and tested onx x86_64-unknown-linux-gnu, applied.

2020-05-18  Richard Biener  

PR middle-end/95171
* tree-inline.c (remap_gimple_stmt): Split out trapping compares
when inlining into a non-call EH function.

* gcc.dg/pr95171.c: New testcase.
---
 gcc/testsuite/gcc.dg/pr95171.c | 18 ++
 gcc/tree-inline.c  | 31 +++
 2 files changed, 49 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr95171.c

diff --git a/gcc/testsuite/gcc.dg/pr95171.c b/gcc/testsuite/gcc.dg/pr95171.c
new file mode 100644
index 000..af9bde7bc6a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr95171.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-fexceptions -ffinite-math-only -fnon-call-exceptions" } */
+
+inline double __attribute__ ((always_inline))
+w9 (int q2)
+{
+  return __builtin_fabs (__builtin_nan ("")) > 0.0 ? 1.0 : q2 / 1.0;
+}
+
+double __attribute__ ((optimize ("-fipa-cp")))
+o7 (int iz)
+{
+  int rj[1];
+
+  (void) rj;
+
+  return w9 (iz);
+}
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index ee96c9cfff0..943f3f9407b 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -1956,6 +1956,37 @@ remap_gimple_stmt (gimple *stmt, copy_body_data *id)
   gimple_set_vuse (copy, NULL_TREE);
 }
 
+  if (cfun->can_throw_non_call_exceptions)
+{
+  /* When inlining a function which does not have non-call exceptions
+enabled into a function that has (which only happens with
+always-inline) we have to fixup stmts that cannot throw.  */
+  if (gcond *cond = dyn_cast  (copy))
+   if (gimple_could_trap_p (cond))
+ {
+   gassign *cmp
+ = gimple_build_assign (make_ssa_name (boolean_type_node),
+gimple_cond_code (cond),
+gimple_cond_lhs (cond),
+gimple_cond_rhs (cond));
+   gimple_seq_add_stmt (, cmp);
+   gimple_cond_set_code (cond, NE_EXPR);
+   gimple_cond_set_lhs (cond, gimple_assign_lhs (cmp));
+   gimple_cond_set_rhs (cond, boolean_false_node);
+ }
+  if (gassign *ass = dyn_cast  (copy))
+   if ((gimple_assign_rhs_code (ass) == COND_EXPR
+|| gimple_assign_rhs_code (ass) == VEC_COND_EXPR)
+   && gimple_could_trap_p (ass))
+ {
+   gassign *cmp
+ = gimple_build_assign (make_ssa_name (boolean_type_node),
+gimple_assign_rhs1 (ass));
+   gimple_seq_add_stmt (, cmp);
+   gimple_assign_set_rhs1 (ass, gimple_assign_lhs (cmp));
+ }
+}
+
   gimple_seq_add_stmt (, copy);
   return stmts;
 }
-- 
2.25.1

Re: [PATCH v4] Fix alignment for local variable [PR90811]

[Richard Biener via Gcc-patches]

On Mon, May 18, 2020 at 9:27 AM Kito Cheng  wrote:
>
> ping
>
> On Tue, Apr 14, 2020 at 2:53 PM Kito Cheng  wrote:
>>
>>  - The alignment for local variable was adjust during 
>> estimate_stack_frame_size,
>>however it seems wrong spot to adjust that, expand phase will adjust that
>>but it little too late to some gimple optimization, which rely on certain
>>target hooks need to check alignment, forwprop is an example for
>>that, result of simplify_builtin_call rely on the alignment on some
>>target like ARM or RISC-V.
>>
>>  - Exclude static local var and hard register var in the process of
>>alignment adjustment.
>>
>>  - This patch fix gfortran.dg/pr45636.f90 for arm and riscv.
>>
>>  - Regression test on riscv32/riscv64 and x86_64-linux-gnu, no new fail
>>introduced.
>>
>> gcc/ChangeLog
>>
>> PR target/90811
>> * Makefile.in (OBJS): Add tree-adjust-alignment.o.
>> * tree-adjust-alignment.cc (pass_data_adjust_alignment): New.
>> (pass_adjust_alignment): New.
>> (-pass_adjust_alignment::execute): New.
>> (make_pass_adjust_alignment): New.
>> * tree-pass.h (make_pass_adjust_alignment): New.
>> * passes.def: Add pass_adjust_alignment.
>> ---
>>  gcc/Makefile.in  |  1 +
>>  gcc/passes.def   |  1 +
>>  gcc/tree-adjust-alignment.cc | 92 
>>  gcc/tree-pass.h  |  1 +
>>  4 files changed, 95 insertions(+)
>>  create mode 100644 gcc/tree-adjust-alignment.cc
>>
>> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
>> index fa9923bb270..9b73288f776 100644
>> --- a/gcc/Makefile.in
>> +++ b/gcc/Makefile.in
>> @@ -1545,6 +1545,7 @@ OBJS = \
>> ubsan.o \
>> sanopt.o \
>> sancov.o \
>> +   tree-adjust-alignment.o \

Please rename the file to just 'adjust-alignment.c'

>> tree-call-cdce.o \
>> tree-cfg.o \
>> tree-cfgcleanup.o \
>> diff --git a/gcc/passes.def b/gcc/passes.def
>> index 2bf2cb78fc5..92cbe587a8a 100644
>> --- a/gcc/passes.def
>> +++ b/gcc/passes.def
>> @@ -183,6 +183,7 @@ along with GCC; see the file COPYING3.  If not see
>>NEXT_PASS (pass_oacc_device_lower);
>>NEXT_PASS (pass_omp_device_lower);
>>NEXT_PASS (pass_omp_target_link);
>> +  NEXT_PASS (pass_adjust_alignment);
>>NEXT_PASS (pass_all_optimizations);
>>PUSH_INSERT_PASSES_WITHIN (pass_all_optimizations)
>>NEXT_PASS (pass_remove_cgraph_callee_edges);
>> diff --git a/gcc/tree-adjust-alignment.cc b/gcc/tree-adjust-alignment.cc
>> new file mode 100644
>> index 000..77f38f6949b
>> --- /dev/null
>> +++ b/gcc/tree-adjust-alignment.cc
>> @@ -0,0 +1,92 @@
>> +/* Adjust alignment for local variable.
>> +   Copyright (C) 2003-2020 Free Software Foundation, Inc.

Just 2020 please

>> +   Contributed by Dorit Naishlos 

Eh?  Please put in your name.

>> +
>> +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 "system.h"
>> +#include "coretypes.h"
>> +#include "backend.h"
>> +#include "target.h"
>> +#include "tree.h"
>> +#include "gimple.h"
>> +#include "tree-pass.h"
>> +#include "cgraph.h"
>> +#include "fold-const.h"
>> +#include "gimple-iterator.h"
>> +#include "tree-cfg.h"
>> +#include "cfgloop.h"
>> +#include "tree-vectorizer.h"
>> +#include "tm_p.h"

Did you try to narrow down the set of includes?
Please do so, tree-vectorizer.h does not look needed.

>> +namespace {
>> +
>> +const pass_data pass_data_adjust_alignment =
>> +{
>> +  GIMPLE_PASS, /* type */
>> +  "adjust_alignment", /* name */
>> +  OPTGROUP_NONE, /* optinfo_flags */
>> +  TV_NONE, /* tv_id */
>> +  0, /* properties_required */
>> +  0, /* properties_provided */
>> +  0, /* properties_destroyed */
>> +  0, /* todo_flags_start */
>> +  0, /* todo_flags_finish */
>> +};
>> +
>> +class pass_adjust_alignment : public gimple_opt_pass
>> +{
>> +public:
>> +  pass_adjust_alignment (gcc::context *ctxt)
>> +: gimple_opt_pass (pass_data_adjust_alignment, ctxt)
>> +  {}
>> +
>> +  virtual unsigned int execute (function *);
>> +

excessive vertical space

>> +}; // class pass_adjust_alignment
>> +
>> +} // anon namespace
>> +
>> +/* Entry point to adjust_alignment pass.  */
>> +unsigned int
>> +pass_adjust_alignment::execute (function *fun) {

The { goes to the next line and the following lines indents

[ARM]: Fix typo in documentation.

[Srinath Parvathaneni]

The command line option to enable Armv8.1-M Mainline Security Extensions
has a typo and this patch corrects it.

Committed it under the obvious rule.
### Attachment also inlined for ease of reply###


diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
5bcffdd7e7b6014cbf577b7e738c199a6a63ec0b..2bc25d923b334678f418f443ec6ba9c763fd0e97
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -820,7 +820,7 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
   https://developer.arm.com/docs/101028/0010/custom-datapath-extension;>
   intrinsics has been added.
   Support for Armv8.1-M Mainline Security Extensions architecture has been 
added. The -mcmse option,
-  when used in combination with an Armv8.1-M Mainline architecture (for 
example: -march=armv8.1.m.main -mcmse),
+  when used in combination with an Armv8.1-M Mainline architecture (for 
example: -march=armv8.1-m.main -mcmse),
   now leads to the generation of improved code sequences when changing 
security states.
 
 

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
5bcffdd7e7b6014cbf577b7e738c199a6a63ec0b..2bc25d923b334678f418f443ec6ba9c763fd0e97
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -820,7 +820,7 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
   https://developer.arm.com/docs/101028/0010/custom-datapath-extension;>
   intrinsics has been added.
   Support for Armv8.1-M Mainline Security Extensions architecture has been 
added. The -mcmse option,
-  when used in combination with an Armv8.1-M Mainline architecture (for 
example: -march=armv8.1.m.main -mcmse),
+  when used in combination with an Armv8.1-M Mainline architecture (for 
example: -march=armv8.1-m.main -mcmse),
   now leads to the generation of improved code sequences when changing 
security states.
 
 

[PATCH] Fix missing assemble_external in ASM_OUTPUT_FDESC

[Andreas Schwab]

When TARGET_VTABLE_USES_DESCRIPTORS is defined then function pointers in
the vtable are output by ASM_OUTPUT_FDESC.  The only current user of
this is ia64, but its implementation of ASM_OUTPUT_FDESC lacks a call to
assemble_external.  Thus if there is no other reference to the function
the weak declaration for it will be missing.

PR target/95154
* config/ia64/ia64.h (ASM_OUTPUT_FDESC): Call assemble_external.
---
 gcc/config/ia64/ia64.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/ia64/ia64.h b/gcc/config/ia64/ia64.h
index 8462535d749..d5acc62cd87 100644
--- a/gcc/config/ia64/ia64.h
+++ b/gcc/config/ia64/ia64.h
@@ -963,6 +963,7 @@ do {
\
 do {   \
   if ((PART) == 0) \
 {  \
+  assemble_external (DECL);
\
   if (TARGET_ILP32)
\
 fputs ("\tdata8.ua @iplt(", FILE); \
   else \
-- 
2.26.2


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] tree-optimization/95172 - avoid mixing conditionalized and ordered SM

[Richard Biener]

The following testcase shows a missed optimization that then leads to
wrong-code when issueing SMed stores on exits.  When we were able to
compute an ordered sequence of stores for an exit we need to emit
that in the correct order and we can emit it disregarding to any
conditional for whether a store actually happened (we know it did).
We can also improve detection as of whether we need conditional
processing at all.  Both parts fix the testcase.

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

2020-05-18  Richard Biener  

PR tree-optimization/95172
* tree-ssa-loop-im.c (execute_sm): Get flag whether we
eventually need the conditional processing.
(execute_sm_exit): When processing an orderd sequence
avoid doing any conditional processing.
(hoist_memory_references): Pass down whether all edges
have ordered processing for a ref to execute_sm.

* gcc.dg/torture/pr95172.c: New testcase.
---
 gcc/testsuite/gcc.dg/torture/pr95172.c | 17 +
 gcc/tree-ssa-loop-im.c | 11 ++-
 2 files changed, 23 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr95172.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr95172.c 
b/gcc/testsuite/gcc.dg/torture/pr95172.c
new file mode 100644
index 000..b39de69f08e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr95172.c
@@ -0,0 +1,17 @@
+/* { dg-do run } */
+
+int a, d;
+int *b = 
+short c;
+int main()
+{
+  for (; c <= 4; c--) {
+for (; d;)
+  ;
+a = 1;
+*b = 0;
+  }
+  if (a != 0)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 0d77aaa08a5..63f4ef8883c 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -2130,7 +2130,7 @@ struct sm_aux
 
 static void
 execute_sm (class loop *loop, im_mem_ref *ref,
-   hash_map _map)
+   hash_map _map, bool maybe_mt)
 {
   gassign *load;
   struct fmt_data fmt_data;
@@ -2154,8 +2154,9 @@ execute_sm (class loop *loop, im_mem_ref *ref,
   for_each_index (>mem.ref, force_move_till, _data);
 
   bool always_stored = ref_always_accessed_p (loop, ref, true);
-  if (bb_in_transaction (loop_preheader_edge (loop)->src)
-  || (! flag_store_data_races && ! always_stored))
+  if (maybe_mt
+  && (bb_in_transaction (loop_preheader_edge (loop)->src)
+ || (! flag_store_data_races && ! always_stored)))
 multi_threaded_model_p = true;
 
   if (multi_threaded_model_p)
@@ -2244,7 +2245,7 @@ execute_sm_exit (class loop *loop, edge ex, 
vec ,
   else
{
  sm_aux *aux = *aux_map.get (ref);
- if (!aux->store_flag)
+ if (!aux->store_flag || kind == sm_ord)
{
  gassign *store;
  store = gimple_build_assign (unshare_expr (ref->mem.ref),
@@ -2630,7 +2631,7 @@ hoist_memory_references (class loop *loop, bitmap 
mem_refs,
   EXECUTE_IF_SET_IN_BITMAP (mem_refs, 0, i, bi)
 {
   ref = memory_accesses.refs_list[i];
-  execute_sm (loop, ref, aux_map);
+  execute_sm (loop, ref, aux_map, bitmap_bit_p (refs_not_supported, i));
 }
 
   /* Materialize ordered store sequences on exits.  */
-- 
2.12.3

[PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

[Mark Eggleston]

Please find attached a patch for PR39695 (this time it is attached).

Commit message:

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

2020-05-18  Mark Eggleston 

gcc/fortran/

    PR fortran/39695
    * resolve.c (resolve_fl_procedure): Set name depending on
    whether the result attribute is set.  For PROCEDURE/RESULT
    conflict use the name in sym->ns->proc_name->name.
    * symbol.c (gfc_add_type): Add check for function and result
    attributes use sym->ns->proc_name->name if both are set.
    Where the symbol cannot have a type use the name in
    sym->ns->proc_name->name.

2020-05-18  Mark Eggleston 

gcc/testsuite/

    PR fortran/39695
    * gfortran.dg/pr39695_1.f90: New test.
    * gfortran.dg/pr39695_2.f90: New test.
    * gfortran.dg/pr39695_3.f90: New test.
    * gfortran.dg/pr39695_4.f90: New test.

Tested on x86_64 using make check-fortran for master, gcc-8, gcc-9 and 
gcc-10.


OK to to commit and backport?

--
https://www.codethink.co.uk/privacy.html

>From 8b4e6cb6d72b7c40aa87ca3bbdb1e2bbb7c5a23e Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Thu, 7 May 2020 08:02:02 +0100
Subject: [PATCH] Fortran  : ProcPtr function results: 'ppr@' in error message
 PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

2020-05-18  Mark Eggleston  

gcc/fortran/

	PR fortran/39695
	* resolve.c (resolve_fl_procedure): Set name depending on
	whether the result attribute is set.  For PROCEDURE/RESULT
	conflict use the name in sym->ns->proc_name->name.
	* symbol.c (gfc_add_type): Add check for function and result
	attributes use sym->ns->proc_name->name if both are set.
	Where the symbol cannot have a type use the name in
	sym->ns->proc_name->name.

2020-05-18  Mark Eggleston  

gcc/testsuite/

	PR fortran/39695
	* gfortran.dg/pr39695_1.f90: New test.
	* gfortran.dg/pr39695_2.f90: New test.
	* gfortran.dg/pr39695_3.f90: New test.
	* gfortran.dg/pr39695_4.f90: New test.
---
 gcc/fortran/resolve.c   |  6 --
 gcc/fortran/symbol.c|  7 +--
 gcc/testsuite/gfortran.dg/pr39695_1.f90 |  8 
 gcc/testsuite/gfortran.dg/pr39695_2.f90 | 12 
 gcc/testsuite/gfortran.dg/pr39695_3.f90 | 11 +++
 gcc/testsuite/gfortran.dg/pr39695_4.f90 | 14 ++
 6 files changed, 54 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr39695_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/pr39695_2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/pr39695_3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/pr39695_4.f90

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index fd3b025a84f..bcd89efdc16 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13123,8 +13123,10 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
 {
   if (sym->attr.proc_pointer)
 	{
+	  const char* name = (sym->attr.result ? sym->ns->proc_name->name
+	   : sym->name);
 	  gfc_error ("Procedure pointer %qs at %L shall not be elemental",
-		 sym->name, >declared_at);
+		 name, >declared_at);
 	  return false;
 	}
   if (sym->attr.dummy)
@@ -13211,7 +13213,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
   if (sym->attr.subroutine && sym->attr.result)
 	{
 	  gfc_error ("PROCEDURE attribute conflicts with RESULT attribute "
-		 "in %qs at %L", sym->name, >declared_at);
+		 "in %qs at %L", sym->ns->proc_name->name, >declared_at);
 	  return false;
 	}
   if (sym->attr.external && sym->attr.function && !sym->attr.module_procedure
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index 59f602d80d5..b96706138c9 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -2004,9 +2004,12 @@ gfc_add_type (gfc_symbol *sym, gfc_typespec *ts, locus *where)
 	gfc_error ("Symbol %qs at %L conflicts with symbol from module %qs, "
 		   "use-associated at %L", sym->name, where, sym->module,
 		   >declared_at);
+  else if (sym->attr.function && sym->attr.result)
+	gfc_error ("Symbol %qs at %L already has basic type of %s",
+		   sym->ns->proc_name->name, where, gfc_basic_typename (type));
   else
 	gfc_error ("Symbol %qs at %L already has basic type of %s", sym->name,
-		 where, gfc_basic_typename (type));
+		   where, gfc_basic_typename (type));
   return false;
 }
 
@@ -2024,7 +2027,7 @@ gfc_add_type (gfc_symbol *sym, gfc_typespec *ts, locus *where)
   || (flavor == 

Re: [PATCH v4] Fix alignment for local variable [PR90811]

[Kito Cheng]

ping

On Tue, Apr 14, 2020 at 2:53 PM Kito Cheng  wrote:

>  - The alignment for local variable was adjust during
> estimate_stack_frame_size,
>however it seems wrong spot to adjust that, expand phase will adjust
> that
>but it little too late to some gimple optimization, which rely on
> certain
>target hooks need to check alignment, forwprop is an example for
>that, result of simplify_builtin_call rely on the alignment on some
>target like ARM or RISC-V.
>
>  - Exclude static local var and hard register var in the process of
>alignment adjustment.
>
>  - This patch fix gfortran.dg/pr45636.f90 for arm and riscv.
>
>  - Regression test on riscv32/riscv64 and x86_64-linux-gnu, no new fail
>introduced.
>
> gcc/ChangeLog
>
> PR target/90811
> * Makefile.in (OBJS): Add tree-adjust-alignment.o.
> * tree-adjust-alignment.cc (pass_data_adjust_alignment): New.
> (pass_adjust_alignment): New.
> (-pass_adjust_alignment::execute): New.
> (make_pass_adjust_alignment): New.
> * tree-pass.h (make_pass_adjust_alignment): New.
> * passes.def: Add pass_adjust_alignment.
> ---
>  gcc/Makefile.in  |  1 +
>  gcc/passes.def   |  1 +
>  gcc/tree-adjust-alignment.cc | 92 
>  gcc/tree-pass.h  |  1 +
>  4 files changed, 95 insertions(+)
>  create mode 100644 gcc/tree-adjust-alignment.cc
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index fa9923bb270..9b73288f776 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1545,6 +1545,7 @@ OBJS = \
> ubsan.o \
> sanopt.o \
> sancov.o \
> +   tree-adjust-alignment.o \
> tree-call-cdce.o \
> tree-cfg.o \
> tree-cfgcleanup.o \
> diff --git a/gcc/passes.def b/gcc/passes.def
> index 2bf2cb78fc5..92cbe587a8a 100644
> --- a/gcc/passes.def
> +++ b/gcc/passes.def
> @@ -183,6 +183,7 @@ along with GCC; see the file COPYING3.  If not see
>NEXT_PASS (pass_oacc_device_lower);
>NEXT_PASS (pass_omp_device_lower);
>NEXT_PASS (pass_omp_target_link);
> +  NEXT_PASS (pass_adjust_alignment);
>NEXT_PASS (pass_all_optimizations);
>PUSH_INSERT_PASSES_WITHIN (pass_all_optimizations)
>NEXT_PASS (pass_remove_cgraph_callee_edges);
> diff --git a/gcc/tree-adjust-alignment.cc b/gcc/tree-adjust-alignment.cc
> new file mode 100644
> index 000..77f38f6949b
> --- /dev/null
> +++ b/gcc/tree-adjust-alignment.cc
> @@ -0,0 +1,92 @@
> +/* Adjust alignment for local variable.
> +   Copyright (C) 2003-2020 Free Software Foundation, Inc.
> +   Contributed by Dorit Naishlos 
> +
> +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 "system.h"
> +#include "coretypes.h"
> +#include "backend.h"
> +#include "target.h"
> +#include "tree.h"
> +#include "gimple.h"
> +#include "tree-pass.h"
> +#include "cgraph.h"
> +#include "fold-const.h"
> +#include "gimple-iterator.h"
> +#include "tree-cfg.h"
> +#include "cfgloop.h"
> +#include "tree-vectorizer.h"
> +#include "tm_p.h"
> +
> +namespace {
> +
> +const pass_data pass_data_adjust_alignment =
> +{
> +  GIMPLE_PASS, /* type */
> +  "adjust_alignment", /* name */
> +  OPTGROUP_NONE, /* optinfo_flags */
> +  TV_NONE, /* tv_id */
> +  0, /* properties_required */
> +  0, /* properties_provided */
> +  0, /* properties_destroyed */
> +  0, /* todo_flags_start */
> +  0, /* todo_flags_finish */
> +};
> +
> +class pass_adjust_alignment : public gimple_opt_pass
> +{
> +public:
> +  pass_adjust_alignment (gcc::context *ctxt)
> +: gimple_opt_pass (pass_data_adjust_alignment, ctxt)
> +  {}
> +
> +  virtual unsigned int execute (function *);
> +
> +}; // class pass_adjust_alignment
> +
> +} // anon namespace
> +
> +/* Entry point to adjust_alignment pass.  */
> +unsigned int
> +pass_adjust_alignment::execute (function *fun) {
> +  size_t i;
> +  tree var;
> +  unsigned int align;
> +
> +  FOR_EACH_LOCAL_DECL (fun, i, var)
> +{
> +  /* Don't adjust aligment for static local var and hard register
> var.  */
> +  if (is_global_var (var) || DECL_HARD_REGISTER (var))
> +   continue;
> +
> +  align = LOCAL_DECL_ALIGNMENT (var);
> +
> +  /* Make sure alignment only increase.  */
> +  gcc_assert (align >= DECL_ALIGN (var));
> +
> +  SET_DECL_ALIGN (var, align);
> +}
> 

[PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

[Mark Eggleston]

Please find attache a patch for PR39695

Commit message:

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

2020-05-18  Mark Eggleston 

gcc/fortran/

    PR fortran/39695
    * resolve.c (resolve_fl_procedure): Set name depending on
    whether the result attribute is set.  For PROCEDURE/RESULT
    conflict use the name in sym->ns->proc_name->name.
    * symbol.c (gfc_add_type): Add check for function and result
    attributes use sym->ns->proc_name->name if both are set.
    Where the symbol cannot have a type use the name in
    sym->ns->proc_name->name.

2020-05-18  Mark Eggleston 

gcc/testsuite/

    PR fortran/39695
    * gfortran.dg/pr39695_1.f90: New test.
    * gfortran.dg/pr39695_2.f90: New test.
    * gfortran.dg/pr39695_3.f90: New test.
    * gfortran.dg/pr39695_4.f90: New test.

Tested on x86_64 using make check-fortran for master, gcc-8, gcc-9 and 
gcc-10.


OK to to commit and backport?

--
https://www.codethink.co.uk/privacy.html