[PATCH] i386: Replace frame pointer with stack pointer in debug insns

[H.J. Lu]

When we eliminate frame pointer, we should also replace frame pointer
with stack pointer - UNITS_PER_WORD in debug insns.  This patch fixed:

FAIL: gcc.dg/guality/pr58791-5.c   -Os  line pr58791-5.c:20 b1 == 9
FAIL: gcc.dg/guality/pr58791-5.c   -Os  line pr58791-5.c:20 b2 == 73
FAIL: gcc.dg/guality/pr58791-5.c   -Os  line pr58791-5.c:20 b3 == 585
FAIL: gcc.dg/guality/pr58791-5.c   -Os  line pr58791-5.c:20 b4 == 4681
FAIL: gcc.dg/guality/pr59776.c   -Os  line pr59776.c:17 s1.f == 5.0
FAIL: gcc.dg/guality/pr59776.c   -Os  line pr59776.c:17 s1.g == 6.0
FAIL: gcc.dg/guality/pr59776.c   -Os  line pr59776.c:17 s2.g == 6.0
FAIL: gcc.dg/guality/pr59776.c   -Os  line pr59776.c:20 s1.f == 5.0
FAIL: gcc.dg/guality/pr59776.c   -Os  line pr59776.c:20 s1.g == 6.0
FAIL: gcc.dg/guality/pr59776.c   -Os  line pr59776.c:20 s2.f == 5.0
FAIL: gcc.dg/guality/pr59776.c   -Os  line pr59776.c:20 s2.g == 6.0

on Linux/i386.

Tested on i686 and x86-64.  OK for trunk?

H.J.
---

PR target/81820
* config/i386/i386.c (ix86_finalize_stack_frame_flags): Replace
frame pointer with stack pointer - UNITS_PER_WORD in debug insns.
---
 gcc/config/i386/i386.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b04321a8d40..0094f2c4441 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -14281,6 +14281,42 @@ ix86_finalize_stack_frame_flags (void)
   df_scan_blocks ();
   df_compute_regs_ever_live (true);
   df_analyze ();
+
+  if (flag_var_tracking)
+   {
+ /* Since frame pointer is no longer needed, replace it with
+stack pointer - UNITS_PER_WORD in debug insns.  */
+ df_ref ref, next;
+ for (ref = DF_REG_USE_CHAIN (HARD_FRAME_POINTER_REGNUM);
+  ref; ref = next)
+   {
+ rtx_insn *insn = DF_REF_INSN (ref);
+ /* Make sure the next ref is for a different instruction,
+so that we're not affected by the rescan.  */
+ next = DF_REF_NEXT_REG (ref);
+ while (next && DF_REF_INSN (next) == insn)
+   next = DF_REF_NEXT_REG (next);
+
+ if (DEBUG_INSN_P (insn))
+   {
+ bool changed = false;
+ for (; ref != next; ref = DF_REF_NEXT_REG (ref))
+   {
+ rtx *loc = DF_REF_LOC (ref);
+ if (*loc == hard_frame_pointer_rtx)
+   {
+ *loc = plus_constant (Pmode,
+   stack_pointer_rtx,
+   -UNITS_PER_WORD);
+ changed = true;
+   }
+   }
+ if (changed)
+   df_insn_rescan (insn);
+   }
+   }
+   }
+
   recompute_frame_layout_p = true;
 }
 
-- 
2.13.4

Re: [RS6000] linux startfile/endfile

[Segher Boessenkool]

On Fri, Aug 11, 2017 at 12:23:26PM +0930, Alan Modra wrote:
> These need to match the gnu-user.h definitions to support
> --enable-default-pie.  Otherwise we end up linking the wrong startup
> files when defaulting to PIE.
> 
> I've just copied the HAVE_LD_PIE variants as we don't need the
> !HAVE_LD_PIE variant.  (In fact, gnu-user.h doesn't need them either.)
> 
> Bootstrapped and regression tested powerpc64-linux and
> powerpc64le-linux.  OK?

Okay for trunk, and backports if you need/want them (do you?)  Thanks,


Segher


>   PR target/81170
>   PR target/81295
>   * config/rs6000/sysv4.h (STARTFILE_LINUX_SPEC): Upgrade to
>   match gnu-user.h startfile.
>   (ENDFILE_LINUX_SPEC): Similarly.

Re: [PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining

[Jason Merrill]

On Fri, Aug 11, 2017 at 6:05 AM, Pierre-Marie de Rodat
 wrote:
> On 08/07/2017 08:42 PM, Jason Merrill wrote:
>>
>> Perhaps the DECL_ABSTRACT_ORIGIN check in my patch should be
>> decl_ultimate_origin instead, which should return null in that case?
>
>
> It looks like it worked, thanks! Note that I had to tweak a bit your change
> in process_scope_vars to avoid a crash in a couple of Fortran tests (at -O3
> -g). Also, as the gcc_unreachable appears in an IF block, I turned it into a
> gcc_assert and remove the corresponding IF.
>
> Here is the final patch version, bootstrapped and regtested on x86_64-linux.

OK.

Jason

[PATCH] [i386,testsuite] [PR 71958] Error on -mx32 with -mabi=ms

[Daniel Santos]

We currently error when -mx32 -mabi=sysv and we encounter a function
with attribute ms_abi, but we are not erroring on -mx32 and -mabi=ms
(either explicitly or when it is the default on Windows).  In fact, it
generates code that runs, but is of an undfined ABI.

I'm running -m64 and -m32 tests now and will run x32 tests when those
are done.  Presuming that I've corrected all existing tests that do not
filter out x32 target and there are no additional failures, is this OK
for head?

Thanks,
Daniel

gcc/ChangeLog:
2017-08-11  Daniel Santos  

* config/i386/i386.c (ix86_option_override_internal): Modify.
(ix86_function_type_abi): Likewise.

gcc/testsuite/ChangeLog:
2017-08-11  Daniel Santos  

* gcc.target/i386/pr71958.c: New test.
* gcc.target/i386/pr64409.c: Modify to skip on Windows.
* gcc.target/i386/pr46470.c: Modify to skip x32 target.
* gcc.target/i386/pr66275.c: Likewise.
* gcc.target/i386/pr68018.c: Likewise.

Signed-off-by: Daniel Santos 
---
 gcc/config/i386/i386.c  | 11 +--
 gcc/testsuite/gcc.target/i386/pr46470.c |  2 +-
 gcc/testsuite/gcc.target/i386/pr64409.c |  3 ++-
 gcc/testsuite/gcc.target/i386/pr66275.c |  2 +-
 gcc/testsuite/gcc.target/i386/pr68018.c |  2 +-
 gcc/testsuite/gcc.target/i386/pr71958.c |  8 
 6 files changed, 22 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr71958.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b04321a8d40..311a52c2a1f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -5585,6 +5585,9 @@ ix86_option_override_internal (bool main_args_p,
 
   if (TARGET_X32_P (opts->x_ix86_isa_flags))
 {
+  if (opts_set->x_ix86_abi == MS_ABI)
+   error ("-mx32 not supported with -mabi=ms");
+
   /* Always turn on OPTION_MASK_ISA_64BIT and turn off
 OPTION_MASK_ABI_64 for TARGET_X32.  */
   opts->x_ix86_isa_flags |= OPTION_MASK_ISA_64BIT;
@@ -8777,8 +8780,12 @@ ix86_function_type_abi (const_tree fntype)
   if (abi == SYSV_ABI
   && lookup_attribute ("ms_abi", TYPE_ATTRIBUTES (fntype)))
 {
-  if (TARGET_X32)
-   error ("X32 does not support ms_abi attribute");
+  static int warned;
+  if (TARGET_X32 && !warned)
+   {
+ error ("X32 does not support ms_abi attribute");
+ warned = 1;
+   }
 
   abi = MS_ABI;
 }
diff --git a/gcc/testsuite/gcc.target/i386/pr46470.c 
b/gcc/testsuite/gcc.target/i386/pr46470.c
index 9e8e731188e..c66a378a1ad 100644
--- a/gcc/testsuite/gcc.target/i386/pr46470.c
+++ b/gcc/testsuite/gcc.target/i386/pr46470.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target { ! x32 } } } */
 /* The pic register save adds unavoidable stack pointer references.  */
 /* { dg-skip-if "" { ia32 && { ! nonpic } } } */
 /* These options are selected to ensure 1 word needs to be allocated
diff --git a/gcc/testsuite/gcc.target/i386/pr64409.c 
b/gcc/testsuite/gcc.target/i386/pr64409.c
index 917472653f4..3dbd9a09f01 100644
--- a/gcc/testsuite/gcc.target/i386/pr64409.c
+++ b/gcc/testsuite/gcc.target/i386/pr64409.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { ! ia32 } } } */
 /* { dg-require-effective-target maybe_x32 } */
 /* { dg-options "-O0 -mx32" } */
+/* { xfail { "*-*-cygwin* *-*-mingw*" } } */
 
 int a;
-int* __attribute__ ((ms_abi)) fn1 () { return  } /* { dg-error "X32 does 
not support ms_abi attribute" } */
+int* __attribute__ ((ms_abi)) fn1 () { return  } /* { dg-error "X32 does 
not support ms_abi attribute" { target { ! "*-*-mingw* *-*-cygwin*" } } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr66275.c 
b/gcc/testsuite/gcc.target/i386/pr66275.c
index b8759aeb5ec..a1271857f6a 100644
--- a/gcc/testsuite/gcc.target/i386/pr66275.c
+++ b/gcc/testsuite/gcc.target/i386/pr66275.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
+/* { dg-do compile { target { *-*-linux* && { ! { ia32 || x32 } } } } } */
 /* { dg-options "-mabi=ms -fdump-rtl-dfinit" } */
 
 void
diff --git a/gcc/testsuite/gcc.target/i386/pr68018.c 
b/gcc/testsuite/gcc.target/i386/pr68018.c
index a0fa21e0b00..871fdddf643 100644
--- a/gcc/testsuite/gcc.target/i386/pr68018.c
+++ b/gcc/testsuite/gcc.target/i386/pr68018.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
+/* { dg-do compile { target { *-*-linux* && { ! { ia32 || x32 } } } } } */
 /* { dg-options "-O -mabi=ms -mstackrealign" } */
 
 typedef float V __attribute__ ((vector_size (16)));
diff --git a/gcc/testsuite/gcc.target/i386/pr71958.c 
b/gcc/testsuite/gcc.target/i386/pr71958.c
new file mode 100644
index 000..090d1970ca9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr71958.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-mx32 -mabi=ms" } */
+/* { dg-require-effective-target maybe_x32 } */
+/* { dg-excess-errors "not supported" } 

Re: [PATCH 0/2] add unique_ptr class

[Jonathan Wakely]

On 05/08/17 20:05 +0100, Pedro Alves wrote:

On 08/04/2017 07:52 PM, Jonathan Wakely wrote:

On 31/07/17 19:46 -0400, tbsaunde+...@tbsaunde.org wrote:

I've been saying I'd do this for a long time, but I'm finally getting to
importing the C++98 compatable unique_ptr class Pedro wrote for gdb a
while
back.


Thanks a lot for doing this!


I believe the gtl namespace also comes from Pedro, but GNU template
library seems as reasonable as any other name I can come up with.


Yes, I had suggested it here:

 https://sourceware.org/ml/gdb-patches/2017-02/msg00197.html



If it's inspired by "STL" then can we call it something else?

std::unique_ptr is not part of the STL, because the STL is a library
of containers and algorithms from the 1990s. std::unique_ptr is
something much newer that doesn't originate in the STL.

STL != C++ Standard Library


That I knew, but gtl was not really a reference to the
C++ Standard Library, so I don't see the problem.  It was supposed to
be the name of a library which would contain other C++ utilities
that would be shared by different GNU toolchain components.
Some of those bits would be inspired by, or be straight backports of
more-recent standards, but it'd be more than that.

An option would be to keep "gtl" as acronym, but expand it
to "GNU Toolchain Library" instead.


OK, that raises my hackles less. What bothered me was an apparent
analogy to "STL" when that isn't even the right name for the library
that provides the original unique_ptr.

And "template library" assumes we'd never add non-templates to it,
which is unlikely (you already mentioned offset_type, which isn't a
template).

It seems odd to make up a completely new acronym for this though,
rather than naming it after something that exists already in the
toolchain codebases.


For example, gdb has been growing C++ utilities under gdb/common/
that might be handy for gcc and other projects too, for example:

- enum_flags (type-safe enum bit flags)
- function_view (non-owning reference to callables)
- offset_type (type safe / distinct integer types to represent offsets
   into anything addressable)
- optional (C++11 backport of libstdc++'s std::optional)
- refcounted_object.h (intrusively-refcounted types)
- scoped_restore (RAII save/restore of globals)
- an allocator that default-constructs using default-initialization
  instead of value-initialization.

and more.

GCC OTOH has code that might be handy for GDB as well, like for
example the open addressing hash tables (hash_map/hash_table/hash_set
etc.).

Maybe Gold could make use of some of this code too.  There
are some bits in Gold that might be useful for (at least) GDB
too.  For example, its Stringpool class.

I think there's a lot of scope for sharing more code between the
different components of the GNU toolchain, even beyond general
random utilities and data structures, and I'd love to see us
move more in that direction.


If we want a namespace for GNU utilities, what's wrong with "gnu"?


That'd be an "obvious" choice, and I'm not terribly against it,
though I wonder whether it'd be taking over a name that has a wider
scope than intended?  I.e., GNU is a larger set of projects than the
GNU toolchain.  For example, there's Gnulib, which already compiles
as libgnu.a / -lgnu, which might be confusing.  GCC doesn't currently
use Gnulib, but GDB does, and, there was work going on a while ago to
make GCC use gnulib as well.


Good point. "gnutools" might be more accurate, but people might object
to adding 10 extra characters for "gnutools::".

Naming is important, especially for a whole namespace (not just a
single type) so I do think it's worth spending time getting it right.

But I could live with gtl as long as nobody ever says "GTL is the GNU
STL" or mentions "gtl" and STL in the same breath :-)

Re: [PATCH, rs6000] More diagnostic cleanup, addressing PR79845

[Segher Boessenkool]

On Fri, Aug 11, 2017 at 02:21:17PM -0500, Bill Schmidt wrote:
> >>   if (nargs == 0)
> >>{
> >> -error ("%s only accepts %d arguments", name, (fcode == 
> >> ALTIVEC_BUILTIN_VEC_PROMOTE)+1 );
> >> +error ("builtin %qs only accepts %d arguments", name,
> >> +   (fcode == ALTIVEC_BUILTIN_VEC_PROMOTE)+1 );
> >>  return error_mark_node;
> >>}
> >>   if (fcode == ALTIVEC_BUILTIN_VEC_SPLATS && nargs != 1)
> >>{
> >> -error ("%s only accepts 1 argument", name);
> >> +error ("builtin %qs only accepts 1 argument", name);
> >>  return error_mark_node;
> >>}
> >>   if (fcode == ALTIVEC_BUILTIN_VEC_PROMOTE && nargs != 2)
> >>{
> >> -error ("%s only accepts 2 arguments", name);
> >> +error ("builtin %qs only accepts 2 arguments", name);
> >>  return error_mark_node;
> >>}
> > 
> > This last "if" is redundant with the handling of VEC_PROMOTE about ten
> > lines up.  Maybe the "if (nargs == 0)" should be ordered later and things
> > simplified?
> 
> Looks to me like it's equivalent to remove the whole "if (nargs == 0) {...}" 
> clause.

Ah, right, there is an if() around this allowing only these two fcodes.

> I'll regstrap that and commit if it's clean.  Thanks again!

No, thank you, this wasn't the most fun work to do ;-)


Segher

[og7] Adjust k80 resources

[Cesar Philippidis]

I've pushed this patch to openacc-gcc-7-branch to teach the libgomp
nvptx plugin how to cope with the hardware resources on K80 boards. K80
boards have two physical GPUs on a single board. Consequently, the CUDA
driver reports that 2x the amount of registers and shared memory are
available on those GPUs. But that's not true if only a single GPU is
being utilized. Consequently, this prevented the runtime from informing
the user that that K80 does not have sufficient hardware resources to
execute certain offloaded kernels.

Unfortunately, I don't have a test case which reproduce this failure,
but it does show up in various OpenACC tests such as cloverleaf. I'll
try to create a reduced test case that uses a lot of hardware registers
later.

Cesar
2017-08-11  Cesar Philippidis  

	libgomp/
	* plugin/cuda/cuda.h (CUdevice_attribute): Add
	CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR,
	CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR.
	* plugin/plugin-nvptx.c (struct ptx_device): Add
	compute_capability_major, compute_capability_minor members.
	(nvptx_open_device): Probe driver for those values.  Adjust 
	regs_per_sm and max_shared_memory_per_multiprocessor for K80
	hardware.

diff --git a/libgomp/plugin/cuda/cuda.h b/libgomp/plugin/cuda/cuda.h
index 25d5d1913b0..94a693cbdef 100644
--- a/libgomp/plugin/cuda/cuda.h
+++ b/libgomp/plugin/cuda/cuda.h
@@ -69,6 +69,8 @@ typedef enum {
   CU_DEVICE_ATTRIBUTE_CONCURRENT_KERNELS = 31,
   CU_DEVICE_ATTRIBUTE_MAX_THREADS_PER_MULTIPROCESSOR = 39,
   CU_DEVICE_ATTRIBUTE_ASYNC_ENGINE_COUNT = 40,
+  CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR = 75,
+  CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR = 76,
   CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_MULTIPROCESSOR = 82
 } CUdevice_attribute;
 
diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index 37e1f6efbe1..10f000ab3c1 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -285,7 +285,9 @@ struct ptx_device
   bool map;
   bool concur;
   bool mkern;
-  int  mode;
+  int mode;
+  int compute_capability_major;
+  int compute_capability_minor;
   int clock_khz;
   int num_sms;
   int regs_per_block;
@@ -448,6 +450,14 @@ nvptx_open_device (int n)
   ptx_dev->mode = pi;
 
   CUDA_CALL_ERET (NULL, cuDeviceGetAttribute,
+		  , CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR, dev);
+  ptx_dev->compute_capability_major = pi;
+
+  CUDA_CALL_ERET (NULL, cuDeviceGetAttribute,
+		  , CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR, dev);
+  ptx_dev->compute_capability_minor = pi;
+
+  CUDA_CALL_ERET (NULL, cuDeviceGetAttribute,
 		  , CU_DEVICE_ATTRIBUTE_INTEGRATED, dev);
   ptx_dev->mkern = pi;
 
@@ -512,20 +522,37 @@ nvptx_open_device (int n)
 
   GOMP_PLUGIN_debug (0, "Nvidia device %d:\n\tGPU_OVERLAP = %d\n"
 		 "\tCAN_MAP_HOST_MEMORY = %d\n\tCONCURRENT_KERNELS = %d\n"
-		 "\tCOMPUTE_MODE = %d\n\tINTEGRATED = %d\n"
+		 "\tCOMPUTE_MODE = %d\n"
+		 "\tCU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR = %d\n"
+		 "\tCU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR = %d\n"
+		 "\tINTEGRATED = %d\n"
 		 "\tMAX_THREADS_PER_BLOCK = %d\n\tWARP_SIZE = %d\n"
 		 "\tMULTIPROCESSOR_COUNT = %d\n"
 		 "\tMAX_THREADS_PER_MULTIPROCESSOR = %d\n"
 		 "\tMAX_REGISTERS_PER_MULTIPROCESSOR = %d\n"
 		 "\tMAX_SHARED_MEMORY_PER_MULTIPROCESSOR = %d\n",
 		 ptx_dev->ord, ptx_dev->overlap, ptx_dev->map,
-		 ptx_dev->concur, ptx_dev->mode, ptx_dev->mkern,
-		 ptx_dev->max_threads_per_block, ptx_dev->warp_size,
-		 ptx_dev->num_sms,
+		 ptx_dev->concur, ptx_dev->mode,
+		 ptx_dev->compute_capability_major,
+		 ptx_dev->compute_capability_minor,
+		 ptx_dev->mkern, ptx_dev->max_threads_per_block,
+		 ptx_dev->warp_size, ptx_dev->num_sms,
 		 ptx_dev->max_threads_per_multiprocessor,
 		 ptx_dev->regs_per_sm,
 		 ptx_dev->max_shared_memory_per_multiprocessor);
 
+  /* K80 (SM_37) boards contain two physical GPUs.  Consequntly they
+ report 2x larger values for MAX_REGISTERS_PER_MULTIPROCESSOR and
+ MAX_SHARED_MEMORY_PER_MULTIPROCESSOR.  Those values need to be
+ adjusted on order to allow the nvptx_exec to select an
+ appropriate num_workers.  */
+  if (ptx_dev->compute_capability_major == 3
+  && ptx_dev->compute_capability_minor == 7)
+{
+  ptx_dev->regs_per_sm /= 2;
+  ptx_dev->max_shared_memory_per_multiprocessor /= 2;
+}
+
   return ptx_dev;
 }
 

Re: [PATCH, rs6000] More diagnostic cleanup, addressing PR79845

[Bill Schmidt]

Hi Segher,

Thanks for the review!

> On Aug 11, 2017, at 2:14 PM, Segher Boessenkool  
> wrote:
> 
> Hi Bill,
> 
> On Thu, Aug 10, 2017 at 04:28:49PM -0500, Bill Schmidt wrote:
>> This continues the cleanup of diagnostic messages in the rs6000 back end.  
>> The
>> primary focus is to make sure that we use quoted strings with %qs, %<, %> as
>> appropriate, and that option strings are separated from translatable strings
>> to make things easier on the internationalization folks, as requested in
>> PR79845.  While working on this, I noticed a couple of places where the
>> diagnostic strings result in excessively long lines, and cleaned these up as
>> well.
>> 
>> One peculiarity I noticed, but did not attempt to address, is that a small
>> handful of diagnostic strings are tagged with _N ().  There doesn't seem to
>> be any rhyme or reason to this.  I expect it's a result of copy/paste from
>> somewhere and most of these strings should be translated.  But that's for
>> another day (and probably another person).
>> 
>> Bootstrapped and tested on powerpc64le-linux-gnu (POWER8 64-bit) and on
>> powerpc64-linux-gnu (POWER7 32- and 64-bit) with no regressions.  Is this
>> okay for trunk?
> 
> Yes, thank you!  One comment:
> 
>> @@ -6128,17 +6128,18 @@ altivec_resolve_overloaded_builtin (location_t loc
>> 
>>   if (nargs == 0)
>>  {
>> -  error ("%s only accepts %d arguments", name, (fcode == 
>> ALTIVEC_BUILTIN_VEC_PROMOTE)+1 );
>> +  error ("builtin %qs only accepts %d arguments", name,
>> + (fcode == ALTIVEC_BUILTIN_VEC_PROMOTE)+1 );
>>return error_mark_node;
>>  }
>>   if (fcode == ALTIVEC_BUILTIN_VEC_SPLATS && nargs != 1)
>>  {
>> -  error ("%s only accepts 1 argument", name);
>> +  error ("builtin %qs only accepts 1 argument", name);
>>return error_mark_node;
>>  }
>>   if (fcode == ALTIVEC_BUILTIN_VEC_PROMOTE && nargs != 2)
>>  {
>> -  error ("%s only accepts 2 arguments", name);
>> +  error ("builtin %qs only accepts 2 arguments", name);
>>return error_mark_node;
>>  }
> 
> This last "if" is redundant with the handling of VEC_PROMOTE about ten
> lines up.  Maybe the "if (nargs == 0)" should be ordered later and things
> simplified?

Looks to me like it's equivalent to remove the whole "if (nargs == 0) {...}" 
clause.
I'll regstrap that and commit if it's clean.  Thanks again!

Bill

> 
> Okay with or without making that nicer.
> 
> 
> Segher
> 

Re: [PATCH, rs6000] More diagnostic cleanup, addressing PR79845

[Segher Boessenkool]

Hi Bill,

On Thu, Aug 10, 2017 at 04:28:49PM -0500, Bill Schmidt wrote:
> This continues the cleanup of diagnostic messages in the rs6000 back end.  The
> primary focus is to make sure that we use quoted strings with %qs, %<, %> as
> appropriate, and that option strings are separated from translatable strings
> to make things easier on the internationalization folks, as requested in
> PR79845.  While working on this, I noticed a couple of places where the
> diagnostic strings result in excessively long lines, and cleaned these up as
> well.
> 
> One peculiarity I noticed, but did not attempt to address, is that a small
> handful of diagnostic strings are tagged with _N ().  There doesn't seem to
> be any rhyme or reason to this.  I expect it's a result of copy/paste from
> somewhere and most of these strings should be translated.  But that's for
> another day (and probably another person).
> 
> Bootstrapped and tested on powerpc64le-linux-gnu (POWER8 64-bit) and on
> powerpc64-linux-gnu (POWER7 32- and 64-bit) with no regressions.  Is this
> okay for trunk?

Yes, thank you!  One comment:

> @@ -6128,17 +6128,18 @@ altivec_resolve_overloaded_builtin (location_t loc
>  
>if (nargs == 0)
>   {
> -   error ("%s only accepts %d arguments", name, (fcode == 
> ALTIVEC_BUILTIN_VEC_PROMOTE)+1 );
> +   error ("builtin %qs only accepts %d arguments", name,
> +  (fcode == ALTIVEC_BUILTIN_VEC_PROMOTE)+1 );
> return error_mark_node;
>   }
>if (fcode == ALTIVEC_BUILTIN_VEC_SPLATS && nargs != 1)
>   {
> -   error ("%s only accepts 1 argument", name);
> +   error ("builtin %qs only accepts 1 argument", name);
> return error_mark_node;
>   }
>if (fcode == ALTIVEC_BUILTIN_VEC_PROMOTE && nargs != 2)
>   {
> -   error ("%s only accepts 2 arguments", name);
> +   error ("builtin %qs only accepts 2 arguments", name);
> return error_mark_node;
>   }

This last "if" is redundant with the handling of VEC_PROMOTE about ten
lines up.  Maybe the "if (nargs == 0)" should be ordered later and things
simplified?

Okay with or without making that nicer.


Segher

Re: [06/77] Make GET_MODE_WIDER return an opt_mode

[Richard Sandiford]

Jeff Law  writes:
> On 07/13/2017 02:40 AM, Richard Sandiford wrote:
>> GET_MODE_WIDER previously returned VOIDmode if no wider mode existed.
>> That would cause problems with stricter mode classes, since VOIDmode
>> isn't for example a valid scalar integer or floating-point mode.
>> This patch instead makes it return a new opt_mode class, which
>> holds either a T or nothing.
>> 
>> 2017-07-13  Richard Sandiford  
>>  Alan Hayward  
>>  David Sherwood  
>> 
>> gcc/
>>  * coretypes.h (opt_mode): New class.
>>  * machmode.h (opt_mode): Likewise.
>>  (opt_mode::else_void): New function.
>>  (opt_mode::operator *): Likewise.
>>  (opt_mode::exists): Likewise.
>>  (GET_MODE_WIDER_MODE): Turn into a function and return an opt_mode.
>>  (GET_MODE_2XWIDER_MODE): Likewise.
>>  (mode_iterator::get_wider): Update accordingly.
>>  (mode_iterator::get_2xwider): Likewise.
>>  (mode_iterator::get_known_wider): Likewise, turning into a template.
>>  * combine.c (make_extraction): Update use of GET_MODE_WIDER_MODE,
>>  forcing a wider mode to exist.
>>  * config/cr16/cr16.h (LONG_REG_P): Likewise.
>>  * rtlanal.c (init_num_sign_bit_copies_in_rep): Likewise.
>>  * config/c6x/c6x.c (c6x_rtx_costs): Update use of
>>  GET_MODE_2XWIDER_MODE, forcing a wider mode to exist.
>>  * lower-subreg.c (init_lower_subreg): Likewise.
>>  * optabs-libfuncs.c (init_sync_libfuncs_1): Likewise, but not
>>  on the final iteration.
>>  * config/i386/i386.c (ix86_expand_set_or_movmem): Check whether
>>  a wider mode exists before asking for a move pattern.
>>  (get_mode_wider_vector): Update use of GET_MODE_WIDER_MODE,
>>  forcing a wider mode to exist.
>>  (expand_vselect_vconcat): Update use of GET_MODE_2XWIDER_MODE,
>>  returning false if no such mode exists.
>>  * config/ia64/ia64.c (expand_vselect_vconcat): Likewise.
>>  * config/mips/mips.c (mips_expand_vselect_vconcat): Likewise.
>>  * expmed.c (init_expmed_one_mode): Update use of GET_MODE_WIDER_MODE.
>>  Avoid checking for a MODE_INT if we already know the mode is not a
>>  SCALAR_INT_MODE_P.
>>  (extract_high_half): Update use of GET_MODE_WIDER_MODE,
>>  forcing a wider mode to exist.
>>  (expmed_mult_highpart_optab): Likewise.
>>  (expmed_mult_highpart): Likewise.
>>  * expr.c (expand_expr_real_2): Update use of GET_MODE_WIDER_MODE,
>>  using else_void.
>>  * lto-streamer-in.c (lto_input_mode_table): Likewise.
>>  * optabs-query.c (find_widening_optab_handler_and_mode): Likewise.
>>  * stor-layout.c (bit_field_mode_iterator::next_mode): Likewise.
>>  * internal-fn.c (expand_mul_overflow): Update use of
>>  GET_MODE_2XWIDER_MODE.
>>  * omp-low.c (omp_clause_aligned_alignment): Likewise.
>>  * tree-ssa-math-opts.c (convert_mult_to_widen): Update use of
>>  GET_MODE_WIDER_MODE.
>>  (convert_plusminus_to_widen): Likewise.
>>  * tree-switch-conversion.c (array_value_type): Likewise.
>>  * var-tracking.c (emit_note_insn_var_location): Likewise.
>>  * tree-vrp.c (simplify_float_conversion_using_ranges): Likewise.
>>  Return false inside rather than outside the loop if no wider mode
>>  exists
>>  * optabs.c (expand_binop): Update use of GET_MODE_WIDER_MODE
>>  and GET_MODE_2XWIDER_MODE
>>  (can_compare_p): Use else_void.
>>  * gdbhooks.py (OptMachineModePrinter): New class.
>>  (build_pretty_printer): Use it for opt_mode.
>> 
>> gcc/ada/
>>  * gcc-interface/decl.c (validate_size): Update use of
>>  GET_MODE_WIDER_MODE, forcing a wider mode to exist.
> I'm not a big fan of the API here, particularly using operator* to
> handle asserting the mode exists.  I'd prefer to just use a member
> function rather than overloading operator*.
>
> What's the rationale behind using operator* to imply the assertion?
>
> THe changes themsleves look fine, it's really just a question of the API
> we present.

The original idea was to make opt_mode look pointer-ish, so that
the dyn_cast <...> result could be used in the same way as for
dyn_cast  etc.  The first cut therefore had operator bool ()
to test whether there was a mode and operator * to dereference it.

However, operator bool () created various subtle problems (as it always
seems to) so we dropped it in favour of exists ().  I was neutral
on whether we should keep '*' or switch to a function, so in the
end the status quo won out.  I'm happy to change it to a named
accessor though.

Any better ideas than "get ()" for the name?  Maybe something
to emphasis that it is asserting for non-nullness/non-emptiness
(which '*' does implicitly)?

Thanks,
Richard

Re: [14/77] Make libgcc_floating_mode_supported_p take a scalar_float_mode

[Jeff Law]

On 07/13/2017 02:43 AM, Richard Sandiford wrote:
> As per subject.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * target.def (libgcc_floating_mode_supported_p): Take a
>   scalar_float_mode.
>   * doc/tm.texi: Regenerate.
>   * targhooks.h (default_libgcc_floating_mode_supported_p): Take a
>   scalar_float_mode.
>   * targhooks.c (default_libgcc_floating_mode_supported_p): Likewise.
>   * config/aarch64/aarch64.c (aarch64_libgcc_floating_mode_supported_p):
>   Likewise.
OK.
jeff

Re: [13/77] Make floatn_mode return an opt_scalar_float_mode

[Jeff Law]

On 07/13/2017 02:43 AM, Richard Sandiford wrote:
> As per subject.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * target.def (default_floatn_mode): Return an opt_scalar_float_mode.
>   * doc/tm.texi: Regenerate.
>   * config/arm/arm.c (arm_floatn_mode): Return an opt_scalar_float_mode.
>   * config/powerpcspe/powerpcspe.c (rs6000_floatn_mode): Likewise.
>   * config/rs6000/rs6000.c (rs6000_floatn_mode): Likewise.
>   * targhooks.h (default_floatn_mode): Likewise.
>   * targhooks.c (default_floatn_mode): Likewise.
>   * tree.c (build_common_tree_nodes): Update accordingly.
OK.
jeff

Re: [12/77] Use opt_scalar_float_mode when iterating over float modes

[Jeff Law]

On 07/13/2017 02:42 AM, Richard Sandiford wrote:
> This means that we know when accessing the modes that the size is
> a compile-time constant, even for SVE.  It also enables stricter
> type safety in later patches.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * machmode.h (mode_iterator::start): Provide overload for opt_modes.
>   (mode_iterator::iterate_p): Likewise.
>   (mode_iterator::get_wider): Likewise.
>   * expr.c (init_expr_target): Use opt_scalar_float_mode.
> 
> gcc/ada/
>   * gcc-interface/misc.c (fp_prec_to_size): Use opt_scalar_float_mode.
>   (fp_size_to_prec): Likewise.
> 
> gcc/c-family/
>   * c-cppbuiltin.c (c_cpp_builtins): Use opt_scalar_float_mode.
> 
> gcc/fortran/
>   * trans-types.c (gfc_init_kinds): Use opt_scalar_float_mode
>   and FOR_EACH_MODE_IN_CLASS.

OK.
jeff

Re: [11/77] Add a float_mode_for_size helper function

[Jeff Law]

On 07/13/2017 02:42 AM, Richard Sandiford wrote:
> This provides a type-safe way to ask for a float mode and get it as a
> scalar_float_mode.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * coretypes.h (opt_scalar_float_mode): New typedef.
>   * machmode.h (float_mode_for_size): New function.
>   * emit-rtl.c (double_mode): Delete.
>   (init_emit_once): Use float_mode_for_size.
>   * stor-layout.c (layout_type): Likewise.
>   * gdbhooks.py (build_pretty_printer): Handle opt_scalar_float_mode.
OK.
jeff

Re: [10/77] Make assemble_real take a scalar_float_mode

[Jeff Law]

On 07/13/2017 02:41 AM, Richard Sandiford wrote:
> As per subject.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * output.h (assemble_real): Take a scalar_float_mode.
>   * config/arm/arm.c (arm_assemble_integer): Update accordingly.
>   * config/arm/arm.md (consttable_4): Likewise.
>   (consttable_8): Likewise.
>   (consttable_16): Likewise.
>   * config/mips/mips.md (consttable_float): Likewise.
>   * config/s390/s390.c (s390_output_pool_entry): Likewise.
>   * varasm.c (assemble_real): Take a scalar_float_mode.
>   (output_constant_pool_2): Update accordingly.
>   (output_constant): Likewise.
> 
OK.
jeff

Re: [09/77] Add SCALAR_FLOAT_TYPE_MODE

[Jeff Law]

On 07/13/2017 02:41 AM, Richard Sandiford wrote:
> This patch adds a macro that extracts the TYPE_MODE and forcibly
> converts it to a scalar_float_mode.  The forcible conversion
> includes a gcc_checking_assert that the mode is a SCALAR_FLOAT_MODE_P.
> 
> This becomes important as more static type checking is added by
> later patches.  It has the additional benefit of bypassing the
> VECTOR_TYPE_P (...) ? vector_type_mode (...) : ... condition
> in TYPE_MODE; in release builds the new macro is a simple
> field access.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * tree.h (SCALAR_FLOAT_TYPE_MODE): New macro.
>   * builtins.c (expand_builtin_signbit): Use it instead of TYPE_MODE.
>   * fold-const.c (fold_convert_const_real_from_fixed): Likewise.
>   (native_encode_real): Likewise.
>   (native_interpret_real): Likewise.
>   * hsa-brig.c (emit_immediate_scalar_to_buffer): Likewise.
>   * tree-vrp.c (simplify_float_conversion_using_ranges): Likewise.
> 
> gcc/cp/
>   * mangle.c (write_real_cst): Use SCALAR_FLOAT_TYPE_MODE
>   instead of TYPE_MODE.
> 
> gcc/fortran/
>   * target-memory.c (size_float): Use SCALAR_FLOAT_TYPE_MODE
>   instead of TYPE_MODE.
> 
> gcc/objc/
>   * objc-encoding.c (encode_type): Use SCALAR_FLOAT_TYPE_MODE
>   instead of TYPE_MODE.
OK.
jeff

Re: [08/77] Simplify gen_trunc/extend_conv_libfunc

[Jeff Law]

On 07/13/2017 02:40 AM, Richard Sandiford wrote:
> Replace checks of:
> 
>   GET_MODE_CLASS (fmode) != MODE_FLOAT && !DECIMAL_FLOAT_MODE_P (fmode)
> 
> with !is_a  and use MODE_CLASS equality/inequality
> instead of:
> 
>   (GET_MODE_CLASS (tmode) == MODE_FLOAT && DECIMAL_FLOAT_MODE_P (fmode))
>   || (GET_MODE_CLASS (fmode) == MODE_FLOAT && DECIMAL_FLOAT_MODE_P (tmode))
> 
> and:
> 
>   (GET_MODE_CLASS (tmode) == MODE_FLOAT
>&& GET_MODE_CLASS (fmode) == MODE_FLOAT)
>   || (DECIMAL_FLOAT_MODE_P (fmode) && DECIMAL_FLOAT_MODE_P (tmode))
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * optabs-libfuncs.c (gen_trunc_conv_libfunc): Use is_a
>   .  Simplify.
>   (gen_extend_conv_libfunc): Likewise.

OK.
jeff

Re: [07/77] Add scalar_float_mode

[Jeff Law]

On 07/13/2017 02:40 AM, Richard Sandiford wrote:
> This patch adds a scalar_float_mode class, which wraps a mode enum
> that is known to satisfy SCALAR_FLOAT_MODE_P.  Things like "SFmode"
> now give a scalar_float_mode object instead of a machine_mode.
> This in turn needs a change to the real.h format_helper, so that
> it can accept both machine_modes and scalar_float_modes.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * coretypes.h (scalar_float_mode): New type.
>   * machmode.h (mode_traits::from_int): Use machine_mode if
>   USE_ENUM_MODES is defined.
>   (is_a): New function.
>   (as_a): Likewise.
>   (dyn_cast): Likewise.
>   (scalar_float_mode): New class.
>   (scalar_float_mode::includes_p): New function.
>   (is_float_mode): Likewise.
>   * gdbhooks.py (MachineModePrinter): New class.
>   (build_pretty_printer): Use it for scalar_float_mode.
>   * real.h (FLOAT_MODE_FORMAT): Use as_a .
>   (format_helper::format_helper): Turn into a template.
>   * genmodes.c (get_mode_class): New function.
>   (emit_insn_modes_h): Give modes the class returned by get_mode_class,
>   or machine_mode if none.
>   * config/aarch64/aarch64.c (aarch64_simd_valid_immediate): Use
>   as_a .
>   * dwarf2out.c (mem_loc_descriptor): Likewise.
>   (insert_float): Likewise.
>   (add_const_value_attribute): Likewise.
>   * simplify-rtx.c (simplify_immed_subreg): Likewise.
>   * optabs.c (expand_absneg_bit): Take a scalar_float_mode.
>   (expand_unop): Update accordingly.
>   (expand_abs_nojump): Likewise.
>   (expand_copysign_absneg): Take a scalar_float_mode.
>   (expand_copysign_bit): Likewise.
>   (expand_copysign): Update accordingly.
> 
> gcc/ada/
>   * gcc-interface/utils.c (gnat_type_for_mode): Use is_a
>instead of SCALAR_FLOAT_MODE_P.
> 
> gcc/go/
>   * go-lang.c (go_langhook_type_for_mode): Use is_float_mode.
> 
OK.
jeff

Re: [06/77] Make GET_MODE_WIDER return an opt_mode

[Jeff Law]

On 07/13/2017 02:40 AM, Richard Sandiford wrote:
> GET_MODE_WIDER previously returned VOIDmode if no wider mode existed.
> That would cause problems with stricter mode classes, since VOIDmode
> isn't for example a valid scalar integer or floating-point mode.
> This patch instead makes it return a new opt_mode class, which
> holds either a T or nothing.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * coretypes.h (opt_mode): New class.
>   * machmode.h (opt_mode): Likewise.
>   (opt_mode::else_void): New function.
>   (opt_mode::operator *): Likewise.
>   (opt_mode::exists): Likewise.
>   (GET_MODE_WIDER_MODE): Turn into a function and return an opt_mode.
>   (GET_MODE_2XWIDER_MODE): Likewise.
>   (mode_iterator::get_wider): Update accordingly.
>   (mode_iterator::get_2xwider): Likewise.
>   (mode_iterator::get_known_wider): Likewise, turning into a template.
>   * combine.c (make_extraction): Update use of GET_MODE_WIDER_MODE,
>   forcing a wider mode to exist.
>   * config/cr16/cr16.h (LONG_REG_P): Likewise.
>   * rtlanal.c (init_num_sign_bit_copies_in_rep): Likewise.
>   * config/c6x/c6x.c (c6x_rtx_costs): Update use of
>   GET_MODE_2XWIDER_MODE, forcing a wider mode to exist.
>   * lower-subreg.c (init_lower_subreg): Likewise.
>   * optabs-libfuncs.c (init_sync_libfuncs_1): Likewise, but not
>   on the final iteration.
>   * config/i386/i386.c (ix86_expand_set_or_movmem): Check whether
>   a wider mode exists before asking for a move pattern.
>   (get_mode_wider_vector): Update use of GET_MODE_WIDER_MODE,
>   forcing a wider mode to exist.
>   (expand_vselect_vconcat): Update use of GET_MODE_2XWIDER_MODE,
>   returning false if no such mode exists.
>   * config/ia64/ia64.c (expand_vselect_vconcat): Likewise.
>   * config/mips/mips.c (mips_expand_vselect_vconcat): Likewise.
>   * expmed.c (init_expmed_one_mode): Update use of GET_MODE_WIDER_MODE.
>   Avoid checking for a MODE_INT if we already know the mode is not a
>   SCALAR_INT_MODE_P.
>   (extract_high_half): Update use of GET_MODE_WIDER_MODE,
>   forcing a wider mode to exist.
>   (expmed_mult_highpart_optab): Likewise.
>   (expmed_mult_highpart): Likewise.
>   * expr.c (expand_expr_real_2): Update use of GET_MODE_WIDER_MODE,
>   using else_void.
>   * lto-streamer-in.c (lto_input_mode_table): Likewise.
>   * optabs-query.c (find_widening_optab_handler_and_mode): Likewise.
>   * stor-layout.c (bit_field_mode_iterator::next_mode): Likewise.
>   * internal-fn.c (expand_mul_overflow): Update use of
>   GET_MODE_2XWIDER_MODE.
>   * omp-low.c (omp_clause_aligned_alignment): Likewise.
>   * tree-ssa-math-opts.c (convert_mult_to_widen): Update use of
>   GET_MODE_WIDER_MODE.
>   (convert_plusminus_to_widen): Likewise.
>   * tree-switch-conversion.c (array_value_type): Likewise.
>   * var-tracking.c (emit_note_insn_var_location): Likewise.
>   * tree-vrp.c (simplify_float_conversion_using_ranges): Likewise.
>   Return false inside rather than outside the loop if no wider mode
>   exists
>   * optabs.c (expand_binop): Update use of GET_MODE_WIDER_MODE
>   and GET_MODE_2XWIDER_MODE
>   (can_compare_p): Use else_void.
>   * gdbhooks.py (OptMachineModePrinter): New class.
>   (build_pretty_printer): Use it for opt_mode.
> 
> gcc/ada/
>   * gcc-interface/decl.c (validate_size): Update use of
>   GET_MODE_WIDER_MODE, forcing a wider mode to exist.
I'm not a big fan of the API here, particularly using operator* to
handle asserting the mode exists.  I'd prefer to just use a member
function rather than overloading operator*.

What's the rationale behind using operator* to imply the assertion?

THe changes themsleves look fine, it's really just a question of the API
we present.

jeff

Re: C PATCH to fix bogus inform with -Wc++-compat (PR c/81795)

[Joseph Myers]

On Fri, 11 Aug 2017, Marek Polacek wrote:

> Pretty trivial patch -- these two informs weren't properly guarded so
> they'd trigger even if the warning was disabled via #pragma.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

OK.

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

Re: [04/77] Add FOR_EACH iterators for modes

[Jeff Law]

On 07/13/2017 02:39 AM, Richard Sandiford wrote:
> The new iterators are:
> 
> - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class.
> 
> - FOR_EACH_MODE_FROM: iterate over all the modes in a class,
>   starting at a given mode.
> 
> - FOR_EACH_WIDER_MODE: iterate over all the modes in a class,
>   starting at the next widest mode after a given mode.
> 
> - FOR_EACH_2XWIDER_MODE: same, but considering only modes that
>   are two times wider than the previous mode.
> 
> - FOR_EACH_MODE_UNTIL: iterate over all the modes in a class until
>   a given mode is reached.
> 
> - FOR_EACH_MODE: iterate over all the modes in a class between
>   two given modes, inclusive of the first but not the second.
> 
> These help with the stronger type checking added by later patches,
> since every new mode will be in the same class as the previous one.
> 
> 2017-07-13  Richard Sandiford  
> Alan Hayward  
> David Sherwood  
> 
> gcc/
>   * machmode.h (mode_traits): New structure.
>   (get_narrowest_mode): New function.
>   (mode_iterator::start): Likewise.
>   (mode_iterator::iterate_p): Likewise.
>   (mode_iterator::get_wider): Likewise.
>   (mode_iterator::get_known_wider): Likewise.
>   (mode_iterator::get_2xwider): Likewise.
>   (FOR_EACH_MODE_IN_CLASS): New mode iterator.
>   (FOR_EACH_MODE): Likewise.
>   (FOR_EACH_MODE_FROM): Likewise.
>   (FOR_EACH_MODE_UNTIL): Likewise.
>   (FOR_EACH_WIDER_MODE): Likewise.
>   (FOR_EACH_2XWIDER_MODE): Likewise.
>   * builtins.c (expand_builtin_strlen): Use new mode iterators.
>   * combine.c (simplify_comparison): Likewise
>   * config/i386/i386.c (type_natural_mode): Likewise.
>   * cse.c (cse_insn): Likewise.
>   * dse.c (find_shift_sequence): Likewise.
>   * emit-rtl.c (init_derived_machine_modes): Likewise.
>   (init_emit_once): Likewise.
>   * explow.c (hard_function_value): Likewise.
>   * expmed.c (init_expmed_one_mode): Likewise.
>   (extract_fixed_bit_field_1): Likewise.
>   (extract_bit_field_1): Likewise.
>   (expand_divmod): Likewise.
>   (emit_store_flag_1): Likewise.
>   * expr.c (init_expr_target): Likewise.
>   (convert_move): Likewise.
>   (alignment_for_piecewise_move): Likewise.
>   (widest_int_mode_for_size): Likewise.
>   (emit_block_move_via_movmem): Likewise.
>   (copy_blkmode_to_reg): Likewise.
>   (set_storage_via_setmem): Likewise.
>   (compress_float_constant): Likewise.
>   * omp-low.c (omp_clause_aligned_alignment): Likewise.
>   * optabs-query.c (get_best_extraction_insn): Likewise.
>   * optabs.c (expand_binop): Likewise.
>   (expand_twoval_unop): Likewise.
>   (expand_twoval_binop): Likewise.
>   (widen_leading): Likewise.
>   (widen_bswap): Likewise.
>   (expand_parity): Likewise.
>   (expand_unop): Likewise.
>   (prepare_cmp_insn): Likewise.
>   (prepare_float_lib_cmp): Likewise.
>   (expand_float): Likewise.
>   (expand_fix): Likewise.
>   (expand_sfix_optab): Likewise.
>   * postreload.c (move2add_use_add2_insn): Likewise.
>   * reg-stack.c (reg_to_stack): Likewise.
>   * reginfo.c (choose_hard_reg_mode): Likewise.
>   * rtlanal.c (init_num_sign_bit_copies_in_rep): Likewise.
>   * stmt.c (emit_case_decision_tree): Likewise.
>   * stor-layout.c (mode_for_size): Likewise.
>   (smallest_mode_for_size): Likewise.
>   (mode_for_vector): Likewise.
>   (finish_bitfield_representative): Likewise.
>   * tree-ssa-math-opts.c (target_supports_divmod_p): Likewise.
>   * tree-vect-generic.c (type_for_widest_vector_mode): Likewise.
>   * tree-vect-stmts.c (vectorizable_conversion): Likewise.
>   * var-tracking.c (prepare_call_arguments): Likewise.
> 
> gcc/ada/
>   * gcc-interface/misc.c (fp_prec_to_size): Use new mode iterators.
>   (fp_size_to_prec): Likewise.
> 
> gcc/c-family/
>   * c-common.c (c_common_fixed_point_type_for_size): Use new mode
>   iterators.
>   * c-cppbuiltin.c (c_cpp_builtins): Likewise.
I would have missed the expmed.c goof.  THanks for looking at things
again after my first message.

With your fix to expmed.c this is OK.

Jeff

Re: *ping* [patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope

[Thomas Koenig]

Hi Paul,


It looks fine to me. OK for trunk.



Thanks, committed.


Paul

PS What about PR34640 ?


Your patch is OK if you bump the library version.

Regards

Thomas

Re: [04/77] Add FOR_EACH iterators for modes

[Jeff Law]

On 08/11/2017 11:16 AM, Richard Sandiford wrote:
> Hi Jeff,
> 
> First, many thanks for the reviews!
> 
> Jeff Law  writes:
>> On 07/13/2017 02:39 AM, Richard Sandiford wrote:
>>> The new iterators are:
>>>
>>> - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class.
>>>
>>> - FOR_EACH_MODE_FROM: iterate over all the modes in a class,
>>>   starting at a given mode.
>>>
>>> - FOR_EACH_WIDER_MODE: iterate over all the modes in a class,
>>>   starting at the next widest mode after a given mode.
>>>
>>> - FOR_EACH_2XWIDER_MODE: same, but considering only modes that
>>>   are two times wider than the previous mode.
>>>
>>> - FOR_EACH_MODE_UNTIL: iterate over all the modes in a class until
>>>   a given mode is reached.
>>>
>>> - FOR_EACH_MODE: iterate over all the modes in a class between
>>>   two given modes, inclusive of the first but not the second.
>>>
>>> These help with the stronger type checking added by later patches,
>>> since every new mode will be in the same class as the previous one.
>>>
>>> 2017-07-13  Richard Sandiford  
>>> Alan Hayward  
>>> David Sherwood  
>>>
>>> gcc/
>>> * machmode.h (mode_traits): New structure.
>>> (get_narrowest_mode): New function.
>>> (mode_iterator::start): Likewise.
>>> (mode_iterator::iterate_p): Likewise.
>>> (mode_iterator::get_wider): Likewise.
>>> (mode_iterator::get_known_wider): Likewise.
>>> (mode_iterator::get_2xwider): Likewise.
>>> (FOR_EACH_MODE_IN_CLASS): New mode iterator.
>>> (FOR_EACH_MODE): Likewise.
>>> (FOR_EACH_MODE_FROM): Likewise.
>>> (FOR_EACH_MODE_UNTIL): Likewise.
>>> (FOR_EACH_WIDER_MODE): Likewise.
>>> (FOR_EACH_2XWIDER_MODE): Likewise.
>>> * builtins.c (expand_builtin_strlen): Use new mode iterators.
>>> * combine.c (simplify_comparison): Likewise
>>> * config/i386/i386.c (type_natural_mode): Likewise.
>>> * cse.c (cse_insn): Likewise.
>>> * dse.c (find_shift_sequence): Likewise.
>>> * emit-rtl.c (init_derived_machine_modes): Likewise.
>>> (init_emit_once): Likewise.
>>> * explow.c (hard_function_value): Likewise.
>>> * expmed.c (init_expmed_one_mode): Likewise.
>>> (extract_fixed_bit_field_1): Likewise.
>>> (extract_bit_field_1): Likewise.
>>> (expand_divmod): Likewise.
>>> (emit_store_flag_1): Likewise.
>>> * expr.c (init_expr_target): Likewise.
>>> (convert_move): Likewise.
>>> (alignment_for_piecewise_move): Likewise.
>>> (widest_int_mode_for_size): Likewise.
>>> (emit_block_move_via_movmem): Likewise.
>>> (copy_blkmode_to_reg): Likewise.
>>> (set_storage_via_setmem): Likewise.
>>> (compress_float_constant): Likewise.
>>> * omp-low.c (omp_clause_aligned_alignment): Likewise.
>>> * optabs-query.c (get_best_extraction_insn): Likewise.
>>> * optabs.c (expand_binop): Likewise.
>>> (expand_twoval_unop): Likewise.
>>> (expand_twoval_binop): Likewise.
>>> (widen_leading): Likewise.
>>> (widen_bswap): Likewise.
>>> (expand_parity): Likewise.
>>> (expand_unop): Likewise.
>>> (prepare_cmp_insn): Likewise.
>>> (prepare_float_lib_cmp): Likewise.
>>> (expand_float): Likewise.
>>> (expand_fix): Likewise.
>>> (expand_sfix_optab): Likewise.
>>> * postreload.c (move2add_use_add2_insn): Likewise.
>>> * reg-stack.c (reg_to_stack): Likewise.
>>> * reginfo.c (choose_hard_reg_mode): Likewise.
>>> * rtlanal.c (init_num_sign_bit_copies_in_rep): Likewise.
>>> * stmt.c (emit_case_decision_tree): Likewise.
>>> * stor-layout.c (mode_for_size): Likewise.
>>> (smallest_mode_for_size): Likewise.
>>> (mode_for_vector): Likewise.
>>> (finish_bitfield_representative): Likewise.
>>> * tree-ssa-math-opts.c (target_supports_divmod_p): Likewise.
>>> * tree-vect-generic.c (type_for_widest_vector_mode): Likewise.
>>> * tree-vect-stmts.c (vectorizable_conversion): Likewise.
>>> * var-tracking.c (prepare_call_arguments): Likewise.
>>>
>>> gcc/ada/
>>> * gcc-interface/misc.c (fp_prec_to_size): Use new mode iterators.
>>> (fp_size_to_prec): Likewise.
>>>
>>> gcc/c-family/
>>> * c-common.c (c_common_fixed_point_type_for_size): Use new mode
>>> iterators.
>>> * c-cppbuiltin.c (c_cpp_builtins): Likewise.
>> So in some cases I see that we have loops like this:
>>
>> for (; mode != VOIDmode; mode = GET_WIDER_MODE (mode))
>>
>> Which iterates from the current mode through all the remaining modes,
>> with each iteration using a wider mode than the previous iteration.
>> GET_WIDER_MODE is always going to give us something in the same class or
>> VOIDmode.
>>
>> This is getting translated into:
>>
>> FOR_EACH_MODE_FROM (mode, mode)
>>
>> The two loops have different steps.  The original steps to a wider mode
>> each iteration.  The new one may step to a different mode of the same
>> width IIUC.
>>

Re: [04/77] Add FOR_EACH iterators for modes

[Richard Sandiford]

Hi Jeff,

First, many thanks for the reviews!

Jeff Law  writes:
> On 07/13/2017 02:39 AM, Richard Sandiford wrote:
>> The new iterators are:
>> 
>> - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class.
>> 
>> - FOR_EACH_MODE_FROM: iterate over all the modes in a class,
>>   starting at a given mode.
>> 
>> - FOR_EACH_WIDER_MODE: iterate over all the modes in a class,
>>   starting at the next widest mode after a given mode.
>> 
>> - FOR_EACH_2XWIDER_MODE: same, but considering only modes that
>>   are two times wider than the previous mode.
>> 
>> - FOR_EACH_MODE_UNTIL: iterate over all the modes in a class until
>>   a given mode is reached.
>> 
>> - FOR_EACH_MODE: iterate over all the modes in a class between
>>   two given modes, inclusive of the first but not the second.
>> 
>> These help with the stronger type checking added by later patches,
>> since every new mode will be in the same class as the previous one.
>> 
>> 2017-07-13  Richard Sandiford  
>> Alan Hayward  
>> David Sherwood  
>> 
>> gcc/
>>  * machmode.h (mode_traits): New structure.
>>  (get_narrowest_mode): New function.
>>  (mode_iterator::start): Likewise.
>>  (mode_iterator::iterate_p): Likewise.
>>  (mode_iterator::get_wider): Likewise.
>>  (mode_iterator::get_known_wider): Likewise.
>>  (mode_iterator::get_2xwider): Likewise.
>>  (FOR_EACH_MODE_IN_CLASS): New mode iterator.
>>  (FOR_EACH_MODE): Likewise.
>>  (FOR_EACH_MODE_FROM): Likewise.
>>  (FOR_EACH_MODE_UNTIL): Likewise.
>>  (FOR_EACH_WIDER_MODE): Likewise.
>>  (FOR_EACH_2XWIDER_MODE): Likewise.
>>  * builtins.c (expand_builtin_strlen): Use new mode iterators.
>>  * combine.c (simplify_comparison): Likewise
>>  * config/i386/i386.c (type_natural_mode): Likewise.
>>  * cse.c (cse_insn): Likewise.
>>  * dse.c (find_shift_sequence): Likewise.
>>  * emit-rtl.c (init_derived_machine_modes): Likewise.
>>  (init_emit_once): Likewise.
>>  * explow.c (hard_function_value): Likewise.
>>  * expmed.c (init_expmed_one_mode): Likewise.
>>  (extract_fixed_bit_field_1): Likewise.
>>  (extract_bit_field_1): Likewise.
>>  (expand_divmod): Likewise.
>>  (emit_store_flag_1): Likewise.
>>  * expr.c (init_expr_target): Likewise.
>>  (convert_move): Likewise.
>>  (alignment_for_piecewise_move): Likewise.
>>  (widest_int_mode_for_size): Likewise.
>>  (emit_block_move_via_movmem): Likewise.
>>  (copy_blkmode_to_reg): Likewise.
>>  (set_storage_via_setmem): Likewise.
>>  (compress_float_constant): Likewise.
>>  * omp-low.c (omp_clause_aligned_alignment): Likewise.
>>  * optabs-query.c (get_best_extraction_insn): Likewise.
>>  * optabs.c (expand_binop): Likewise.
>>  (expand_twoval_unop): Likewise.
>>  (expand_twoval_binop): Likewise.
>>  (widen_leading): Likewise.
>>  (widen_bswap): Likewise.
>>  (expand_parity): Likewise.
>>  (expand_unop): Likewise.
>>  (prepare_cmp_insn): Likewise.
>>  (prepare_float_lib_cmp): Likewise.
>>  (expand_float): Likewise.
>>  (expand_fix): Likewise.
>>  (expand_sfix_optab): Likewise.
>>  * postreload.c (move2add_use_add2_insn): Likewise.
>>  * reg-stack.c (reg_to_stack): Likewise.
>>  * reginfo.c (choose_hard_reg_mode): Likewise.
>>  * rtlanal.c (init_num_sign_bit_copies_in_rep): Likewise.
>>  * stmt.c (emit_case_decision_tree): Likewise.
>>  * stor-layout.c (mode_for_size): Likewise.
>>  (smallest_mode_for_size): Likewise.
>>  (mode_for_vector): Likewise.
>>  (finish_bitfield_representative): Likewise.
>>  * tree-ssa-math-opts.c (target_supports_divmod_p): Likewise.
>>  * tree-vect-generic.c (type_for_widest_vector_mode): Likewise.
>>  * tree-vect-stmts.c (vectorizable_conversion): Likewise.
>>  * var-tracking.c (prepare_call_arguments): Likewise.
>> 
>> gcc/ada/
>>  * gcc-interface/misc.c (fp_prec_to_size): Use new mode iterators.
>>  (fp_size_to_prec): Likewise.
>> 
>> gcc/c-family/
>>  * c-common.c (c_common_fixed_point_type_for_size): Use new mode
>>  iterators.
>>  * c-cppbuiltin.c (c_cpp_builtins): Likewise.
> So in some cases I see that we have loops like this:
>
> for (; mode != VOIDmode; mode = GET_WIDER_MODE (mode))
>
> Which iterates from the current mode through all the remaining modes,
> with each iteration using a wider mode than the previous iteration.
> GET_WIDER_MODE is always going to give us something in the same class or
> VOIDmode.
>
> This is getting translated into:
>
> FOR_EACH_MODE_FROM (mode, mode)
>
> The two loops have different steps.  The original steps to a wider mode
> each iteration.  The new one may step to a different mode of the same
> width IIUC.
>
> Am I missing something here?

The new iterators use GET_MODE_WIDER or GET_MODE_2XWIDER to step,

Re: [05/77] Small tweak to array_value_type

[Jeff Law]

On 07/13/2017 02:39 AM, Richard Sandiford wrote:
> Store the type mode in a variable so that a later,
> more mechanical patch can change its type.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * tree-switch-conversion.c (array_value_type): Only read TYPE_MODE
>   once.  Use get_narrowest_mode instead of GET_CLASS_NARROWEST_MODE.
OK.

jeff

Re: [04/77] Add FOR_EACH iterators for modes

[Jeff Law]

On 07/13/2017 02:39 AM, Richard Sandiford wrote:
> The new iterators are:
> 
> - FOR_EACH_MODE_IN_CLASS: iterate over all the modes in a mode class.
> 
> - FOR_EACH_MODE_FROM: iterate over all the modes in a class,
>   starting at a given mode.
> 
> - FOR_EACH_WIDER_MODE: iterate over all the modes in a class,
>   starting at the next widest mode after a given mode.
> 
> - FOR_EACH_2XWIDER_MODE: same, but considering only modes that
>   are two times wider than the previous mode.
> 
> - FOR_EACH_MODE_UNTIL: iterate over all the modes in a class until
>   a given mode is reached.
> 
> - FOR_EACH_MODE: iterate over all the modes in a class between
>   two given modes, inclusive of the first but not the second.
> 
> These help with the stronger type checking added by later patches,
> since every new mode will be in the same class as the previous one.
> 
> 2017-07-13  Richard Sandiford  
> Alan Hayward  
> David Sherwood  
> 
> gcc/
>   * machmode.h (mode_traits): New structure.
>   (get_narrowest_mode): New function.
>   (mode_iterator::start): Likewise.
>   (mode_iterator::iterate_p): Likewise.
>   (mode_iterator::get_wider): Likewise.
>   (mode_iterator::get_known_wider): Likewise.
>   (mode_iterator::get_2xwider): Likewise.
>   (FOR_EACH_MODE_IN_CLASS): New mode iterator.
>   (FOR_EACH_MODE): Likewise.
>   (FOR_EACH_MODE_FROM): Likewise.
>   (FOR_EACH_MODE_UNTIL): Likewise.
>   (FOR_EACH_WIDER_MODE): Likewise.
>   (FOR_EACH_2XWIDER_MODE): Likewise.
>   * builtins.c (expand_builtin_strlen): Use new mode iterators.
>   * combine.c (simplify_comparison): Likewise
>   * config/i386/i386.c (type_natural_mode): Likewise.
>   * cse.c (cse_insn): Likewise.
>   * dse.c (find_shift_sequence): Likewise.
>   * emit-rtl.c (init_derived_machine_modes): Likewise.
>   (init_emit_once): Likewise.
>   * explow.c (hard_function_value): Likewise.
>   * expmed.c (init_expmed_one_mode): Likewise.
>   (extract_fixed_bit_field_1): Likewise.
>   (extract_bit_field_1): Likewise.
>   (expand_divmod): Likewise.
>   (emit_store_flag_1): Likewise.
>   * expr.c (init_expr_target): Likewise.
>   (convert_move): Likewise.
>   (alignment_for_piecewise_move): Likewise.
>   (widest_int_mode_for_size): Likewise.
>   (emit_block_move_via_movmem): Likewise.
>   (copy_blkmode_to_reg): Likewise.
>   (set_storage_via_setmem): Likewise.
>   (compress_float_constant): Likewise.
>   * omp-low.c (omp_clause_aligned_alignment): Likewise.
>   * optabs-query.c (get_best_extraction_insn): Likewise.
>   * optabs.c (expand_binop): Likewise.
>   (expand_twoval_unop): Likewise.
>   (expand_twoval_binop): Likewise.
>   (widen_leading): Likewise.
>   (widen_bswap): Likewise.
>   (expand_parity): Likewise.
>   (expand_unop): Likewise.
>   (prepare_cmp_insn): Likewise.
>   (prepare_float_lib_cmp): Likewise.
>   (expand_float): Likewise.
>   (expand_fix): Likewise.
>   (expand_sfix_optab): Likewise.
>   * postreload.c (move2add_use_add2_insn): Likewise.
>   * reg-stack.c (reg_to_stack): Likewise.
>   * reginfo.c (choose_hard_reg_mode): Likewise.
>   * rtlanal.c (init_num_sign_bit_copies_in_rep): Likewise.
>   * stmt.c (emit_case_decision_tree): Likewise.
>   * stor-layout.c (mode_for_size): Likewise.
>   (smallest_mode_for_size): Likewise.
>   (mode_for_vector): Likewise.
>   (finish_bitfield_representative): Likewise.
>   * tree-ssa-math-opts.c (target_supports_divmod_p): Likewise.
>   * tree-vect-generic.c (type_for_widest_vector_mode): Likewise.
>   * tree-vect-stmts.c (vectorizable_conversion): Likewise.
>   * var-tracking.c (prepare_call_arguments): Likewise.
> 
> gcc/ada/
>   * gcc-interface/misc.c (fp_prec_to_size): Use new mode iterators.
>   (fp_size_to_prec): Likewise.
> 
> gcc/c-family/
>   * c-common.c (c_common_fixed_point_type_for_size): Use new mode
>   iterators.
>   * c-cppbuiltin.c (c_cpp_builtins): Likewise.
So in some cases I see that we have loops like this:

for (; mode != VOIDmode; mode = GET_WIDER_MODE (mode))

Which iterates from the current mode through all the remaining modes,
with each iteration using a wider mode than the previous iteration.
GET_WIDER_MODE is always going to give us something in the same class or
VOIDmode.

This is getting translated into:

FOR_EACH_MODE_FROM (mode, mode)

The two loops have different steps.  The original steps to a wider mode
each iteration.  The new one may step to a different mode of the same
width IIUC.

Am I missing something here?

I realize you won't want to use FOR_EACH_WIDER_MODE since that's got a
different starting point.  But we might want to have an iterator that
starts at the current mode, but steps to the net wider mode within 

C PATCH to fix bogus inform with -Wc++-compat (PR c/81795)

[Marek Polacek]

Pretty trivial patch -- these two informs weren't properly guarded so
they'd trigger even if the warning was disabled via #pragma.

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

2017-08-11  Marek Polacek  

PR c/81795
* c-decl.c (pushtag): Only print inform if the warning was printed.
(grokdeclarator): Likewise.

* gcc.dg/pr81795.c: New test.

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index d21fbc5883e..323d4480609 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -1557,11 +1557,10 @@ pushtag (location_t loc, tree name, tree type)
  && (TYPE_MAIN_VARIANT (TREE_TYPE (b->decl))
  != TYPE_MAIN_VARIANT (type)))
{
- warning_at (loc, OPT_Wc___compat,
- ("using %qD as both a typedef and a tag is "
-  "invalid in C++"),
- b->decl);
- if (b->locus != UNKNOWN_LOCATION)
+ if (warning_at (loc, OPT_Wc___compat,
+ ("using %qD as both a typedef and a tag is "
+  "invalid in C++"), b->decl)
+ && b->locus != UNKNOWN_LOCATION)
inform (b->locus, "originally defined here");
}
 }
@@ -6596,11 +6595,10 @@ grokdeclarator (const struct c_declarator *declarator,
  || (current_scope == file_scope && B_IN_EXTERNAL_SCOPE (b)))
  && TYPE_MAIN_VARIANT (b->decl) != TYPE_MAIN_VARIANT (type))
{
- warning_at (declarator->id_loc, OPT_Wc___compat,
- ("using %qD as both a typedef and a tag is "
-  "invalid in C++"),
- decl);
- if (b->locus != UNKNOWN_LOCATION)
+ if (warning_at (declarator->id_loc, OPT_Wc___compat,
+ ("using %qD as both a typedef and a tag is "
+  "invalid in C++"), decl)
+ && b->locus != UNKNOWN_LOCATION)
inform (b->locus, "originally defined here");
}
}
diff --git gcc/testsuite/gcc.dg/pr81795.c gcc/testsuite/gcc.dg/pr81795.c
index e69de29bb2d..b035bd0b530 100644
--- gcc/testsuite/gcc.dg/pr81795.c
+++ gcc/testsuite/gcc.dg/pr81795.c
@@ -0,0 +1,14 @@
+/* PR c/81795 */
+/* { dg-do compile } */
+/* { dg-options "-Wc++-compat" } */
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wc++-compat"
+
+struct S { int f; };   /* { dg-bogus "note: originally defined here" } */
+typedef int S; /* { dg-bogus "invalid in C\[+\]\[+\]" } */
+
+typedef int T; /* { dg-bogus "note: originally defined here" } */
+struct T { int f; };/* { dg-bogus "invalid in C\[+\]\[+\]" } */
+
+#pragma GCC diagnostic pop

Marek

Re: [03/77] Allow machine modes to be classes

[Jeff Law]

On 07/13/2017 02:38 AM, Richard Sandiford wrote:
> This patch makes various changes that allow modes like SImode to be
> classes rather than enums.
> 
> Firstly, it adds inline functions for all mode size properties,
> with the macros being simple wrappers around them.  This is necessary
> for the __builtin_constant_p trick to continue working effectively when
> the mode arguments are slightly more complex (but still foldable at
> compile time).
> 
> These inline functions are trivial and heavily used.  There's not much
> point keeping them out-of-line at -O0: if anything it would make
> debugging harder rather than easier, and it would also slow things down.
> The patch therefore marks them as "always_inline", if that's available.
> Later patches use this approach too.
> 
> Using inline functions means that it's no longer possible to pass
> an int to GET_MODE_PRECISION etc.  The Fortran and powerpcspe-c.c
> parts are needed to avoid instances of that.
> 
> The patch continues to use enums for gencondmd.c, so that more
> mode comparisons are integer constant expressions when checking
> for always-true or always-false conditions.  This is the only
> intended use of USE_ENUM_MODES.
> 
> The patch also enforces the previous replacement of case statements
> by defining modes as:
> 
>   #define FOOmode ((void) 0, E_FOOmode)
> 
> This adds no overhead but makes sure that new uses of "case FOOmode:"
> don't accidentally creep in when FOOmode has no specific class associated
> with it.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * genconditions.c (write_header): Add a "#define USE_ENUM_MODES".
>   * genmodes.c (emit_insn_modes_h): Define FOOmode to E_FOOmode if
>   USE_ENUM_MODES is defined and to ((void) 0, E_FOOmode) otherwise.
>   * machmode.h (mode_size): Move earlier in file.
>   (mode_precision): Likewise.
>   (mode_inner): Likewise.
>   (mode_nunits): Likewise.
>   (mode_unit_size): Likewise.
>   (unit_unit_precision): Likewise.
>   (mode_wider): Likewise.
>   (mode_2xwider): Likewise.
>   (machine_mode): New class.
>   (mode_to_bytes): New function.
>   (mode_to_bits): Likewise.
>   (mode_to_precision): Likewise.
>   (mode_to_inner): Likewise.
>   (mode_to_unit_size): Likewise.
>   (mode_to_unit_precision): Likewise.
>   (mode_to_nunits): Likewise.
>   (GET_MODE_SIZE): Use mode_to_bytes.
>   (GET_MODE_BITSIZE): Use mode_to_bits.
>   (GET_MODE_PRECISION): Use mode_to_precision.
>   (GET_MODE_INNER): Use mode_to_inner.
>   (GET_MODE_UNIT_SIZE): Use mode_to_unit_size.
>   (GET_MODE_UNIT_PRECISION): Use mode_to_unit_precision.
>   (GET_MODE_NUNITS): Use mode_to_nunits.
>   * system.h (ALWAYS_INLINE): New macro.
>   * config/powerpcspe/powerpcspe-c.c
>   (altivec_resolve_overloaded_builtin): Use machine_mode instead of
>   int for arg1_mode and arg2_mode.
> 
> gcc/fortran/
>   * trans-types.c (gfc_init_kinds): Use machine_mode instead of int
>   for "mode".
OK.
Jeff

Re: [02/77] Add an E_ prefix to mode names and update case statements

[Jeff Law]

On 07/13/2017 02:38 AM, Richard Sandiford wrote:
> All case statements need to be updated to use the prefixed names,
> since the unprefixed names will eventually not be integer constant
> expressions.  This patch does a mechanical substitution over the whole
> codebase.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * config/aarch64/aarch64-builtins.c (aarch64_simd_builtin_std_type):
>   Prefix mode names with E_ in case statements.
>   * config/aarch64/aarch64-elf.h (ASM_OUTPUT_ADDR_DIFF_ELT): Likewise.
>   * config/aarch64/aarch64.c (aarch64_split_simd_combine): Likewise.
>   (aarch64_split_simd_move): Likewise.
>   (aarch64_gen_storewb_pair): Likewise.
>   (aarch64_gen_loadwb_pair): Likewise.
>   (aarch64_gen_store_pair): Likewise.
>   (aarch64_gen_load_pair): Likewise.
>   (aarch64_get_condition_code_1): Likewise.
>   (aarch64_constant_pool_reload_icode): Likewise.
>   (get_rsqrte_type): Likewise.
>   (get_rsqrts_type): Likewise.
>   (get_recpe_type): Likewise.
>   (get_recps_type): Likewise.
>   (aarch64_gimplify_va_arg_expr): Likewise.
>   (aarch64_simd_container_mode): Likewise.
>   (aarch64_emit_load_exclusive): Likewise.
>   (aarch64_emit_store_exclusive): Likewise.
>   (aarch64_expand_compare_and_swap): Likewise.
>   (aarch64_gen_atomic_cas): Likewise.
>   (aarch64_emit_bic): Likewise.
>   (aarch64_emit_atomic_swap): Likewise.
>   (aarch64_emit_atomic_load_op): Likewise.
>   (aarch64_evpc_trn): Likewise.
>   (aarch64_evpc_uzp): Likewise.
>   (aarch64_evpc_zip): Likewise.
>   (aarch64_evpc_ext): Likewise.
>   (aarch64_evpc_rev): Likewise.
>   (aarch64_evpc_dup): Likewise.
>   (aarch64_gen_ccmp_first): Likewise.
>   (aarch64_gen_ccmp_next): Likewise.
>   * config/alpha/alpha.c (alpha_scalar_mode_supported_p): Likewise.
>   (alpha_emit_xfloating_libcall): Likewise.
>   (emit_insxl): Likewise.
>   (alpha_arg_type): Likewise.
>   * config/arc/arc.c (arc_vector_mode_supported_p): Likewise.
>   (arc_preferred_simd_mode): Likewise.
>   (arc_secondary_reload): Likewise.
>   (get_arc_condition_code): Likewise.
>   (arc_print_operand): Likewise.
>   * config/arc/arc.h (ASM_OUTPUT_ADDR_DIFF_ELT): Likewise.
>   * config/arc/arc.md (casesi_load): Likewise.
>   (casesi_compact_jump): Likewise.
>   * config/arc/predicates.md (proper_comparison_operator): Likewise.
>   (cc_use_register): Likewise.
>   * config/arm/aout.h (ASM_OUTPUT_ADDR_DIFF_ELT): Likewise.
>   * config/arm/arm-builtins.c (arm_simd_builtin_std_type): Likewise.
>   (arm_init_iwmmxt_builtins): Likewise.
>   * config/arm/arm.c (thumb1_size_rtx_costs): Likewise.
>   (neon_expand_vector_init): Likewise.
>   (arm_attr_length_move_neon): Likewise.
>   (maybe_get_arm_condition_code): Likewise.
>   (arm_emit_vector_const): Likewise.
>   (arm_preferred_simd_mode): Likewise.
>   (arm_output_iwmmxt_tinsr): Likewise.
>   (thumb1_output_casesi): Likewise.
>   (thumb2_output_casesi): Likewise.
>   (arm_emit_load_exclusive): Likewise.
>   (arm_emit_store_exclusive): Likewise.
>   (arm_expand_compare_and_swap): Likewise.
>   (arm_evpc_neon_vuzp): Likewise.
>   (arm_evpc_neon_vzip): Likewise.
>   (arm_evpc_neon_vrev): Likewise.
>   (arm_evpc_neon_vtrn): Likewise.
>   (arm_evpc_neon_vext): Likewise.
>   (arm_validize_comparison): Likewise.
>   * config/arm/neon.md (neon_vc): Likewise.
>   * config/avr/avr-c.c (avr_resolve_overloaded_builtin): Likewise.
>   * config/avr/avr.c (avr_rtx_costs_1): Likewise.
>   * config/c6x/c6x.c (c6x_vector_mode_supported_p): Likewise.
>   (c6x_preferred_simd_mode): Likewise.
>   * config/epiphany/epiphany.c (get_epiphany_condition_code): Likewise.
>   (epiphany_rtx_costs): Likewise.
>   * config/epiphany/predicates.md (proper_comparison_operator):
>   Likewise.
>   * config/frv/frv.c (condexec_memory_operand): Likewise.
>   (frv_emit_move): Likewise.
>   (output_move_single): Likewise.
>   (output_condmove_single): Likewise.
>   (frv_hard_regno_mode_ok): Likewise.
>   (frv_matching_accg_mode): Likewise.
>   * config/h8300/h8300.c (split_adds_subs): Likewise.
>   (h8300_rtx_costs): Likewise.
>   (h8300_print_operand): Likewise.
>   (compute_mov_length): Likewise.
>   (output_logical_op): Likewise.
>   (compute_logical_op_length): Likewise.
>   (compute_logical_op_cc): Likewise.
>   (h8300_shift_needs_scratch_p): Likewise.
>   (output_a_shift): Likewise.
>   (compute_a_shift_length): Likewise.
>   (compute_a_shift_cc): Likewise.
>   (expand_a_rotate): Likewise.
>   (output_a_rotate): Likewise.
>   * config/i386/i386.c 

Re: [01/77] Add an E_ prefix to mode names

[Jeff Law]

On 07/13/2017 02:36 AM, Richard Sandiford wrote:
> Later patches will add wrapper types for specific classes
> of mode.  E.g. SImode will be a scalar_int_mode, SFmode will be a
> scalar_float_mode, etc.  This patch prepares for that change by adding
> an E_ prefix to the mode enum values.  It also adds #defines that map
> the unprefixed names to the prefixed names; e.g:
> 
>   #define QImode E_QImode
> 
> Later patches will change this to use things like scalar_int_mode
> where appropriate.
> 
> The patch continues to use enum values to initialise static data.
> This isn't necessary for correctness, but it cuts down on the amount
> of load-time initialisation and shouldn't have any downsides.
> 
> The patch also changes things like:
> 
>   cmp_mode == DImode ? DFmode : DImode
> 
> to:
> 
>   cmp_mode == DImode ? E_DFmode : E_DImode
> 
> This is because DImode and DFmode will eventually be different
> classes, so the original ?: wouldn't be well-formed.
> 
> 2017-07-13  Richard Sandiford  
>   Alan Hayward  
>   David Sherwood  
> 
> gcc/
>   * genmodes.c (mode_size_inline): Add an E_ prefix to mode names.
>   (mode_nunits_inline): Likewise.
>   (mode_inner_inline): Likewise.
>   (mode_unit_size_inline): Likewise.
>   (mode_unit_precision_inline): Likewise.
>   (emit_insn_modes_h): Likewise.  Also emit a #define of the
>   unprefixed name.
>   (emit_mode_wider): Add an E_ prefix to mode names.
>   (emit_mode_complex): Likewise.
>   (emit_mode_inner): Likewise.
>   (emit_mode_adjustments): Likewise.
>   (emit_mode_int_n): Likewise.
>   * config/aarch64/aarch64-builtins.c (v8qi_UP, v4hi_UP, v4hf_UP)
>   (v2si_UP, v2sf_UP, v1df_UP, di_UP, df_UP, v16qi_UP, v8hi_UP, v8hf_UP)
>   (v4si_UP, v4sf_UP, v2di_UP, v2df_UP, ti_UP, oi_UP, ci_UP, xi_UP)
>   (si_UP, sf_UP, hi_UP, hf_UP, qi_UP): Likewise.
>   (CRC32_BUILTIN, ENTRY): Likewise.
>   * config/aarch64/aarch64.c (aarch64_push_regs): Likewise.
>   (aarch64_pop_regs): Likewise.
>   (aarch64_process_components): Likewise.
>   * config/alpha/alpha.c (alpha_emit_conditional_move): Likewise.
>   * config/arm/arm-builtins.c (v8qi_UP, v4hi_UP, v4hf_UP, v2si_UP)
>   (v2sf_UP, di_UP, v16qi_UP, v8hi_UP, v8hf_UP, v4si_UP, v4sf_UP)
>   (v2di_UP, ti_UP, ei_UP, oi_UP, hf_UP, si_UP, void_UP): Likewise.
>   * config/arm/arm.c (arm_init_libfuncs): Likewise.
>   * config/i386/i386-builtin-types.awk (ix86_builtin_type_vect_mode):
>   Likewise.
>   * config/i386/i386-builtin.def (pcmpestr): Likewise.
>   (pcmpistr): Likewise.
>   * config/microblaze/microblaze.c (double_memory_operand): Likewise.
>   * config/mmix/mmix.c (mmix_output_condition): Likewise.
>   * config/powerpcspe/powerpcspe.c (rs6000_init_hard_regno_mode_ok):
>   Likewise.
>   * config/rl78/rl78.c (mduc_regs): Likewise.
>   * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Likewise.
>   (htm_expand_builtin): Likewise.
>   * config/sh/sh.h (REGISTER_NATURAL_MODE): Likewise.
>   * config/sparc/sparc.c (emit_save_or_restore_regs): Likewise.
>   * config/xtensa/xtensa.c (print_operand): Likewise.
>   * expmed.h (NUM_MODE_PARTIAL_INT): Likewise.
>   (NUM_MODE_VECTOR_INT): Likewise.
>   * genoutput.c (null_operand): Likewise.
>   (output_operand_data): Likewise.
>   * genrecog.c (print_parameter_value): Likewise.
>   * lra.c (debug_operand_data): Likewise.
OK.  As are any natural tweaks to deal with changes that have occurred
on the trunk since this was submitted.

Jeff

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Joseph Myers]

On Fri, 11 Aug 2017, Martin Sebor wrote:

> > (An optional warning for different information in different declarations
> > is reasonable enough.  Actually in glibc it would be useful to have a
> > warning for a different but related case - two functions both declared,
> > later one defined as an alias of another, but the declarations don't have
> > the same attributes.  I'm pretty sure there are cases where the internal
> > declaration of __foo is missing attributes present on the public
> > declaration of foo.  But such a warning for aliases is only appropriate
> > for attributes that are properties of the function, not attributes that
> > are properties of particular names for it - __foo may well be a hidden
> > symbol where foo isn't.)
> 
> That does sound useful.  With the last pushed declaration now
> available to the attribute handlers it should be fairly easy
> to detect this problem in handle_alias_ifunc_attribute.  I'd
> be happy to look into implementing it after I'm done with this
> patch.  Can you please open a bug to request it?

Bug 81824 filed.

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

Re: [committed, nvptx] Add nvptx_override_options_after_change

[Thomas Schwinge]

Hi!

On Tue, 8 Aug 2017 10:58:12 +0200, Tom de Vries  wrote:
> On 08/08/2017 10:45 AM, Thomas Schwinge wrote:
> > On Fri, 21 Jul 2017 11:49:11 +0200, Tom de Vries  
> > wrote:
> >> this patch adds nvptx_override_options_after_change, containing a
> >> workaround for PR81430.

> > Should this be reverted now that r250852 "Apply finish_options on
> > DECL_FUNCTION_SPECIFIC_OPTIMIZATION for ACCEL_COMPILER" has been
> > committed?  (I'm confirming this works fine, thanks.)
> 
> Indeed, it can be reverted.

Committed to trunk in r251053:

commit 5b005e86c8c45aa84c090064b2f789c802384fc5
Author: tschwinge 
Date:   Fri Aug 11 15:37:14 2017 +

[PR lto/81430] Revert "Add nvptx_override_options_after_change"

This reverts r250421; properly fixed by r250852.

PR lto/81430
* config/nvptx/nvptx.c (nvptx_override_options_after_change):
Remove function.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Remove definition.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@251053 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|  7 +++
 gcc/config/nvptx/nvptx.c | 14 --
 2 files changed, 7 insertions(+), 14 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 2975655..295b4c9 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,10 @@
+2017-08-11  Thomas Schwinge  
+
+   PR lto/81430
+   * config/nvptx/nvptx.c (nvptx_override_options_after_change):
+   Remove function.
+   (TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Remove definition.
+
 2017-08-11  Tamar Christina  
* config/aarch64/aarch64.md (mov): Change.
(*movhf_aarch64, *movsf_aarch64, *movdf_aarch64):
diff --git gcc/config/nvptx/nvptx.c gcc/config/nvptx/nvptx.c
index ffd50d7..8babac7 100644
--- gcc/config/nvptx/nvptx.c
+++ gcc/config/nvptx/nvptx.c
@@ -212,17 +212,6 @@ nvptx_option_override (void)
 target_flags |= MASK_SOFT_STACK | MASK_UNIFORM_SIMT;
 }
 
-/* Implement TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE.  */
-
-static void
-nvptx_override_options_after_change (void)
-{
-  /* This is a workaround for PR81430 - nvptx acceleration compilation broken
- because of running pass_partition_blocks.  This should be dealt with in 
the
- common code, not in the target.  */
-  flag_reorder_blocks_and_partition = 0;
-}
-
 /* Return a ptx type for MODE.  If PROMOTE, then use .u32 for QImode to
deal with ptx ideosyncracies.  */
 
@@ -5527,9 +5516,6 @@ nvptx_data_alignment (const_tree type, unsigned int 
basic_align)
 #undef TARGET_OPTION_OVERRIDE
 #define TARGET_OPTION_OVERRIDE nvptx_option_override
 
-#undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
-#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE 
nvptx_override_options_after_change
-
 #undef TARGET_ATTRIBUTE_TABLE
 #define TARGET_ATTRIBUTE_TABLE nvptx_attribute_table
 


Grüße
 Thomas

Re: [PATCH 1/3] improve detection of attribute conflicts (PR 81544)

[Martin Sebor]

On 08/10/2017 03:55 PM, Joseph Myers wrote:

On Wed, 9 Aug 2017, Martin Sebor wrote:


The problem isn't that the declarations aren't merged at the call
site but rather that the middle-end gives const precedence over
pure so when both attributes are provided the former wins.


But that precedence is correct.  Any function with the semantics of const
also has the semantics of pure.  The problem is that the function doesn't
have the semantics of the attribute it's declared with.  And any
diagnostic based purely on the presence of both attributes would be
essentially a style diagnostic - for the style principle "if you have
multiple declarations of a function, they should have the same
information" - rather than "these attributes are inconsistent".


I didn't mean to imply that the precedence is incorrect.  But
whichever alternative it chosen is going to be "wrong" for
code written with an expectation of the opposite.  (Though
the consequences of choosing the more restrictive one when
the definition doesn't support it are obviously worse.)  So
because specifying the two attributes on two distinct
declarations raises the question of which one was meant it's
worth pointing it out to the user.  This is in line with how
some more benign attribute conflicts are already diagnosed
this way (e.g., hot and cold or always_inline and noinline).

But I don't want us to get too bogged down in a discussion
of these two or any other particular attributes at this point.
I'd like to get the infrastructure into a shape where these
choices can easily be made without changing the code or the
data structures, simply by adjusting bits in the attribute_spec
tables.  (There are plenty of other mutually exclusive attributes
that should be reviewed and perhaps adjusted.)


(An optional warning for different information in different declarations
is reasonable enough.  Actually in glibc it would be useful to have a
warning for a different but related case - two functions both declared,
later one defined as an alias of another, but the declarations don't have
the same attributes.  I'm pretty sure there are cases where the internal
declaration of __foo is missing attributes present on the public
declaration of foo.  But such a warning for aliases is only appropriate
for attributes that are properties of the function, not attributes that
are properties of particular names for it - __foo may well be a hidden
symbol where foo isn't.)


That does sound useful.  With the last pushed declaration now
available to the attribute handlers it should be fairly easy
to detect this problem in handle_alias_ifunc_attribute.  I'd
be happy to look into implementing it after I'm done with this
patch.  Can you please open a bug to request it?

Martin
remind

Re: [PATCH][testsuite] Add check_effective_target_autoincdec

[Rainer Orth]

Hi Wilco,

> Richard Earnshaw wrote:
>> Except that I think this would be better done as an 'effective target'
>> test; something like
>>
>> dg-require-effective-target autoincdec
>
> Right I figured out how to do this - not trivial as it needs a secret flag
> in the
> glob call - if anyone knows a better way of doing this I'd like to know!
>
>
> Add check_effective_target_autoincdec that returns true if a target
> runs the auto_inc_dec optimization pass.
>
> OK for commit?
>
> ChangeLog:
> 2017-08-08  Wilco Dijkstra  
>
> gcc/testsuite/
>
>   * gcc.dg/pr46932.c: Use effective_target autoincdec.
>   * lib/target-supports.exp: Add check_effective_target_autoincdec.
> --
>
> diff --git a/gcc/testsuite/gcc.dg/pr46932.c b/gcc/testsuite/gcc.dg/pr46932.c
> index 
> 4eb1a99e1bd9403f8b1c5d0d71ef731ad4a65128..2b39990d036035d22e226b98351a4900a5dbb309
>  100644
> --- a/gcc/testsuite/gcc.dg/pr46932.c
> +++ b/gcc/testsuite/gcc.dg/pr46932.c
> @@ -1,7 +1,5 @@
>  /* { dg-options "-O2 -fdump-rtl-auto_inc_dec" } */
> -
> -/* Build on targets which have pre increment.  */
> -/* { dg-do compile { target aarch64*-*-* arm*-*-* rs6000-*-* powerpc*-*-* 
> arc*-*-* m32r-*-* tic6x-*-* } } */
> +/* { dg-require-effective-target autoincdec } */
>  
>  /* Check that accesses based on the frame pointer do not
> use auto increment.  */
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 
> 5a6562794b2bdd5f370fc5b26d688f02779a..5219fbf4671e83a6fa7affdab926115e8a23f9cb
>  100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -8482,3 +8482,18 @@ proc check_effective_target_arm_coproc4_ok { } {
>  return [check_cached_effective_target arm_coproc4_ok \
>   check_effective_target_arm_coproc4_ok_nocache]
>  }
> +
> +# Return 1 if the target supports the auto_inc_dec optimization pass.
> +proc check_effective_target_autoincdec { } {
> +if { ![check_no_compiler_messages auto_incdec assembly { void f () { }
> +  } "-O2 -fdump-rtl-auto_inc_dec" ] } {
> +  return 0
> +}
> +
> +set dumpfile [glob -nocomplain 
> "auto_incdec[pid].c.\[0-9\]\[0-9\]\[0-9\]r.auto_inc_dec"]
> +if { [file exists $dumpfile ] } {
> + file delete $dumpfile
> + return 1
> +}
> +return 0
> +}

the new keyword needs documenting in sourcebuild.texi (often forgotten ;-)

Rainer

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

Re: [PATCH] Add macro DISABLE_COPY_AND_ASSIGN

[Pedro Alves]

On 08/02/2017 12:19 PM, Yao Qi wrote:
> On Wed, Jul 26, 2017 at 9:55 AM, Yao Qi  wrote:
>> On 17-07-19 10:30:45, Yao Qi wrote:
>>> We have many classes that copy cotr and assignment operator are deleted
>>> in different projects, gcc, gdb and gold.  So this patch adds a macro
>>> to do this, and replace these existing mechanical code with macro
>>> DISABLE_COPY_AND_ASSIGN.
>>>
>>> The patch was posted in gdb-patches,
>>> https://sourceware.org/ml/gdb-patches/2017-07/msg00254.html but we
>>> think it is better to put this macro in include/ansidecl.h so that
>>> other projects can use it too.
>>>
>>> Boostrapped on x86_64-linux-gnu.  Is it OK?
>>>
>>> include:
>>>
>>> 2017-07-19  Yao Qi  
>>>   Pedro Alves  
>>>
>>>   * ansidecl.h (DISABLE_COPY_AND_ASSIGN): New macro.
>>>
>>> gcc/cp:
>>>
>>> 2017-07-19  Yao Qi  
>>>
>>>   * cp-tree.h (class ovl_iterator): Use DISABLE_COPY_AND_ASSIGN.
>>>   * name-lookup.c (struct name_loopup): Likewise.
>>>
>>> gcc:
>>>
>>> 2017-07-19  Yao Qi  
>>>
>>>   * tree-ssa-scopedtables.h (class avail_exprs_stack): Use
>>>   DISABLE_COPY_AND_ASSIGN.
>>>   (class const_and_copies): Likewise.
>>
>> Ping.
>> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01134.html
>>
> 
> Ping.  It is a quite straightforward patch, can any one
> take a look?
> 

Yeah, this is a macro that lots of projects out there reinvent,
can't imagine it being very controversial.

I could have used this today in another spot in gdb.

The patch as is touches areas with different maintainers, it
may have fallen victim of diffusion of responsibility.

Could we get at least the ansidecl.h change in, so we can
start using it in gdb?  CCing Ian as a libiberty maintainer.

Thanks,
Pedro Alves

Re: [AArch64, PATCH] Improve Neon store of zero

[Richard Earnshaw (lists)]

On 10/08/17 14:12, Jackson Woodruff wrote:
> Hi all,
> 
> This patch changes patterns in aarch64-simd.md to replace
> 
> moviv0.4s, 0
> strq0, [x0, 16]
> 
> With:
> 
> stp xzr, xzr, [x0, 16]
> 
> When we are storing zeros to vectors like this:
> 
> void f(uint32x4_t *p) {
>   uint32x4_t x = { 0, 0, 0, 0};
>   p[1] = x;
> }
> 
> Bootstrapped and regtested on aarch64 with no regressions.
> OK for trunk?
> 
> Jackson
> 
> gcc/
> 
> 2017-08-09  Jackson Woodruff  
> 
> * aarch64-simd.md (mov): No longer force zero
> immediate into register.
> (*aarch64_simd_mov): Add new case for stp
> using zero immediate.
> 
> 
> gcc/testsuite
> 
> 2017-08-09  Jackson Woodruff  
> 
> * gcc.target/aarch64/simd/neon_str_zero.c: New.
> 
> 
> patchfile
> 
> 
> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> 74de9b8c89dd5e4e3d87504594c969de0e0128ce..0149a742d34ae4fd5b3fd705b03c845f94aa1d59
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -23,7 +23,10 @@
>   (match_operand:VALL_F16 1 "general_operand" ""))]
>"TARGET_SIMD"
>"
> -if (GET_CODE (operands[0]) == MEM)
> +if (GET_CODE (operands[0]) == MEM
> + && !(aarch64_simd_imm_zero (operands[1], mode)
> +  && aarch64_legitimate_address_p (mode, operands[0],
> +   PARALLEL, 1)))
>operands[1] = force_reg (mode, operands[1]);
>"
>  )
> @@ -94,63 +97,70 @@
>  
>  (define_insn "*aarch64_simd_mov"
>[(set (match_operand:VD 0 "nonimmediate_operand"
> - "=w, m,  w, ?r, ?w, ?r, w")
> + "=w, m,  m,  w, ?r, ?w, ?r, w")
>   (match_operand:VD 1 "general_operand"
> - "m,  w,  w,  w,  r,  r, Dn"))]
> + "m,  Dz, w,  w,  w,  r,  r, Dn"))]
>"TARGET_SIMD
> -   && (register_operand (operands[0], mode)
> -   || register_operand (operands[1], mode))"
> +   && ((register_operand (operands[0], mode)
> +   || register_operand (operands[1], mode))
> +  || (memory_operand (operands[0], mode)
> +   && immediate_operand (operands[1], mode)))"

Allowing any immediate here seems too lax - it allows any immediate
value which then could cause reload operations to be inserted (that in
turn might cause register pressure calculations to be incorrect).
Wouldn't it be better to use something like aarch64_simd_reg_or_zero?
Similarly below.

R.

>  {
> switch (which_alternative)
>   {
>   case 0: return "ldr\\t%d0, %1";
> - case 1: return "str\\t%d1, %0";
> - case 2: return "mov\t%0., %1.";
> - case 3: return "umov\t%0, %1.d[0]";
> - case 4: return "fmov\t%d0, %1";
> - case 5: return "mov\t%0, %1";
> - case 6:
> + case 1: return "str\\txzr, %0";
> + case 2: return "str\\t%d1, %0";
> + case 3: return "mov\t%0., %1.";
> + case 4: return "umov\t%0, %1.d[0]";
> + case 5: return "fmov\t%d0, %1";
> + case 6: return "mov\t%0, %1";
> + case 7:
>   return aarch64_output_simd_mov_immediate (operands[1],
> mode, 64);
>   default: gcc_unreachable ();
>   }
>  }
> -  [(set_attr "type" "neon_load1_1reg, neon_store1_1reg,\
> +  [(set_attr "type" "neon_load1_1reg, neon_stp, neon_store1_1reg,\
>neon_logic, neon_to_gp, f_mcr,\
>mov_reg, neon_move")]
>  )
>  
>  (define_insn "*aarch64_simd_mov"
>[(set (match_operand:VQ 0 "nonimmediate_operand"
> - "=w, m,  w, ?r, ?w, ?r, w")
> + "=w, Ump,  m,  w, ?r, ?w, ?r, w")
>   (match_operand:VQ 1 "general_operand"
> - "m,  w,  w,  w,  r,  r, Dn"))]
> + "m,  Dz, w,  w,  w,  r,  r, Dn"))]
>"TARGET_SIMD
> -   && (register_operand (operands[0], mode)
> -   || register_operand (operands[1], mode))"
> +   && ((register_operand (operands[0], mode)
> + || register_operand (operands[1], mode))
> +   || (memory_operand (operands[0], mode)
> +&& immediate_operand (operands[1], mode)))"
>  {
>switch (which_alternative)
>  {
>  case 0:
>   return "ldr\\t%q0, %1";
>  case 1:
> - return "str\\t%q1, %0";
> + return "stp\\txzr, xzr, %0";
>  case 2:
> - return "mov\t%0., %1.";
> + return "str\\t%q1, %0";
>  case 3:
> + return "mov\t%0., %1.";
>  case 4:
>  case 5:
> - return "#";
>  case 6:
> + return "#";
> +case 7:
>   return aarch64_output_simd_mov_immediate (operands[1], mode, 128);
>  default:
>   gcc_unreachable ();
>  }
>  }
>[(set_attr "type" "neon_load1_1reg, neon_store1_1reg,\
> - neon_logic, multiple, multiple, multiple,\
> - neon_move")
> -   (set_attr "length" "4,4,4,8,8,8,4")]
> +  neon_stp, neon_logic, multiple, multiple,\
> +  

Re: [PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func. inlining

[Pierre-Marie de Rodat]

On 08/07/2017 08:42 PM, Jason Merrill wrote:
Perhaps the DECL_ABSTRACT_ORIGIN check in my patch should be 
decl_ultimate_origin instead, which should return null in that case?


It looks like it worked, thanks! Note that I had to tweak a bit your 
change in process_scope_vars to avoid a crash in a couple of Fortran 
tests (at -O3 -g). Also, as the gcc_unreachable appears in an IF block, 
I turned it into a gcc_assert and remove the corresponding IF.


Here is the final patch version, bootstrapped and regtested on x86_64-linux.

--
Pierre-Marie de Rodat
>From 9272d97bfa77b073d57e99c231d271ec1bea2c26 Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat 
Date: Tue, 9 May 2017 12:24:36 +0200
Subject: [PATCH] [PR79542][Ada] Fix ICE in dwarf2out.c with nested func.
 inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79542 reports an ICE in
dwarf2out.c for an Ada testcase built with optimization.

This crash happens during the late generation pass because
add_gnat_descriptive_type cannot find the type DIE corresponding to some
descriptive type after having tried to generate it. This is because the
DIE was generated during the early generation pass, but then pruned by
the type pruning machinery. So why was it pruned?

We are in a situation where we have cloned types (because of inlining,
IIUC) whose TYPE_NAME have non-null DECL_ABSTRACT_ORIGIN attributes. As
a consequence:

  * In modified_type_die, the "handle C typedef types" part calls
gen_type_die on the cloned type.

  * gen_type_die matches a typedef variant, and then calls gen_decl_die
on its TYPE_NAME, which will end up calling gen_typedef_die.

  * gen_typedef_die checks decl_ultimate_origin for this TYPE_DECL, and
finds one, so it only adds a DW_AT_abstract_origin attribute to the
DW_TAG_typedef DIE, but the cloned type itself does not get its own
DIE.

  * Back in modified_type_die, the call to lookup_type_die on the type
passed to gen_type_die returns NULL.

In the end, whole type trees, i.e. the ones referenced by
DECL_ABSTRACT_ORIGIN attributes, are never referenced from type pruning
"roots" and are thus pruned. The descriptive type at stake here is one
of them, hence the assertion failure.

This patch attemps to fix that with what seems to be the most sensible
thing to do in my opinion: updating the "handle C typedef types" part in
modified_type_die to check decl_ultimate_origin before calling
gen_type_die: if that function returns something not null, then we know
that gen_type_die/gen_typedef_die will not generate a DIE for the input
type, so we try to process the ultimate origin instead. It also updates
in a similar way gen_type_die_with_usage, assert that when
gen_typedef_die is called on nodes that have an ultimate origin, this
origin is themselves.

gcc/
	PR ada/79542
	* dwarf2out.c (modified_type_die): For C typedef types that have
	an ultimate origin, process the ultimate origin instead of the
	input type.
	(gen_typedef_die): Assert that input DECLs have no ultimate
	origin.
	(gen_type_die_with_usage): For typedef variants that have an
	ultimate origin, just call gen_decl_die on the original DECL.
	(process_scope_var): Avoid creating DIEs for local typedefs and
	concrete static variables.

gcc/testsuite/

	* gnat.dg/debug13.ads, gnat.dg/debug13.adb: New testcase.
---
 gcc/dwarf2out.c   | 143 +++---
 gcc/testsuite/gnat.dg/debug13.adb |  38 ++
 gcc/testsuite/gnat.dg/debug13.ads |   5 ++
 3 files changed, 129 insertions(+), 57 deletions(-)
 create mode 100644 gcc/testsuite/gnat.dg/debug13.adb
 create mode 100644 gcc/testsuite/gnat.dg/debug13.ads

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 8e42227..917ab9f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -12506,6 +12506,15 @@ modified_type_die (tree type, int cv_quals, bool reverse,
 
   if (qualified_type == dtype)
 	{
+	  tree origin = decl_ultimate_origin (name);
+
+	  /* Typedef variants that have an abstract origin don't get their own
+	 type DIE (see gen_typedef_die), so fall back on the ultimate
+	 abstract origin instead.  */
+	  if (origin != NULL)
+	return modified_type_die (TREE_TYPE (origin), cv_quals, reverse,
+  context_die);
+
 	  /* For a named type, use the typedef.  */
 	  gen_type_die (qualified_type, context_die);
 	  return lookup_type_die (qualified_type);
@@ -24296,7 +24305,7 @@ static void
 gen_typedef_die (tree decl, dw_die_ref context_die)
 {
   dw_die_ref type_die;
-  tree origin;
+  tree type;
 
   if (TREE_ASM_WRITTEN (decl))
 {
@@ -24305,75 +24314,71 @@ gen_typedef_die (tree decl, dw_die_ref context_die)
   return;
 }
 
+  /* As we avoid creating DIEs for local typedefs (see decl_ultimate_origin
+ checks in process_scope_var and modified_type_die), this should be called
+ only for original types.  */
+  gcc_assert (decl_ultimate_origin (decl) == NULL);
+
   TREE_ASM_WRITTEN (decl) = 1;
   type_die = 

Re: [PATCH][GCC][AArch64] Fix pattern guard relaxations that are allowing more constants than they should.

[James Greenhalgh]

On Fri, Aug 11, 2017 at 12:01:40PM +0100, Tamar Christina wrote:
> Hi All, 
> 
> 
> Hi previous float immediate patches changed
> 
> aarch64_reg_or_fp_zero into aarch64_reg_or_fp_float
> for each of the movdf/sf/hf causing the RTL to contain
> stores to memory it would never be able to find a matching
> pattern for. Reload would then decide to store them to a
> register instead.
> 
> This didn't cause any incorrect code or failing tests but did change
> scheduling does producing more inefficient code.
> 
> The predicate is not reverted.
>
> Regression tested on aarch64-none-linux-gnu and no regressions.
> 
> OK for trunk?

OK.

Thanks,
James

> 
> Thanks,
> Tamar
> 
> 
> gcc/
> 2017-08-11  Tamar Christina  
>   * config/aarch64/aarch64.md (mov): Change.
>   (*movhf_aarch64, *movsf_aarch64, *movdf_aarch64):
>   aarch64_reg_or_fp_float into aarch64_reg_or_fp_zero.
>   * config/aarch64/predicates.md (aarch64_reg_or_fp_float): Removed.
> 
> -- 

Small tweak to tree-sra diagnostics

[Eric Botcazou]

In the case where build_access_from_expr_1 returns NULL because of a storage 
order barrier.  No functional changes.

Tested on x86_64-suse-linux, applied on the mainline as obvious.


2017-08-11  Eric Botcazou  

* tree-sra.c (build_access_from_expr_1): Use more precise diagnostics
for storage order barriers.

-- 
Eric BotcazouIndex: tree-sra.c
===
--- tree-sra.c	(revision 250983)
+++ tree-sra.c	(working copy)
@@ -1175,11 +1175,17 @@ build_access_from_expr_1 (tree expr, gimple *stmt,
   else
 partial_ref = false;
 
+  if (storage_order_barrier_p (expr))
+{
+  disqualify_base_of_expr (expr, "storage order barrier.");
+  return NULL;
+}
+
   /* We need to dive through V_C_Es in order to get the size of its parameter
  and not the result type.  Ada produces such statements.  We are also
  capable of handling the topmost V_C_E but not any of those buried in other
  handled components.  */
-  if (TREE_CODE (expr) == VIEW_CONVERT_EXPR && !storage_order_barrier_p (expr))
+  if (TREE_CODE (expr) == VIEW_CONVERT_EXPR)
 expr = TREE_OPERAND (expr, 0);
 
   if (contains_view_convert_expr_p (expr))

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

[Yvan Roux]

On 11 August 2017 at 13:50, Wilco Dijkstra  wrote:
> Kugan wrote:
>> Ping^2?
>
> Could you make sure to either include the patch or provide a link to it?
> (https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01967.html)
>
> I think the patch is fine since avoiding adrp/ldr on literals doesn't really
> help when global variables still use adrp. If you really want to avoid adrp
> and don't care about the overhead, there is -mcmodel=large...
>
> Note once you get the OK, we should consider backporting this with
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00386.html.

good point Wilco, I'll take care to add to the backport when it'll be accepted.

> Wilco

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

[Wilco Dijkstra]

Kugan wrote:
> Ping^2?

Could you make sure to either include the patch or provide a link to it?
(https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01967.html)

I think the patch is fine since avoiding adrp/ldr on literals doesn't really
help when global variables still use adrp. If you really want to avoid adrp
and don't care about the overhead, there is -mcmodel=large...

Note once you get the OK, we should consider backporting this with 
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00386.html.

Wilco

[PATCH][GCC][AArch64] Fix pattern guard relaxations that are allowing more constants than they should.

[Tamar Christina]

Hi All, 


Hi previous float immediate patches changed

aarch64_reg_or_fp_zero into aarch64_reg_or_fp_float
for each of the movdf/sf/hf causing the RTL to contain
stores to memory it would never be able to find a matching
pattern for. Reload would then decide to store them to a
register instead.

This didn't cause any incorrect code or failing tests but did change
scheduling does producing more inefficient code.

The predicate is not reverted.


Regression tested on aarch64-none-linux-gnu and no regressions.

OK for trunk?

Thanks,
Tamar


gcc/
2017-08-11  Tamar Christina  
* config/aarch64/aarch64.md (mov): Change.
(*movhf_aarch64, *movsf_aarch64, *movdf_aarch64):
aarch64_reg_or_fp_float into aarch64_reg_or_fp_zero.
* config/aarch64/predicates.md (aarch64_reg_or_fp_float): Removed.

-- 
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 7609fdba22627f15ed7630c371587b14b72e02ec..ba9c4479605fc6e001822a0f0e1df7d61ab58e0f 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1076,7 +1076,7 @@
   [(set (match_operand:HF 0 "nonimmediate_operand" "=w,w  ,?r,w,w  ,w  ,w,m,r,m ,r")
 	(match_operand:HF 1 "general_operand"  "Y ,?rY, w,w,Ufc,Uvi,m,w,m,rY,r"))]
   "TARGET_FLOAT && (register_operand (operands[0], HFmode)
-|| aarch64_reg_or_fp_float (operands[1], HFmode))"
+|| aarch64_reg_or_fp_zero (operands[1], HFmode))"
   "@
movi\\t%0.4h, #0
fmov\\t%h0, %w1
@@ -1099,7 +1099,7 @@
   [(set (match_operand:SF 0 "nonimmediate_operand" "=w,w  ,?r,w,w  ,w  ,w,m,r,m ,r,r")
 	(match_operand:SF 1 "general_operand"  "Y ,?rY, w,w,Ufc,Uvi,m,w,m,rY,r,M"))]
   "TARGET_FLOAT && (register_operand (operands[0], SFmode)
-|| aarch64_reg_or_fp_float (operands[1], SFmode))"
+|| aarch64_reg_or_fp_zero (operands[1], SFmode))"
   "@
movi\\t%0.2s, #0
fmov\\t%s0, %w1
@@ -1123,7 +1123,7 @@
   [(set (match_operand:DF 0 "nonimmediate_operand" "=w, w  ,?r,w,w  ,w  ,w,m,r,m ,r,r")
 	(match_operand:DF 1 "general_operand"  "Y , ?rY, w,w,Ufc,Uvi,m,w,m,rY,r,N"))]
   "TARGET_FLOAT && (register_operand (operands[0], DFmode)
-|| aarch64_reg_or_fp_float (operands[1], DFmode))"
+|| aarch64_reg_or_fp_zero (operands[1], DFmode))"
   "@
movi\\t%d0, #0
fmov\\t%d0, %x1
diff --git a/gcc/config/aarch64/predicates.md b/gcc/config/aarch64/predicates.md
index 95d28cfa33c6e06c47b6c666af6d8c2d6cef20f4..11243c4ce00aa7d16a886bb24b01180801c68f4e 100644
--- a/gcc/config/aarch64/predicates.md
+++ b/gcc/config/aarch64/predicates.md
@@ -57,11 +57,6 @@
(ior (match_operand 0 "register_operand")
 	(match_test "op == const0_rtx"
 
-(define_predicate "aarch64_reg_or_fp_float"
-  (ior (match_operand 0 "register_operand")
-	(and (match_code "const_double")
-	 (match_test "aarch64_float_const_rtx_p (op)"
-
 (define_predicate "aarch64_reg_or_fp_zero"
   (ior (match_operand 0 "register_operand")
 	(and (match_code "const_double")

[PATCH] skip patchable_function_entry tests on ia64

[Torsten Duwe]

As Andreas found out, patchable_function_entry tests generate false failures
on ia64. On a closer look, this feature needs some more thought on itanium:
I *could* imagine it is a good idea to generate N complete nop "bundles",
which would be properly aligned and allow for easy replacement with alternate
binary code.

But I'd rather leave this to the platform experts, or whoever comes up with
a good use case, to implement the proper cpu override hook. Meanwhile, as
long as the expected results remain undefined, disable the tests.

Torsten


gcc/testsuite/ChangeLog
2017-08-11  Torsten Duwe  

* c-c++-common/patchable_function_entry-default.c: Skip test on ia64.
* c-c++-common/patchable_function_entry-decl.c: Likewise.
* c-c++-common/patchable_function_entry-definition.c: Likewise.


diff --git a/gcc/testsuite/c-c++-common/patchable_function_entry-decl.c 
b/gcc/testsuite/c-c++-common/patchable_function_entry-decl.c
index 5c39a354559..e35dce4f3d8 100644
--- a/gcc/testsuite/c-c++-common/patchable_function_entry-decl.c
+++ b/gcc/testsuite/c-c++-common/patchable_function_entry-decl.c
@@ -1,4 +1,5 @@
 /* { dg-do compile { target { ! nvptx*-*-* } } } */
+/* { dg-skip-if "undefined padding" { "ia64*-*-*" } { "*" } { "" } } */
 /* { dg-options "-O2 -fpatchable-function-entry=3,1" } */
 /* { dg-final { scan-assembler-times "nop" 2 } } */
 
diff --git a/gcc/testsuite/c-c++-common/patchable_function_entry-default.c 
b/gcc/testsuite/c-c++-common/patchable_function_entry-default.c
index 48094f75f78..1b7e188d5f9 100644
--- a/gcc/testsuite/c-c++-common/patchable_function_entry-default.c
+++ b/gcc/testsuite/c-c++-common/patchable_function_entry-default.c
@@ -1,4 +1,5 @@
 /* { dg-do compile { target { ! nvptx*-*-* } } } */
+/* { dg-skip-if "undefined padding" { "ia64*-*-*" } { "*" } { "" } } */
 /* { dg-options "-O2 -fpatchable-function-entry=3,1" } */
 /* { dg-final { scan-assembler-times "nop" 3 } } */
 
diff --git a/gcc/testsuite/c-c++-common/patchable_function_entry-definition.c 
b/gcc/testsuite/c-c++-common/patchable_function_entry-definition.c
index af8202f283b..33e37dbc49f 100644
--- a/gcc/testsuite/c-c++-common/patchable_function_entry-definition.c
+++ b/gcc/testsuite/c-c++-common/patchable_function_entry-definition.c
@@ -1,4 +1,5 @@
 /* { dg-do compile { target { ! nvptx*-*-* } } } */
+/* { dg-skip-if "undefined padding" { "ia64*-*-*" } { "*" } { "" } } */
 /* { dg-options "-O2 -fpatchable-function-entry=3,1" } */
 /* { dg-final { scan-assembler-times "nop" 1 } } */
 

Re: [PATCH] Do not instrument void variables with MPX (PR tree-opt/79987).

[Martin Liška]

On 08/11/2017 01:51 AM, Ilya Enkovich wrote:
> 2017-08-10 10:40 GMT+03:00 Martin Liška :
>> Hello.
>>
>> In order to prevent the ICE, CHKP should not isntrument variables of void 
>> type.
> 
> Hi,
> 
> There was another thread for this PR where I proposed a way to handle such 
> vars
> via size relocations. But there was no feedback in that thread for two
> months and
> skipping void var is better than ICE. The patch is OK then.

Yep, probably does not worth doing that with relocations.
Thanks for review.

Martin

> 
> Thanks,
> Ilya
> 
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2017-08-09  Martin Liska  
>>
>> PR tree-opt/79987
>> * tree-chkp.c (chkp_get_bounds_for_decl_addr): Do not instrument
>> variables of void type.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2017-08-09  Martin Liska  
>>
>> PR tree-opt/79987
>> * gcc.target/i386/mpx/pr79987.c: New test.
>> ---
>>  gcc/testsuite/gcc.target/i386/mpx/pr79987.c | 5 +
>>  gcc/tree-chkp.c | 3 +++
>>  2 files changed, 8 insertions(+)
>>  create mode 100644 gcc/testsuite/gcc.target/i386/mpx/pr79987.c
>>
>>

[PATCH][GCC][AArch64] Restrict lrint inlining on ILP32.

[Tamar Christina]

Hi All,

The inlining of lrint isn't valid in all cases on ILP32 when
-fno-math-errno is used because an inexact exception is raised in
certain circumstances.

For ILP32 I now restrict the inlining only when -fno-trapping-math
is also specified.

This fixed PR/81800.

Regtested on aarch64-none-linux-gnu and no regressions.

Ok for trunk?

Thanks,
Tamar

gcc/
2017-08-11  Tamar Christina  

PR target/81800
* config/aarch64/aarch64.md (lrint2): Add 
flag_trapping_math.

gcc/testsuite/
2017-08-11  Tamar Christina  

* gcc.target/aarch64/inline-lrint_2.c (dg-options): Add 
-fno-trapping-math.

-- 
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index b1ef0252c4b0b93d368abbd9bb88cb740115a829..6617ea0b95f71fd91534f63de9ddfd2f400bb787 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -5122,7 +5122,7 @@
 (define_expand "lrint2"
   [(match_operand:GPI 0 "register_operand")
(match_operand:GPF 1 "register_operand")]
-  "TARGET_FLOAT"
+  "TARGET_FLOAT && (!TARGET_ILP32 || !flag_trapping_math)"
 {
   rtx cvt = gen_reg_rtx (mode);
   emit_insn (gen_rint2 (cvt, operands[1]));
diff --git a/gcc/testsuite/gcc.target/aarch64/inline-lrint_2.c b/gcc/testsuite/gcc.target/aarch64/inline-lrint_2.c
index 6080e186d8f0c6f5ede81c6438e059e8b976378f..bd0c73c8d34a2cb52d0a453a175bedd59bba5457 100644
--- a/gcc/testsuite/gcc.target/aarch64/inline-lrint_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/inline-lrint_2.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target ilp32 } */
-/* { dg-options "-O3 -fno-math-errno" } */
+/* { dg-options "-O3 -fno-math-errno -fno-trapping-math" } */
 
 #include "lrint-matherr.h"
 

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

[Kugan Vivekanandarajah]

Ping^2?

Thanks,
Kugan

On 21 July 2017 at 20:12, Kugan Vivekanandarajah
 wrote:
> Ping ?
>
> Thanks,
> Kugan
>
> On 27 June 2017 at 11:20, Kugan Vivekanandarajah
>  wrote:
>> https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00614.html  added this
>> workaround to get kernel building with when TARGET_FIX_ERR_A53_843419
>> is enabled.
>>
>> This was added to support building kernel loadable modules. In kernel,
>> when CONFIG_ARM64_ERRATUM_843419 is selected, the relocation needed
>> for ADRP/LDR (R_AARCH64_ADR_PREL_PG_HI21 and
>> R_AARCH64_ADR_PREL_PG_HI21_NC are removed from the kernel to avoid
>> loading objects with possibly offending sequence). Thus, it could only
>> support pc relative literal loads.
>>
>> However, the following patch was posted to kernel to add
>> -mpc-relative-literal-loads
>> http://www.spinics.net/lists/arm-kernel/msg476149.html
>>
>> -mpc-relative-literal-loads is unconditionally added to the kernel
>> build as can be seen from:
>> https://github.com/torvalds/linux/blob/master/arch/arm64/Makefile
>>
>> Therefore this patch removes the hunk so that applications like
>> SPECcpu2017's 521/621.wrf can be built (with LTO in this case) without
>> -mno-pc-relative-literal-loads
>>
>> Bootstrapped and regression tested on aarch64-linux-gnu with no new 
>> regressions.
>>
>> Is this OK for trunk?
>>
>> Thanks,
>> Kugan
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2017-06-27  Kugan Vivekanandarajah  
>>
>> * gcc.target/aarch64/pr63304_1.c: Remove-mno-fix-cortex-a53-843419.
>>
>> gcc/ChangeLog:
>>
>> 2017-06-27  Kugan Vivekanandarajah  
>>
>> * config/aarch64/aarch64.c (aarch64_override_options_after_change_1):
>> Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341
>> for default.