Re: [PATCH] rs6000: Use subreg for QI/HI vector init

[Kewen.Lin via Gcc-patches]

Hi Segher,

on 2020/12/15 下午10:40, Segher Boessenkool wrote:
> Hi Ke Wen,
> 
> On Tue, Dec 15, 2020 at 03:53:29PM +0800, Kewen.Lin wrote:
>> on 2020/12/15 上午2:51, Segher Boessenkool wrote:
>>> On Wed, Dec 02, 2020 at 05:44:24PM +0800, Kewen.Lin wrote:
 --- a/gcc/config/rs6000/rs6000.c
 +++ b/gcc/config/rs6000/rs6000.c
 @@ -6793,17 +6793,8 @@ rs6000_expand_vector_init (rtx target, rtx vals)
/* Force the values into word_mode registers.  */
for (i = 0; i < n_elts; i++)
{
 -rtx tmp = force_reg (GET_MODE_INNER (mode), XVECEXP (vals, 0, i));
 -if (TARGET_POWERPC64)
 -  {
 -op[i] = gen_reg_rtx (DImode);
 -emit_insn (gen_zero_extendqidi2 (op[i], tmp));
 -  }
 -else
 -  {
 -op[i] = gen_reg_rtx (SImode);
 -emit_insn (gen_zero_extendqisi2 (op[i], tmp));
 -  }
 +rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
 +op[i] = simplify_gen_subreg (Pmode, tmp, inner_mode, 0);
}
>>>
>>> Pmode is defined based on TARGET_64BIT, not TARGET_POWERPC64.
>>
>> Good point, you are right, is it ok to change this part with one
>> explicit mode based on TARGET_POWERPC64?
>>
>>   rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
>>   machine_mode tmode = TARGET_POWERPC64 ? DImode : SImode;
>>   op[i] = simplify_gen_subreg (tmode, tmp, inner_mode, 0);
> 
> That looks fine, yes.
> 
>>> But, can you not always use SImode here?
>>
>> Sorry that I didn't quite follow here.
> 
> I mean do
> 
>   rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
>   op[i] = simplify_gen_subreg (SImode, tmp, inner_mode, 0);
> 
> If that works (also in 64-bit mode), that is preferred.  It might need
> some more adjustment elsewhere, not sure if that is worth it.
> 

Thanks for the clarification!  Yes, as you said it doesn't work without
any adjustments, the gen_vsx_concat_v2di requires DImode operands, I
think it's not worthy to expand it just for this case.

> It is okay for trunk with either of those changes.  Thanks!
> 

Thanks!  Committed with the former way via r11-6109.

BR,
Kewen

Re: [PATCH] bswap: Handle vector CONSTRUCTORs [PR96239]

[Richard Biener]

On Tue, 15 Dec 2020, Jakub Jelinek wrote:


Hi!

The following patch teaches the bswap pass to handle for small (2/4/8 byte
long) vectors a CONSTRUCTOR by determining if the bytes of the constructor
come from non-vector sources and are either nop or bswap and changing the
CONSTRUCTOR in that case to VIEW_CONVERT_EXPR from scalar integer to
the vector type.

Unfortunately, as I found after the patch was written, due to pass ordering
this doesn't really fix the original testcase, just the one I wrote,
because both loop and slp vectorization is done only after the bswap pass.
A possible way out of that would be to perform just this particular bswap
optimization (i.e. for CONSTRUCTOR assignments with integral vector types
call find_bswap_or_nop and bswap_replace if successful) also during the
store merging pass, it isn't really a store, but the store merging pass
already performs bswapping when handling store, so it wouldn't be that big
hack.  What do you think?


I think it probably makes sense to have some helper split out that
collects & classifies vector constructor components we can use from
both forwprop (where matching the V_C_E from integer could be done
as well IMHO) and bswap (when a permute is involved) and store-merging.

Like with the bug missing integer promotion/demotion from memory
in forwprop we should be able to handle this in several places.

The helper would collect defs from the CTOR, and for loads classify
them so they have the same VUSE and are in the same BB and only then
does some ref analysis (using data-ref analysis is OK I think) and
see whether the defs are linear or permuted.  There should be a
corresponding second helper for emitting a combined load so we do
not have to redo that.

I guess this isn't really stage3 material though.


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


I guess this patch is still OK (tracking the bswap state in a generic
helper of course complicates things).

Richard.


2020-12-15  Jakub Jelinek  

PR tree-optimization/96239
* gimple-ssa-store-merging.c (find_bswap_or_nop): Handle a vector
CONSTRUCTOR.
(bswap_replace): Likewise.

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

--- gcc/gimple-ssa-store-merging.c.jj   2020-11-20 12:26:23.777860152 +0100
+++ gcc/gimple-ssa-store-merging.c  2020-12-14 19:10:30.887578930 +0100
@@ -865,7 +865,66 @@ find_bswap_or_nop (gimple *stmt, struct
  gimple *ins_stmt = find_bswap_or_nop_1 (stmt, n, limit);

  if (!ins_stmt)
-return NULL;
+{
+  if (gimple_assign_rhs_code (stmt) != CONSTRUCTOR
+ || BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN)
+   return NULL;
+  unsigned HOST_WIDE_INT sz = tree_to_uhwi (type_size) * BITS_PER_UNIT;
+  if (sz != 16 && sz != 32 && sz != 64)
+   return NULL;
+  tree rhs = gimple_assign_rhs1 (stmt);
+  tree eltype = TREE_TYPE (TREE_TYPE (rhs));
+  unsigned HOST_WIDE_INT eltsz
+   = int_size_in_bytes (eltype) * BITS_PER_UNIT;
+  if (TYPE_PRECISION (eltype) != eltsz)
+   return NULL;
+  constructor_elt *elt;
+  unsigned int i;
+  tree type = build_nonstandard_integer_type (sz, 1);
+  FOR_EACH_VEC_SAFE_ELT (CONSTRUCTOR_ELTS (rhs), i, elt)
+   {
+ if (TREE_CODE (elt->value) != SSA_NAME
+ || !INTEGRAL_TYPE_P (TREE_TYPE (elt->value)))
+   return NULL;
+ struct symbolic_number n1;
+ gimple *source_stmt
+   = find_bswap_or_nop_1 (SSA_NAME_DEF_STMT (elt->value), &n1,
+  limit - 1);
+
+ if (!source_stmt)
+   return NULL;
+
+ n1.type = type;
+ if (!n1.base_addr)
+   n1.range = sz / BITS_PER_UNIT;
+
+ if (i == 0)
+   {
+ ins_stmt = source_stmt;
+ *n = n1;
+   }
+ else
+   {
+ if (n->vuse != n1.vuse)
+   return NULL;
+
+ struct symbolic_number n0 = *n;
+
+ if (!BYTES_BIG_ENDIAN)
+   {
+ if (!do_shift_rotate (LSHIFT_EXPR, &n1, i * eltsz))
+   return NULL;
+   }
+ else if (!do_shift_rotate (LSHIFT_EXPR, &n0, eltsz))
+   return NULL;
+ ins_stmt
+   = perform_symbolic_merge (ins_stmt, &n0, source_stmt, &n1, n);
+
+ if (!ins_stmt)
+   return NULL;
+   }
+   }
+}

  uint64_t cmpxchg, cmpnop;
  find_bswap_or_nop_finalize (n, &cmpxchg, &cmpnop);
@@ -939,11 +998,18 @@ bswap_replace (gimple_stmt_iterator gsi,
{
  tree src, tmp, tgt = NULL_TREE;
  gimple *bswap_stmt;
+  tree_code conv_code = NOP_EXPR;

  gimple *cur_stmt = gsi_stmt (gsi);
  src = n->src;
  if (cur_stmt)
-tgt = gimple_assign_lhs (cur_stmt);
+{
+  tgt = gimple_assign_lhs (cur_stmt);
+  if (gimple_assign_rhs_code (cur_stmt) == CONSTRUCTOR
+ && tgt
+ && VECTOR_TYPE_P (TREE_TYPE (tgt)))
+   conv_code = VIEW_CONVERT_EXPR;
+  

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Martin Liška]

On 12/16/20 8:56 AM, Iain Sandoe via Gcc-patches wrote:

Rainer Orth  wrote:


Hi Pierre-Marie,


This fixes an issue when setting the baud rate. The baud rate is set
using the cfsetospeed and cfsetispeed system calls. The code is using
speed_t for clarity. The non-blocking status is only reset when Block is
True. And serial blocking mode is now properly set according to termios
manual.

Add documentation about a way to debug and test a serial port on
GNU/Linux without the need for a physical serial port.

Tested on x86_64-pc-linux-gnu, committed on trunk


this patch broke Linux/x86_64 bootstrap (Fedora 29):


also Darwin (which seems to be using g-sercom-linux.adb)


g-sercom.adb:307:53: "ICANON" is undefined
make[7]: *** [../gcc-interface/Makefile:299: g-sercom.o] Error 1

I suspect s-oscons-tmplt.c needs a change to define ICANON.

Rainer


Iain



I've just create PR for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98312

Martin

Re: Libcody breaks configure

[Kewen.Lin via Gcc-patches]

on 2020/12/16 下午2:35, Stott Graham via Gcc-patches wrote:
> If any ---checking options used
> 

The related PR PR98311[1] has been filed by David.

BR,
Kewen

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98311

[PATCH/RFC] combine: Tweak the condition of last_set invalidation

[Kewen.Lin via Gcc-patches]

Hi,

When I was investigating unsigned int vec_init issue on Power,
I happened to find there seems something we can enhance in how
combine pass invalidate last_set (set last_set_invalid nonzero).

Currently we have the check:

  if (!insn
  || (value && rsp->last_set_table_tick >= label_tick_ebb_start))
rsp->last_set_invalid = 1; 

which means if we want to record some value for some reg and
this reg got refered before in a valid scope, we invalidate the
set of reg (last_set_invalid to 1).  It avoids to find the wrong
set for one reg reference, such as the case like:

   ... op regX  // this regX could find wrong last_set below
   regX = ...   // if we think this set is valid
   ... op regX

But because of retry's existence, the last_set_table_tick could
be set by some later reference insns, but we see it's set due
to retry on the set (for that reg) insn again, such as:

   insn 1
   insn 2

   regX = ... --> (a)
   ... op regX--> (b)
   
   insn 3

   // assume all in the same BB.

Assuming we combine 1, 2 -> 3 sucessfully and replace them as two
(3 insns -> 2 insns), retrying from insn1 or insn2 again:
it will scan insn (a) again, the below condition holds for regX:

  (value && rsp->last_set_table_tick >= label_tick_ebb_start)

it will mark this set as invalid set.  But actually the
last_set_table_tick here is set by insn (b) before retrying, so it
should be safe to be taken as valid set.

This proposal is to check whether the last_set_table safely happens
after the current set, make the set still valid if so.

Bootstrapped/regtested on powerpc64le-linux-gnu (P9),
aarch64-linux-gnu and x86_64-pc-linux-gnu.

Full SPEC2017 building shows this patch gets more sucessful combines
from 1902208 to 1902243 (trivial though).

Any comments are highly appreciated!

BR,
Kewen
-

gcc/ChangeLog:

* combine.c (struct reg_stat_type): New member
last_set_table_luid.
(update_table_tick): Add one argument for insn luid and
set last_set_table_luid with it.
(record_value_for_reg): Adjust the condition to set
last_set_invalid nonzero.
diff --git a/gcc/combine.c b/gcc/combine.c
index 6fb2fa82c3f..2f45a0ad733 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -202,6 +202,10 @@ struct reg_stat_type {
 
   int  last_set_table_tick;
 
+  /* Record the luid of the insn whose expression involving register n.  */
+
+  int  last_set_table_luid;
+
   /* Record the value of label_tick when the value for register n is placed in
  last_set_value.  */
 
@@ -480,7 +484,7 @@ static rtx gen_lowpart_for_combine (machine_mode, rtx);
 static enum rtx_code simplify_compare_const (enum rtx_code, machine_mode,
 rtx, rtx *);
 static enum rtx_code simplify_comparison (enum rtx_code, rtx *, rtx *);
-static void update_table_tick (rtx);
+static void update_table_tick (rtx, int);
 static void record_value_for_reg (rtx, rtx_insn *, rtx);
 static void check_promoted_subreg (rtx_insn *, rtx);
 static void record_dead_and_set_regs_1 (rtx, const_rtx, void *);
@@ -13228,7 +13232,7 @@ count_rtxs (rtx x)
for each register mentioned.  Similar to mention_regs in cse.c  */
 
 static void
-update_table_tick (rtx x)
+update_table_tick (rtx x, int insn_luid)
 {
   enum rtx_code code = GET_CODE (x);
   const char *fmt = GET_RTX_FORMAT (code);
@@ -13243,7 +13247,21 @@ update_table_tick (rtx x)
   for (r = regno; r < endregno; r++)
{
  reg_stat_type *rsp = ®_stat[r];
- rsp->last_set_table_tick = label_tick;
+ if (rsp->last_set_table_tick >= label_tick_ebb_start)
+   {
+ /* Later references should not have lower ticks.  */
+ gcc_assert (label_tick >= rsp->last_set_table_tick);
+ /* Should pick up the lowest luid if the references
+are in the same block.  */
+ if (label_tick == rsp->last_set_table_tick
+ && rsp->last_set_table_luid > insn_luid)
+   rsp->last_set_table_luid = insn_luid;
+   }
+ else
+   {
+ rsp->last_set_table_tick = label_tick;
+ rsp->last_set_table_luid = insn_luid;
+   }
}
 
   return;
@@ -13279,16 +13297,17 @@ update_table_tick (rtx x)
if (ARITHMETIC_P (x0)
&& (x1 == XEXP (x0, 0) || x1 == XEXP (x0, 1)))
  {
-   update_table_tick (XEXP (x0, x1 == XEXP (x0, 0) ? 1 : 0));
+   update_table_tick (XEXP (x0, x1 == XEXP (x0, 0) ? 1 : 0),
+  insn_luid);
break;
  }
  }
 
-   update_table_tick (XEXP (x, i));
+   update_table_tick (XEXP (x, i), insn_luid);
   }
 else if (fmt[i] == 'E')
   for (j = 0; j < XVECLEN (x, i); j++)
-   update_table_tick (XVECEXP (x, i, j));
+   update_table_tick (XVECEXP (x, i, j), insn_luid);
 }
 
 /* R

Re: [PATCH]AArch64: Add NEON, SVE and SVE2 RTL patterns for Complex Addition, Multiply and FMA.

[Richard Sandiford via Gcc-patches]

Tamar Christina  writes:
> Hi Richard,
>
> Here's the split off complex add.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> Checked with armv8-a+sve2+fp16 and no issues.  Note that due to a mid-end
> limitation SLP for SVE currently fails for some permutes.  The tests have 
> these
> marked as XFAIL.
>
> Matching tests for these are in the mid-end patches.
>
> Ok for master?

OK, thanks.

Richard

[PATCH] Fix --enable-gather-detailed-mem-stats build.

[Martin Liška]

The build suffers from the static initialization order fiasco:

==30085== Invalid read of size 4
==30085==at 0x1D451CD: hash_table_mod1 (hash-table.h:344)
==30085==by 0x1D451CD: hash_table::mem_location_hash, 
vec_usage*, 
simple_hashmap_traits::mem_location_hash>, 
vec_usage*> >::hash_entry, false, xcallocator>::find_with_hash(mem_location* const&, unsigned int) 
(hash-table.h:911)
==30085==by 0x1D411F7: get (hash-map.h:185)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:417)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:451)
==30085==by 0x1D411F7: vec_prefix::register_overhead(void*, unsigned long, 
unsigned long, char const*, int, char const*) (vec.c:132)
==30085==by 0xA2DB28: reserve (vec.h:294)
==30085==by 0xA2DB28: vec::reserve(unsigned int, bool, char const*, int, char const*) [clone 
.isra.0] (vec.h:1778)
==30085==by 0x9039C7: reserve_exact (vec.h:1798)
==30085==by 0x9039C7: create (vec.h:1813)
==30085==by 0x9039C7: loc_spans (module.cc:3281)
==30085==by 0x9039C7: __static_initialization_and_destruction_0 
(module.cc:3340)
==30085==by 0x9039C7: _GLOBAL__sub_I_map_context_from (gt-cp-module.h:360)
==30085==by 0x1E00F6C: __libc_csu_init (elf-init.c:89)
==30085==by 0x4FFF0DD: (below main) (in /lib64/libc-2.32.so)
==30085==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

So vec_mem_desc is not initialized before a static member in module.cc.
That can be fixed by usage of GNU C++ extension init_priority.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

* vec.c: Use init_priority for vec_mem_desc.
---
 gcc/vec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/vec.c b/gcc/vec.c
index a28899170ed..1671f26c045 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -121,7 +121,8 @@ public:
 };
 
 /* Vector memory description.  */

-static mem_alloc_description  vec_mem_desc;
+static mem_alloc_description  vec_mem_desc
+  __attribute__ ((init_priority (101)));
 
 /* Account the overhead.  */
 
--

2.29.2

Re: [PATCH] Fix --enable-gather-detailed-mem-stats build.

[Iain Sandoe via Gcc-patches]

Martin Liška  wrote:


The build suffers from the static initialization order fiasco:

==30085== Invalid read of size 4
==30085==at 0x1D451CD: hash_table_mod1 (hash-table.h:344)
==30085==by 0x1D451CD:  
hash_table::mem_location_hash,  
vec_usage*,  
simple_hashmap_traits::mem_location_hash>,  
vec_usage*> >::hash_entry, false,  
xcallocator>::find_with_hash(mem_location* const&, unsigned int)  
(hash-table.h:911)

==30085==by 0x1D411F7: get (hash-map.h:185)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:417)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:451)
==30085==by 0x1D411F7: vec_prefix::register_overhead(void*, unsigned  
long, unsigned long, char const*, int, char const*) (vec.c:132)

==30085==by 0xA2DB28: reserve (vec.h:294)
==30085==by 0xA2DB28: vecvl_ptr>::reserve(unsigned int, bool, char const*, int, char const*)  
[clone .isra.0] (vec.h:1778)

==30085==by 0x9039C7: reserve_exact (vec.h:1798)
==30085==by 0x9039C7: create (vec.h:1813)
==30085==by 0x9039C7: loc_spans (module.cc:3281)
==30085==by 0x9039C7: __static_initialization_and_destruction_0  
(module.cc:3340)
==30085==by 0x9039C7: _GLOBAL__sub_I_map_context_from  
(gt-cp-module.h:360)

==30085==by 0x1E00F6C: __libc_csu_init (elf-init.c:89)
==30085==by 0x4FFF0DD: (below main) (in /lib64/libc-2.32.so)
==30085==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

So vec_mem_desc is not initialized before a static member in module.cc.
That can be fixed by usage of GNU C++ extension init_priority.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

* vec.c: Use init_priority for vec_mem_desc.
---
gcc/vec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/vec.c b/gcc/vec.c
index a28899170ed..1671f26c045 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -121,7 +121,8 @@ public:
};
 /* Vector memory description.  */
-static mem_alloc_description  vec_mem_desc;
+static mem_alloc_description  vec_mem_desc
+  __attribute__ ((init_priority (101)));


This will break bootstrap on targets without init_priority (e.g. Darwin)

Iain

Re: [PATCH] Fix --enable-gather-detailed-mem-stats build.

[Martin Liška]

On 12/16/20 10:08 AM, Iain Sandoe wrote:

This will break bootstrap on targets without init_priority (e.g. Darwin)


All right, based on the chat on IRC, I suggest using C static constructor
with corresponding priority.

Ready to be installed?
Thanks,
Martin
>From 4ecf4f8df8d5b6b75cfe7cc5df90176e0a5014b8 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 16 Dec 2020 10:02:10 +0100
Subject: [PATCH] Fix --enable-gather-detailed-mem-stats build.

The build suffers from the static initialization order fiasco:

==30085== Invalid read of size 4
==30085==at 0x1D451CD: hash_table_mod1 (hash-table.h:344)
==30085==by 0x1D451CD: hash_table::mem_location_hash, vec_usage*, simple_hashmap_traits::mem_location_hash>, vec_usage*> >::hash_entry, false, xcallocator>::find_with_hash(mem_location* const&, unsigned int) (hash-table.h:911)
==30085==by 0x1D411F7: get (hash-map.h:185)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:417)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:451)
==30085==by 0x1D411F7: vec_prefix::register_overhead(void*, unsigned long, unsigned long, char const*, int, char const*) (vec.c:132)
==30085==by 0xA2DB28: reserve (vec.h:294)
==30085==by 0xA2DB28: vec::reserve(unsigned int, bool, char const*, int, char const*) [clone .isra.0] (vec.h:1778)
==30085==by 0x9039C7: reserve_exact (vec.h:1798)
==30085==by 0x9039C7: create (vec.h:1813)
==30085==by 0x9039C7: loc_spans (module.cc:3281)
==30085==by 0x9039C7: __static_initialization_and_destruction_0 (module.cc:3340)
==30085==by 0x9039C7: _GLOBAL__sub_I_map_context_from (gt-cp-module.h:360)
==30085==by 0x1E00F6C: __libc_csu_init (elf-init.c:89)
==30085==by 0x4FFF0DD: (below main) (in /lib64/libc-2.32.so)
==30085==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

So vec_mem_desc is not initialized before a static member in module.cc.
We can fix it by using constructor attribute.

gcc/ChangeLog:

	* vec.c (init_vec_mem_desc): New function.
	(vec_prefix::register_overhead): Use vec_mem_desc as pointer
	now.
	(vec_prefix::release_overhead): Likewise.
	(dump_vec_loc_statistics): Likewise.
---
 gcc/vec.c | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/gcc/vec.c b/gcc/vec.c
index a28899170ed..ac91400c2df 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -121,7 +121,17 @@ public:
 };
 
 /* Vector memory description.  */
-static mem_alloc_description  vec_mem_desc;
+static mem_alloc_description  *vec_mem_desc;
+
+/* Static constructor for vec_mem_desc that happens before ithe initialization
+   of all static variables.  */
+
+static void
+__attribute__((constructor (101)))
+init_vec_mem_desc (void)
+{
+  vec_mem_desc = new mem_alloc_description ();
+}
 
 /* Account the overhead.  */
 
@@ -129,10 +139,10 @@ void
 vec_prefix::register_overhead (void *ptr, size_t elements,
 			   size_t element_size MEM_STAT_DECL)
 {
-  vec_mem_desc.register_descriptor (ptr, VEC_ORIGIN, false
-FINAL_PASS_MEM_STAT);
+  vec_mem_desc->register_descriptor (ptr, VEC_ORIGIN, false
+ FINAL_PASS_MEM_STAT);
   vec_usage *usage
-= vec_mem_desc.register_instance_overhead (elements * element_size, ptr);
+= vec_mem_desc->register_instance_overhead (elements * element_size, ptr);
   usage->m_element_size = element_size;
   usage->m_items += elements;
   if (usage->m_items_peak < usage->m_items)
@@ -145,11 +155,11 @@ void
 vec_prefix::release_overhead (void *ptr, size_t size, size_t elements,
 			  bool in_dtor MEM_STAT_DECL)
 {
-  if (!vec_mem_desc.contains_descriptor_for_instance (ptr))
-vec_mem_desc.register_descriptor (ptr, VEC_ORIGIN,
+  if (!vec_mem_desc->contains_descriptor_for_instance (ptr))
+vec_mem_desc->register_descriptor (ptr, VEC_ORIGIN,
   false FINAL_PASS_MEM_STAT);
-  vec_usage *usage = vec_mem_desc.release_instance_overhead (ptr, size,
-			 in_dtor);
+  vec_usage *usage = vec_mem_desc->release_instance_overhead (ptr, size,
+			  in_dtor);
   usage->m_items -= elements;
 }
 
@@ -183,7 +193,7 @@ vec_prefix::calculate_allocation_1 (unsigned alloc, unsigned desired)
 void
 dump_vec_loc_statistics (void)
 {
-  vec_mem_desc.dump (VEC_ORIGIN);
+  vec_mem_desc->dump (VEC_ORIGIN);
 }
 
 #if CHECKING_P
-- 
2.29.2

Re: [PATCH] Add -Wtsan.

[Martin Liška]

On 12/16/20 1:19 AM, Jeff Law wrote:

OK.   Please consider a more through description in invoke.texi
though.   What unsupported feature are we warning about and what are the
consequences of not supporting that feature.


Done that and installed the patch.

Thank you for the review,
Martin

Re: [PATCH] Fix --enable-gather-detailed-mem-stats build.

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 10:20:09AM +0100, Martin Liška wrote:
> So vec_mem_desc is not initialized before a static member in module.cc.
> We can fix it by using constructor attribute.
> 
> gcc/ChangeLog:
> 
>   * vec.c (init_vec_mem_desc): New function.
>   (vec_prefix::register_overhead): Use vec_mem_desc as pointer
>   now.
>   (vec_prefix::release_overhead): Likewise.
>   (dump_vec_loc_statistics): Likewise.
> ---
>  gcc/vec.c | 28 +++-
>  1 file changed, 19 insertions(+), 9 deletions(-)
> 
> diff --git a/gcc/vec.c b/gcc/vec.c
> index a28899170ed..ac91400c2df 100644
> --- a/gcc/vec.c
> +++ b/gcc/vec.c
> @@ -121,7 +121,17 @@ public:
>  };
>  
>  /* Vector memory description.  */
> -static mem_alloc_description  vec_mem_desc;
> +static mem_alloc_description  *vec_mem_desc;
> +
> +/* Static constructor for vec_mem_desc that happens before ithe 
> initialization

s/ithe/the/

> +   of all static variables.  */
> +
> +static void
> +__attribute__((constructor (101)))

I think this needs to be guarded based on which compiler is used to compile
GCC.  Perhaps we could say that we don't support
--enable-gather-detailed-mem-stats when the compiler isn't built by GCC (or
other compiler that supports the constructor attribute) and #error on that.

> +init_vec_mem_desc (void)
> +{
> +  vec_mem_desc = new mem_alloc_description ();
> +}
>  
>  /* Account the overhead.  */
>  
> @@ -129,10 +139,10 @@ void
>  vec_prefix::register_overhead (void *ptr, size_t elements,
>  size_t element_size MEM_STAT_DECL)
>  {
> -  vec_mem_desc.register_descriptor (ptr, VEC_ORIGIN, false
> - FINAL_PASS_MEM_STAT);
> +  vec_mem_desc->register_descriptor (ptr, VEC_ORIGIN, false
> +  FINAL_PASS_MEM_STAT);
>vec_usage *usage
> -= vec_mem_desc.register_instance_overhead (elements * element_size, ptr);
> += vec_mem_desc->register_instance_overhead (elements * element_size, 
> ptr);
>usage->m_element_size = element_size;
>usage->m_items += elements;
>if (usage->m_items_peak < usage->m_items)
> @@ -145,11 +155,11 @@ void
>  vec_prefix::release_overhead (void *ptr, size_t size, size_t elements,
> bool in_dtor MEM_STAT_DECL)
>  {
> -  if (!vec_mem_desc.contains_descriptor_for_instance (ptr))
> -vec_mem_desc.register_descriptor (ptr, VEC_ORIGIN,
> +  if (!vec_mem_desc->contains_descriptor_for_instance (ptr))
> +vec_mem_desc->register_descriptor (ptr, VEC_ORIGIN,
> false FINAL_PASS_MEM_STAT);
> -  vec_usage *usage = vec_mem_desc.release_instance_overhead (ptr, size,
> -  in_dtor);
> +  vec_usage *usage = vec_mem_desc->release_instance_overhead (ptr, size,
> +   in_dtor);
>usage->m_items -= elements;
>  }
>  
> @@ -183,7 +193,7 @@ vec_prefix::calculate_allocation_1 (unsigned alloc, 
> unsigned desired)
>  void
>  dump_vec_loc_statistics (void)
>  {
> -  vec_mem_desc.dump (VEC_ORIGIN);
> +  vec_mem_desc->dump (VEC_ORIGIN);
>  }
>  
>  #if CHECKING_P

Jakub

Re: [PATCH] Fix --enable-gather-detailed-mem-stats build.

[Martin Liška]

On 12/16/20 10:26 AM, Jakub Jelinek wrote:

I think this needs to be guarded based on which compiler is used to compile
GCC.


Do you mean basing that on __GNUC__?


 Perhaps we could say that we don't support
--enable-gather-detailed-mem-stats when the compiler isn't built by GCC (or
other compiler that supports the constructor attribute) and #error on that.


Yes, it's a reasonable requirement I would say.

Martin

Re: [PATCH] Fix --enable-gather-detailed-mem-stats build.

[Rainer Orth]

Hi Jakub,

> On Wed, Dec 16, 2020 at 10:20:09AM +0100, Martin Liška wrote:
>> So vec_mem_desc is not initialized before a static member in module.cc.
>> We can fix it by using constructor attribute.
[...]
>> +   of all static variables.  */
>> +
>> +static void
>> +__attribute__((constructor (101)))
>
> I think this needs to be guarded based on which compiler is used to compile
> GCC.  Perhaps we could say that we don't support
> --enable-gather-detailed-mem-stats when the compiler isn't built by GCC (or
> other compiler that supports the constructor attribute) and #error on that.

not only that: if a target doesn't support constructor priorities (like
Solaris 11.3, unlike 11.4), this makes gcc error out.

Rainer

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

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Rainer Orth]

Hi Iain,

> Rainer Orth  wrote:
>
>> Hi Pierre-Marie,
>>
>>> This fixes an issue when setting the baud rate. The baud rate is set
>>> using the cfsetospeed and cfsetispeed system calls. The code is using
>>> speed_t for clarity. The non-blocking status is only reset when Block is
>>> True. And serial blocking mode is now properly set according to termios
>>> manual.
>>>
>>> Add documentation about a way to debug and test a serial port on
>>> GNU/Linux without the need for a physical serial port.
>>>
>>> Tested on x86_64-pc-linux-gnu, committed on trunk
>>
>> this patch broke Linux/x86_64 bootstrap (Fedora 29):
>
> also Darwin (which seems to be using g-sercom-linux.adb)

ah.  In hindsight, I'd wondered why my Solaris builds weren't affected.
termios is common to all POSIX targets after all.

Rainer

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

Re: [PATCH] Fix --enable-gather-detailed-mem-stats build.

[Martin Liška]

On 12/16/20 10:38 AM, Rainer Orth wrote:

Hi Jakub,


On Wed, Dec 16, 2020 at 10:20:09AM +0100, Martin Liška wrote:

So vec_mem_desc is not initialized before a static member in module.cc.
We can fix it by using constructor attribute.

[...]

+   of all static variables.  */
+
+static void
+__attribute__((constructor (101)))


I think this needs to be guarded based on which compiler is used to compile
GCC.  Perhaps we could say that we don't support
--enable-gather-detailed-mem-stats when the compiler isn't built by GCC (or
other compiler that supports the constructor attribute) and #error on that.


not only that: if a target doesn't support constructor priorities (like
Solaris 11.3, unlike 11.4), this makes gcc error out.

Rainer



I see, I'm then suggesting version 3 of the patch that does not depend
on a constructor.

Thoughts?
Thanks,
Martin

Martin
>From 3ac0d258887426b30d3e1885841b1bdf4e53100b Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Wed, 16 Dec 2020 10:02:10 +0100
Subject: [PATCH] Fix --enable-gather-detailed-mem-stats build.

The build suffers from the static initialization order fiasco:

==30085== Invalid read of size 4
==30085==at 0x1D451CD: hash_table_mod1 (hash-table.h:344)
==30085==by 0x1D451CD: hash_table::mem_location_hash, vec_usage*, simple_hashmap_traits::mem_location_hash>, vec_usage*> >::hash_entry, false, xcallocator>::find_with_hash(mem_location* const&, unsigned int) (hash-table.h:911)
==30085==by 0x1D411F7: get (hash-map.h:185)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:417)
==30085==by 0x1D411F7: register_descriptor (mem-stats.h:451)
==30085==by 0x1D411F7: vec_prefix::register_overhead(void*, unsigned long, unsigned long, char const*, int, char const*) (vec.c:132)
==30085==by 0xA2DB28: reserve (vec.h:294)
==30085==by 0xA2DB28: vec::reserve(unsigned int, bool, char const*, int, char const*) [clone .isra.0] (vec.h:1778)
==30085==by 0x9039C7: reserve_exact (vec.h:1798)
==30085==by 0x9039C7: create (vec.h:1813)
==30085==by 0x9039C7: loc_spans (module.cc:3281)
==30085==by 0x9039C7: __static_initialization_and_destruction_0 (module.cc:3340)
==30085==by 0x9039C7: _GLOBAL__sub_I_map_context_from (gt-cp-module.h:360)
==30085==by 0x1E00F6C: __libc_csu_init (elf-init.c:89)
==30085==by 0x4FFF0DD: (below main) (in /lib64/libc-2.32.so)
==30085==  Address 0x28 is not stack'd, malloc'd or (recently) free'd

So vec_mem_desc is not initialized before a static member in module.cc.

gcc/ChangeLog:

	* vec.c (vec_prefix::register_overhead): Initialize vec_mem_desc
	if it is NULL.
	(vec_prefix::release_overhead): Use pointer type for
	vec_mem_desc.
	(dump_vec_loc_statistics): Likewise.
---
 gcc/vec.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/gcc/vec.c b/gcc/vec.c
index a28899170ed..7df0f54605e 100644
--- a/gcc/vec.c
+++ b/gcc/vec.c
@@ -121,7 +121,7 @@ public:
 };
 
 /* Vector memory description.  */
-static mem_alloc_description  vec_mem_desc;
+static mem_alloc_description  *vec_mem_desc = NULL;
 
 /* Account the overhead.  */
 
@@ -129,10 +129,13 @@ void
 vec_prefix::register_overhead (void *ptr, size_t elements,
 			   size_t element_size MEM_STAT_DECL)
 {
-  vec_mem_desc.register_descriptor (ptr, VEC_ORIGIN, false
-FINAL_PASS_MEM_STAT);
+  if (vec_mem_desc == NULL)
+vec_mem_desc = new mem_alloc_description ();
+
+  vec_mem_desc->register_descriptor (ptr, VEC_ORIGIN, false
+ FINAL_PASS_MEM_STAT);
   vec_usage *usage
-= vec_mem_desc.register_instance_overhead (elements * element_size, ptr);
+= vec_mem_desc->register_instance_overhead (elements * element_size, ptr);
   usage->m_element_size = element_size;
   usage->m_items += elements;
   if (usage->m_items_peak < usage->m_items)
@@ -145,11 +148,11 @@ void
 vec_prefix::release_overhead (void *ptr, size_t size, size_t elements,
 			  bool in_dtor MEM_STAT_DECL)
 {
-  if (!vec_mem_desc.contains_descriptor_for_instance (ptr))
-vec_mem_desc.register_descriptor (ptr, VEC_ORIGIN,
+  if (!vec_mem_desc->contains_descriptor_for_instance (ptr))
+vec_mem_desc->register_descriptor (ptr, VEC_ORIGIN,
   false FINAL_PASS_MEM_STAT);
-  vec_usage *usage = vec_mem_desc.release_instance_overhead (ptr, size,
-			 in_dtor);
+  vec_usage *usage = vec_mem_desc->release_instance_overhead (ptr, size,
+			  in_dtor);
   usage->m_items -= elements;
 }
 
@@ -183,7 +186,7 @@ vec_prefix::calculate_allocation_1 (unsigned alloc, unsigned desired)
 void
 dump_vec_loc_statistics (void)
 {
-  vec_mem_desc.dump (VEC_ORIGIN);
+  vec_mem_desc->dump (VEC_ORIGIN);
 }
 
 #if CHECKING_P
-- 
2.29.2

Re: libcody: Fix for dash

[Richard Sandiford via Gcc-patches]

Nathan Sidwell  writes:
> Apparently 'var+=...' is not a dash thing.  Fixed thusly.
>
>   * config.m4: Avoid non-dash idiom
>  * configure: Rebuilt.
>
> pushed (2 patches, because I didn't look carefully enough the first time)

Thanks.  I think the other uses of += need the same treatment though:

  CXX+=" -I$tools/include"
toollib+="/${os}"
CXX+=" -std=c++11"
[CXX+=" -std=c++20"
AC_SEARCH_LIBS([bfd_openr],[bfd],[LIBS+="-lz -liberty -ldl"],,[-lz -liberty 
-ldl])
  CONFIG_FILES+=" $dir/Makesub"
  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES+=" $dir/tests/Makesub"
Richard

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Iain Sandoe via Gcc-patches]

Rainer Orth  wrote:



Rainer Orth  wrote:


Hi Pierre-Marie,


This fixes an issue when setting the baud rate. The baud rate is set
using the cfsetospeed and cfsetispeed system calls. The code is using
speed_t for clarity. The non-blocking status is only reset when Block is
True. And serial blocking mode is now properly set according to termios
manual.

Add documentation about a way to debug and test a serial port on
GNU/Linux without the need for a physical serial port.

Tested on x86_64-pc-linux-gnu, committed on trunk


this patch broke Linux/x86_64 bootstrap (Fedora 29):


also Darwin (which seems to be using g-sercom-linux.adb)


ah.  In hindsight, I'd wondered why my Solaris builds weren't affected.
termios is common to all POSIX targets after all.


Actually, the linux file seems to contain quite a bit more advanced than  
SUSv3,

it might be worth having a Posix_susv3 version (there are quite a few targets
qualified to SUSv3, but it seems not many [1?] qualified to UNIX7).

Iain

Re: [PATCH] rs6000: Use subreg for QI/HI vector init

[Segher Boessenkool]

On Wed, Dec 16, 2020 at 04:19:12PM +0800, Kewen.Lin wrote:
> on 2020/12/15 下午10:40, Segher Boessenkool wrote:
> > I mean do
> > 
> >   rtx tmp = force_reg (inner_mode, XVECEXP (vals, 0, i));
> >   op[i] = simplify_gen_subreg (SImode, tmp, inner_mode, 0);
> > 
> > If that works (also in 64-bit mode), that is preferred.  It might need
> > some more adjustment elsewhere, not sure if that is worth it.
> > 
> 
> Thanks for the clarification!  Yes, as you said it doesn't work without
> any adjustments, the gen_vsx_concat_v2di requires DImode operands, I
> think it's not worthy to expand it just for this case.

Yeah good call.  Thanks!


Segher

Re: [PATCH] [X86] Fold more shuffle builtins to VEC_PERM_EXPR.

[Hongtao Liu via Gcc-patches]

On Tue, Dec 15, 2020 at 7:11 PM Jakub Jelinek  wrote:
>
> On Tue, Dec 15, 2020 at 06:10:57PM +0800, Hongtao Liu via Gcc-patches wrote:
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -18187,21 +18187,67 @@ ix86_gimple_fold_builtin (gimple_stmt_iterator 
> > *gsi)
> >   }
> >break;
> >
> > +case IX86_BUILTIN_SHUFPD512:
> > +case IX86_BUILTIN_SHUFPS512:
> > +  if (n_args > 2)
> > + {
> > +   /* This is masked shuffle.  Only optimize if the mask is all ones.  
> > */
> > +   tree argl = gimple_call_arg (stmt, n_args - 1);
> > +   arg0 = gimple_call_arg (stmt, 0);
> > +   if (!tree_fits_uhwi_p (argl))
> > + break;
> > +   unsigned HOST_WIDE_INT mask = tree_to_uhwi (argl);
> > +   unsigned elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
>
> I think it would be better not to mix the argl and arg0 stuff.
> So e.g. do
>   arg0 = gimple_call_arg (stmt, 0);
>   unsigned elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
> first and then the argl stuff, or vice versa.
> Furthermore, you don't really care about the upper bits of argl,
> so why don't punt just if (TREE_CODE (argl) != INTEGER_CST)
> and use mask = TREE_LOW_CST (argl);
> ?
>

Yes, and for maintenance convenience, i put these code into a new
function which can be also called by masked shift
@@ -18128,17 +18142,10 @@ ix86_gimple_fold_builtin (gimple_stmt_iterator *gsi)
   gcc_assert (n_args >= 2);
   arg0 = gimple_call_arg (stmt, 0);
   arg1 = gimple_call_arg (stmt, 1);
-  if (n_args > 2)
- {
-   /* This is masked shift.  Only optimize if the mask is all ones.  */
-   tree argl = gimple_call_arg (stmt, n_args - 1);
-   if (!tree_fits_uhwi_p (argl))
- break;
-   unsigned HOST_WIDE_INT mask = tree_to_uhwi (argl);
-   unsigned elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
-   if ((mask | (HOST_WIDE_INT_M1U << elems)) != HOST_WIDE_INT_M1U)
- break;
- }
+  /* For masked shift, only optimize if the mask is all ones.  */
+  if (n_args > 2
+   && !ix86_masked_all_ones (arg0, gimple_call_arg (stmt, n_args - 1)))
+ break;


> > +   if ((mask | (HOST_WIDE_INT_M1U << elems)) != HOST_WIDE_INT_M1U)
> > + break;
> > + }
> > +  /* Fall thru.  */
> >  case IX86_BUILTIN_SHUFPD:
> > +case IX86_BUILTIN_SHUFPD256:
> > +case IX86_BUILTIN_SHUFPS:
> > +case IX86_BUILTIN_SHUFPS256:
> >arg2 = gimple_call_arg (stmt, 2);
> >if (TREE_CODE (arg2) == INTEGER_CST)
> >   {
> > -   location_t loc = gimple_location (stmt);
> > -   unsigned HOST_WIDE_INT imask = TREE_INT_CST_LOW (arg2);
> > arg0 = gimple_call_arg (stmt, 0);
> > +   unsigned elems = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
> > +   machine_mode imode = GET_MODE_INNER (TYPE_MODE (TREE_TYPE (arg0)));
> > +   unsigned HOST_WIDE_INT imask = TREE_INT_CST_LOW (arg2);
> > +
> > +   /* Check valid imm, refer to gcc.target/i386/testimm-10.c.  */
> > +   if (imask > 255
> > +   || (imask >= HOST_WIDE_INT_1U << elems
> > +   && imode == E_DFmode))
> > + return false;
>
> Why is this extra checking done only for DFmode and not for SFmode?
Oh, yes, delete extra checking, the instruction would ignore high bits
for 128/256-bit DFmode version.
>
> > +   tree itype = imode == E_DFmode
> > + ? long_long_integer_type_node : integer_type_node;
>
> Formatting.  Should be e.g.
>   tree itype
> = (imode == E_DFmode
>? long_long_integer_type_node : integer_type_node);
> or
>   tree itype = (imode == E_DFmode ? long_long_integer_type_node
>   : integer_type_node);
> but the ? which is part of the imode == E_DFmode ... subexpression
> can't just be below something unrelated.
>
Changed.
> > +   if (imode == E_DFmode)
> > + sel_idx = (i & 1) * elems
> > +   + (i >> 1 << 1) + ((imask & 1 << i) >> i);
>
> Again, formatting.  Plus, i >> 1 << 1 looks too ugly/unreadable,
> if you mean i & ~1, write it like that, it is up to the compiler to emit
> it like i >> 1 << 1 if that is the best implementation.
>
Changed.
> > +   else
> > + {
> > +   /* Imm[7:0](if VL > 128, also use Imm[7:0]) provide 4 select
> > +  controls for each element of the destination.  */
> > +   unsigned j = i % 4;
> > +   sel_idx = ((i & 2) >> 1) * elems
> > + + (i >> 2 << 2) + ((imask & 3 << j << j) >> j >> j);
>
> Ditto.
>
Changed.
> Jakub
>

Update patch

--
BR,
Hongtao
From 1cfec402ffa25375c88fa38e783d203401f38c5e Mon Sep 17 00:00:00 2001
From: liuhongt 
Date: Fri, 11 Dec 2020 19:02:43 +0800
Subject: [PATCH] [X86] Fold more shuffle builtins to VEC_PERM_EXPR.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A follow-up to https://gcc.gnu.org/pipermail/gcc-patches/2019-May/52

Re: [PATCH] genemit: Handle `const_double_zero' rtx

[Maciej W. Rozycki]

On Tue, 15 Dec 2020, Jeff Law wrote:

> > @@ -1942,7 +1942,7 @@ gen_divdf3_cc (rtx operand0 ATTRIBUTE_UN
> > gen_rtx_DIV (DFmode,
> > operand1,
> > operand2),
> > -   const0_rtx)),
> > +   CONST_DOUBLE_ATOF ("0", VOIDmode))),
> > gen_rtx_SET (operand0,
> > gen_rtx_DIV (DFmode,
> > copy_rtx (operand1),
> >
> > gcc/
> > * genemit.c (gen_exp) : Handle `const_double_zero' 
> > rtx.
> > ---
> > Hi,
> >
> >  I have verified this with a bootstrap of a `powerpc64le-linux-gnu' native 
> > compiler, and that it builds a `pdp11-aout' cross-compiler up to the point 
> > of failing to find target headers.  I have no means to verify it further, 
> > the target configuration is too exotic to me, so I will appreciate help.
> >
> >  NB this only triggers with insn-emit.c code produced from named RTL insns 
> > for the purpose of calling them directly, which does not apply for the VAX 
> > backend, as it does not give names to any insns using `const_double_zero'.  
> > Which is why I didn't spot this issue with all my VAX verification.
> >
> >  Thanks to Martin for bringing my attention to this regression, and sorry 
> > to miss this in testing.
> >
> >  OK to apply?
> Presumably you can't use CONST0_RTX (mode) here?  Assuming that's the
> case, then this is fine.

 Well, `mode' is VOID for simplicity and to match what the middle end 
presents as an operand to the COMPARE operation, as also shown with the 
diff above, so with CONST0_RTX (mode) we'd be back to what amounts to 
`const0_rtx' aka `const_int 0', which is exactly what we want to get away 
from.

 Alternatively we could possibly give `const_double_zero' a proper FP 
mode, but it seems to me like an unnecessary complication, as it would 
then have to be individually requested and iterated over all the relevant 
modes.

 Have I missed anything here?

 NB the PDP-11 pieces affected here and tripping this assertion are I 
believe dead code, as these insns are only ever produced by splitters and 
do not appear to be referred by their names.  We need this change however 
for completeness so that `const_double_zero' can be used in contexts where 
an insn actually will be referred by its name.

 However the PDP-11 code being dead makes it a bit more difficult to 
examine actual consequences of such a change like I have proposed than it 
would otherwise be.  In these circumstances I think my proposal is safe if 
a bit overly cautious.

  Maciej

Re: [PATCH, rs6000] Don't set MMA prefixed instruction length to 8

[Segher Boessenkool]

On Mon, Dec 14, 2020 at 04:23:48PM -0600, Pat Haugen wrote:
> Prefixed instructions should not have their length explicitly set to '8'. The 
> function get_attr_length() will adjust the length appropriately based on the 
> value of the "prefixed" attribute.
> 
> Bootstrap/regtest on powerpc64le (Power8/Power10) with no new regressions. Ok 
> for trunk?

Okay for trunk.  Thanks!


Segher

Re: [PATCH 1/2] Remove Report keyword for options

[Martin Liška]

On 12/15/20 8:42 PM, Jeff Law wrote:

Arguably not a bugfix.  But I think this is reasonable, even during stage3.


Thank you.



OK by me, but give Richi and Jakub a couple days if they object due to
it not being a bugfix.


To be honest it's only removal of a dead code. Hope it's fine to install the 
patch now.
I'm planning to work some changes related to options and I would appreciate the 
clean up
to be installed now. That said, I'm going to push the changes.

Martin

RE: [PATCH][GCC][PR target/98177] aarch64: SVE: ICE in expand_direct_optab_fn

[Przemyslaw Wirkus via Gcc-patches]

> Przemyslaw Wirkus  writes:
> > Hi,
> >
> > Recent 'support SVE comparisons for unpacked integers' patch extends
> > operands of define_expands from SVE_FULL to SVE_ALL. This causes an
> > ICE hence this PR patch.
> >
> > This patch adds this relaxation for:
> > + reduc__scal_ and
> > + arch64_pred_reduc__
> > in order to support extra modes. Missing modes were used in REDUC_MAX.
> >
> > Original PR snippet proposed to reproduce issue was only causing ICE
> > for C++ compiler (see pr98177-1 test cases). I've slightly modified
> > original snippet in order to reproduce issue on both C and C++
> > compilers. These are pr98177-2 test cases.
> >
> > Bootstrap/regression test for AArch64 aarch64-elf and no issues.
> 
> This is a bug in the vectoriser: the vectoriser shouldn't generate
> IFN_REDUC_MAX calls that the target doesn't support.
> 
> I think the problem comes from using the wrong interface to get the index
> type for a COND_REDUCTION.  vectorizable_reduction has:
> 
>   cr_index_vector_type = build_vector_type (cr_index_scalar_type,
> nunits_out);
> 
> which means that for fixed-length SVE we get a V2SI (a 64-bit Advanced SIMD
> vector) instead of a VNx2SI (an SVE vector that stores SI elements in DI
> containers).  It should be using:
> 
>   cr_index_vector_type = get_same_sized_vectype (cr_index_scalar_type,
>  vectype_out);
> 
> instead.  Same idea for the build_vector_type call in
> vect_create_epilog_for_reduction.

Hi Richard,
I've followed your guidance and indeed root cause was as you described.
Please see new patch in attachment.

Bootstrap/regression test for AArch64 aarch64-elf and no issues.

OK for master?

gcc/ChangeLog:

PR target/98177
* tree-vect-loop.c (vectorizable_reduction): Use get_same_sized_vectype 
to
obtain index type.

gcc/testsuite/ChangeLog:

PR target/98177
* g++.target/aarch64/pr98177-1.C: New test.
* g++.target/aarch64/pr98177-2.C: New test.
* gcc.target/aarch64/pr98177-1.c: New test.
* gcc.target/aarch64/pr98177-2.c: New test.

> Thanks,
> Richard


rb13905_v2.patch
Description: rb13905_v2.patch

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Pierre-Marie de Rodat]

Hello all,

On Wed, Dec 16, 2020 at 9:31 AM Martin Liška  wrote:
> I've just create PR for it:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98312

Thank you. I can reproduce the issue: at this point I suspect that my
testing hasn’t detected this because of some inconsistency with my
incremental builds. The actual correction is a few patches later in my
porting queue: I’m about to commit it. Sorry for the trouble!

-- 
Pierre-Marie de Rodat 

Re: [PATCH] PR fortran/98284 - ICE in get_array_index

[Thomas Koenig via Gcc-patches]

Hi Harald,


ICE-on-invalid: testcase by Arseny, draft patch by Steve,
slightly polished and regtested by me on x86_64-pc-linux-gnu.


OK for master.

Thanks for the patch!

Best regards

Thomas

Re: [PATCH] genemit: Handle `const_double_zero' rtx

[Richard Sandiford via Gcc-patches]

"Maciej W. Rozycki"  writes:
> On Tue, 15 Dec 2020, Jeff Law wrote:
>
>> > @@ -1942,7 +1942,7 @@ gen_divdf3_cc (rtx operand0 ATTRIBUTE_UN
>> >gen_rtx_DIV (DFmode,
>> >operand1,
>> >operand2),
>> > -  const0_rtx)),
>> > +  CONST_DOUBLE_ATOF ("0", VOIDmode))),
>> >gen_rtx_SET (operand0,
>> >gen_rtx_DIV (DFmode,
>> >copy_rtx (operand1),
>> >
>> >gcc/
>> >* genemit.c (gen_exp) : Handle `const_double_zero' 
>> >rtx.
>> > ---
>> > Hi,
>> >
>> >  I have verified this with a bootstrap of a `powerpc64le-linux-gnu' native 
>> > compiler, and that it builds a `pdp11-aout' cross-compiler up to the point 
>> > of failing to find target headers.  I have no means to verify it further, 
>> > the target configuration is too exotic to me, so I will appreciate help.
>> >
>> >  NB this only triggers with insn-emit.c code produced from named RTL insns 
>> > for the purpose of calling them directly, which does not apply for the VAX 
>> > backend, as it does not give names to any insns using `const_double_zero'. 
>> >  
>> > Which is why I didn't spot this issue with all my VAX verification.
>> >
>> >  Thanks to Martin for bringing my attention to this regression, and sorry 
>> > to miss this in testing.
>> >
>> >  OK to apply?
>> Presumably you can't use CONST0_RTX (mode) here?  Assuming that's the
>> case, then this is fine.
>
>  Well, `mode' is VOID for simplicity and to match what the middle end 
> presents as an operand to the COMPARE operation, as also shown with the 
> diff above, so with CONST0_RTX (mode) we'd be back to what amounts to 
> `const0_rtx' aka `const_int 0', which is exactly what we want to get away 
> from.
>
>  Alternatively we could possibly give `const_double_zero' a proper FP 
> mode, but it seems to me like an unnecessary complication, as it would 
> then have to be individually requested and iterated over all the relevant 
> modes.

Generated FP const_double rtxes have to have a proper (non-VOID) mode
though.  VOIDmode CONST_DOUBLEs are always (legacy) integers instead
of FP values.

So yeah, giving const_double_zero a proper mode seems like the way to go.
It's technically possible to drop it in a pure matching context, but I'm
not sure how valuable that is in practice, given that other parts of the
matched pattern would usually need to refer to the same mode anyway.

>  Have I missed anything here?
>
>  NB the PDP-11 pieces affected here and tripping this assertion are I 
> believe dead code, as these insns are only ever produced by splitters and 
> do not appear to be referred by their names.  We need this change however 
> for completeness so that `const_double_zero' can be used in contexts where 
> an insn actually will be referred by its name.
>
>  However the PDP-11 code being dead makes it a bit more difficult to 
> examine actual consequences of such a change like I have proposed than it 
> would otherwise be.  In these circumstances I think my proposal is safe if 
> a bit overly cautious.

CONST_DOUBLE_ATOF ("0", VOIDmode) seems malformed though, and I'd expect
it to assert in REAL_MODE_FORMAT (via the format_helper constructor).
I'm not sure the patch is strictly safer than the status quo.

FWIW, I agree with Jeff that this ought to be CONST0_RTX (mode).

Thanks,
Richard

Re: [PATCH][GCC][PR target/98177] aarch64: SVE: ICE in expand_direct_optab_fn

[Richard Sandiford via Gcc-patches]

Przemyslaw Wirkus  writes:
> > This is a bug in the vectoriser: the vectoriser shouldn't generate
> > IFN_REDUC_MAX calls that the target doesn't support.
> > 
> > I think the problem comes from using the wrong interface to get the index
> > type for a COND_REDUCTION.  vectorizable_reduction has:
> > 
> >   cr_index_vector_type = build_vector_type (cr_index_scalar_type,
> > nunits_out);
> > 
> > which means that for fixed-length SVE we get a V2SI (a 64-bit Advanced SIMD
> > vector) instead of a VNx2SI (an SVE vector that stores SI elements in DI
> > containers).  It should be using:
> > 
> >   cr_index_vector_type = get_same_sized_vectype (cr_index_scalar_type,
> >  vectype_out);
> > 
> > instead.  Same idea for the build_vector_type call in
> > vect_create_epilog_for_reduction.

Note that for this last bit I meant:

  tree vectype_unsigned = build_vector_type
(scalar_type_unsigned, TYPE_VECTOR_SUBPARTS (vectype));

which should become:

  tree vectype_unsigned = get_same_sized_vectype (scalar_type_unsigned,
  vectype);

This is the “transform” code that partners the “analysis” code that
you're patching.  Changing one but not the other would cause problems
if (say) the Advanced SIMD REDUC_MAX patterns were disabled.  We'd then
correctly pick an SVE mode like VNx4SI when doing the analysis, but generate
an unsupported V4SI REDUC_MAX in vect_create_epilog_for_reduction.
That in turn would trip the kind of expand-time assert that was
reported in the PR, just for a different case.

It's better for the modes to match up anyway: we should use a VNx4SI
reduction when operating on SVE and a V4SI reducation when operating on
Advanced SIMD.  This is particularly true for big endian, where mixing
SVE and Advanced SIMD can involve a permute.

> diff --git a/gcc/testsuite/g++.target/aarch64/pr98177-1.C 
> b/gcc/testsuite/g++.target/aarch64/pr98177-1.C
> new file mode 100644
> index 
> ..a776b7352f966f6b1d870ed51a7c94647bc46d80
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/aarch64/pr98177-1.C
> @@ -0,0 +1,10 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -march=armv8.2-a+sve -msve-vector-bits=128" } */
> +
> +int a, b;
> +short c;
> +void d(long e) {
> +  for (int f = 0; f < b; f += 1)
> +for (short g = 0; g < c; g += 5)
> +  a = (short)e;
> +}

It'd be better to put these g++.target/aarch64/sve and drop the -march
option.  That way we'll test with the user's specified -march or -mcpu
if that -march/-mcpu already supports SVE.

Same idea for the other tests (including the C ones).

OK for trunk with those changes, thanks.

Richard

Re: V4 [PATCH 1/3] Switch to a new section if the SECTION_RETAIN bit doesn't match

[H.J. Lu via Gcc-patches]

On Tue, Dec 15, 2020 at 4:44 PM Jeff Law  wrote:
>
>
>
> On 12/15/20 10:30 AM, H.J. Lu wrote:
> > When definitions marked with used attribute and unmarked definitions are
> > placed in the section with the same name, switch to a new section if the
> > SECTION_RETAIN bit doesn't match.
> >
> > gcc/
> >
> >   PR target/98146
> >   * output.h (switch_to_section): Add a tree argument, default to
> >   nullptr.
> >   * varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
> >   return and switch to a new section later.
> >   (assemble_start_function): Pass decl to switch_to_section.
> >   (assemble_variable): Likewise.
> >   (switch_to_section): If the SECTION_RETAIN bit doesn't match,
> >   switch to a new section.
> >
> > gcc/testsuite/
> >
> >   PR target/98146
> >   * c-c++-common/attr-used-5.c: New test.
> >   * c-c++-common/attr-used-6.c: Likewise.
> >   * c-c++-common/attr-used-7.c: Likewise.
> >   * c-c++-common/attr-used-8.c: Likewise.
> >   * c-c++-common/attr-used-9.c: Likewise.
> So as an additional follow-up could you add to the get_section comment
> the special handling were add SECTION_WRITE and SECTION_RELRO to the
> flags.  That's not something I would expect that function to do either.
> Consider that comment addition pre-approved.
>

I am checking the patch with this change:

diff --git a/gcc/varasm.c b/gcc/varasm.c
index 46f79ea28e6..267a052331d 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -282,7 +282,11 @@ get_noswitch_section (unsigned int flags,
noswitch_section_callback callback)
 /* Return the named section structure associated with NAME.  Create
a new section with the given fields if no such structure exists.
When NOT_EXISTING, then fail if the section already exists.  Return
-   the existing section if the SECTION_RETAIN bit doesn't match.  */
+   the existing section if the SECTION_RETAIN bit doesn't match.  Set
+   the SECTION_WRITE | SECTION_RELRO bits on the the existing section
+   if one of the section flags is SECTION_WRITE | SECTION_RELRO and the
+   other has none of these flags in named sections and either the section
+   hasn't been declared yet or has been declared as writable.  */

 section *
 get_section (const char *name, unsigned int flags, tree decl,

Thanks.

-- 
H.J.
From 22c1d0be1399becffac58d7509ab30a8ecd97a9a Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 3 Dec 2020 11:01:06 -0800
Subject: [PATCH] Switch to a new section if the SECTION_RETAIN bit doesn't
 match

When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.

gcc/

	PR target/98146
	* output.h (switch_to_section): Add a tree argument, default to
	nullptr.
	* varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
	return and switch to a new section later.
	(assemble_start_function): Pass decl to switch_to_section.
	(assemble_variable): Likewise.
	(switch_to_section): If the SECTION_RETAIN bit doesn't match,
	switch to a new section.

gcc/testsuite/

	PR target/98146
	* c-c++-common/attr-used-5.c: New test.
	* c-c++-common/attr-used-6.c: Likewise.
	* c-c++-common/attr-used-7.c: Likewise.
	* c-c++-common/attr-used-8.c: Likewise.
	* c-c++-common/attr-used-9.c: Likewise.
---
 gcc/output.h |  2 +-
 gcc/testsuite/c-c++-common/attr-used-5.c | 26 
 gcc/testsuite/c-c++-common/attr-used-6.c | 26 
 gcc/testsuite/c-c++-common/attr-used-7.c |  8 +
 gcc/testsuite/c-c++-common/attr-used-8.c |  8 +
 gcc/testsuite/c-c++-common/attr-used-9.c | 28 +
 gcc/varasm.c | 38 
 7 files changed, 130 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-9.c

diff --git a/gcc/output.h b/gcc/output.h
index fa8ace1f394..1f9af46da1d 100644
--- a/gcc/output.h
+++ b/gcc/output.h
@@ -548,7 +548,7 @@ extern void switch_to_other_text_partition (void);
 extern section *get_cdtor_priority_section (int, bool);
 
 extern bool unlikely_text_section_p (section *);
-extern void switch_to_section (section *);
+extern void switch_to_section (section *, tree = nullptr);
 extern void output_section_asm_op (const void *);
 
 extern void record_tm_clone_pair (tree, tree);
diff --git a/gcc/testsuite/c-c++-common/attr-used-5.c b/gcc/testsuite/c-c++-common/attr-used-5.c
new file mode 100644
index 000..9fc0d3834e9
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-used-5.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+struct dtv_slotinfo_list
+{
+  struct dtv_slotinfo_list *next;
+};
+
+extern s

[PATCH] libcody: Fix build for older GCC versions

[Jonathan Wakely via Gcc-patches]

Before CWG DR 1955 the controlling expression for an #elif must be
syntactically correct, meaning this won't compile with C++11 compilers
such as gcc 4.8:

The solution is to define __has_include(X) as 0 for compilers that don't
support it.

The second problem is that when  is found, it is used
without the std:: qualification.

libcody/ChangeLog:

* internal.hh: Define fallback macros for __has_builtin and
__has_include. Use __has_builtin for __builtin_FILE and
__builtin_LINE. Define alias for std::source_location.

Built on GNu/Linux using both gcc-11 and gcc-4.8, and also by hacking
it so that __builtin_FILE and __builtin_LINE aren't found, and
 gets used.

OK for trunk?


commit 2c0f7be4ceb175714ede9ad7cbf364314bec2f4a
Author: Jonathan Wakely 
Date:   Wed Dec 16 12:58:14 2020

libcody: Fix build for older GCC versions

Before CWG DR 1955 the controlling expression for an #elif must be
syntactically correct, meaning this won't compile with C++11 compilers
such as gcc 4.8:

The solution is to define __has_include(X) as 0 for compilers that don't
support it.

The second problem is that when  is found, it is used
without the std:: qualification.

libcody/ChangeLog:

* internal.hh: Define fallback macros for __has_builtin and
__has_include. Use __has_builtin for __builtin_FILE and
__builtin_LINE. Define alias for std::source_location.

diff --git a/libcody/internal.hh b/libcody/internal.hh
index d744b564cda..87673f56657 100644
--- a/libcody/internal.hh
+++ b/libcody/internal.hh
@@ -4,14 +4,23 @@
 
 #include "cody.hh"
 
+#ifndef __has_builtin
+#define __has_builtin(X) 0
+#endif
+#ifndef __has_include
+#define __has_include(X) 0
+#endif
+
 // C++
-#if __GNUC__ >= 10
+#if __has_builtin(__builtin_FILE) && __has_builtin(__builtin_LINE)
 #define CODY_LOC_BUILTIN 1
-#elif !defined (__has_include)
 #elif __has_include ()
 #include 
+#ifdef __cpp_lib_source_location
 #define CODY_LOC_SOURCE 1
 #endif
+#endif
+
 // C
 #include 
 
@@ -44,6 +53,8 @@ public:
   }
 
 #if !CODY_LOC_BUILTIN && CODY_LOC_SOURCE
+  using source_location = std::source_location;
+
   constexpr Location (source_location loc = source_location::current ())
 : Location (loc.file (), loc.line ())
   {

c++: Fix (some) solaris breakage

[Nathan Sidwell]

Jonathan was kind enough to test this fix.  It doesn't address all the 
solaris issues, but does get us further.


Solaris' sys/socket uses the poisoned bcopy identifier, so we must
#include it before poisoning.  The inclusion happens in cody.hh, so we
preemptively copy a bit of cody's inclusion logic to get it earlier.

gcc/cp/
* mapper-client.cc: Include sys/socket.h before system.h.

pushing to trunk
--
Nathan Sidwell
diff --git i/gcc/cp/mapper-client.cc w/gcc/cp/mapper-client.cc
index acec591296a..2ad770b3d78 100644
--- i/gcc/cp/mapper-client.cc
+++ w/gcc/cp/mapper-client.cc
@@ -19,6 +19,11 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+#if defined (__unix__)
+// Solaris11's socket header used bcopy, which we poison.  cody.hh
+// will include it later under the above check
+#include 
+#endif
 #include "system.h"
 
 #include "line-map.h"
@@ -28,6 +33,10 @@ along with GCC; see the file COPYING3.  If not see
 
 #include "../../c++tools/resolver.h"
 
+#if !HOST_HAS_O_CLOEXEC
+#define O_CLOEXEC 0
+#endif
+
 module_client::module_client (pex_obj *p, int fd_from, int fd_to)
   : Client (fd_from, fd_to), pex (p)
 {

[Ada] Another small adjustment to System.Value_R

[Pierre-Marie de Rodat]

This makes the code more explicit for the sake of static analyzers.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/s-valuer.adb (Scan_Decimal_Digits): Tweak overflow test.
(Scan_Integral_Digits): Likewise.diff --git a/gcc/ada/libgnat/s-valuer.adb b/gcc/ada/libgnat/s-valuer.adb
--- a/gcc/ada/libgnat/s-valuer.adb
+++ b/gcc/ada/libgnat/s-valuer.adb
@@ -236,12 +236,15 @@ package body System.Value_R is
Temp := Value * Uns (Base) + Uns (Digit);
 
--  Check if Temp is larger than Precision_Limit, taking into
-   --  account that Temp may have wrapped around.
+   --  account that Temp may wrap around when Precision_Limit is
+   --  equal to the largest integer.
 
if Value <= Umax
  or else (Value <= UmaxB
-   and then Temp <= Precision_Limit
-   and then Temp >= Uns (Base))
+   and then ((Precision_Limit < Uns'Last
+   and then Temp <= Precision_Limit)
+ or else (Precision_Limit = Uns'Last
+   and then Temp >= Uns (Base
then
   Value := Temp;
   Scale := Scale - 1;
@@ -386,12 +389,15 @@ package body System.Value_R is
 Temp := Value * Uns (Base) + Uns (Digit);
 
 --  Check if Temp is larger than Precision_Limit, taking into
---  account that Temp may have wrapped around.
+--  account that Temp may wrap around when Precision_Limit is
+--  equal to the largest integer.
 
 if Value <= Umax
   or else (Value <= UmaxB
-and then Temp <= Precision_Limit
-and then Temp >= Uns (Base))
+and then ((Precision_Limit < Uns'Last
+and then Temp <= Precision_Limit)
+  or else (Precision_Limit = Uns'Last
+and then Temp >= Uns (Base
 then
Value := Temp;
 

[Ada] Add some OS constants to control serial port

[Pierre-Marie de Rodat]

This adds some OS constants that are needed to control the serial port
on GNU/Linux.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* s-oscons-tmplt.c: Add some OS constants.diff --git a/gcc/ada/s-oscons-tmplt.c b/gcc/ada/s-oscons-tmplt.c
--- a/gcc/ada/s-oscons-tmplt.c
+++ b/gcc/ada/s-oscons-tmplt.c
@@ -724,6 +724,41 @@ CNU(CRTSCTS, "Output hw flow control")
 #endif
 CNU(CREAD, "Read")
 
+#ifndef ICANON
+# define ICANON -1
+#endif
+CNU(ICANON, "canonical mode")
+
+#ifndef CBAUD
+# define CBAUD -1
+#endif
+CNU(CBAUD, "baud speed mask")
+
+#ifndef ECHO
+# define ECHO -1
+#endif
+CNU(ECHO, "echo input characters")
+
+#ifndef ECHOE
+# define ECHOE -1
+#endif
+CNU(ECHOE, "erase preceding characters")
+
+#ifndef ECHOK
+# define ECHOK -1
+#endif
+CNU(ECHOK, "kill character, erases current line")
+
+#ifndef ECHOCTL
+# define ECHOCTL -1
+#endif
+CNU(ECHOCTL, "echo special characters")
+
+#ifndef ECHONL
+# define ECHONL -1
+#endif
+CNU(ECHONL, "force echo NL character")
+
 #ifndef CS5
 # define CS5 -1
 #endif

[Ada] Mark generic body outside of SPARK

[Pierre-Marie de Rodat]

Unit Ada.Text_IO.Fixed_IO is now generic, which makes it necessary to
exclude the generic body from SPARK explicitly because it uses type
Long_Long_Float which is not supported in GNATprove. This ensures that
the unit can be instantiated from SPARK code.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-tifiio.adb: Mark body not in SPARK.
* libgnat/a-tifiio.ads: Mark spec in SPARK.
* libgnat/a-tifiio__128.adb: Mark body not in SPARK.diff --git a/gcc/ada/libgnat/a-tifiio.adb b/gcc/ada/libgnat/a-tifiio.adb
--- a/gcc/ada/libgnat/a-tifiio.adb
+++ b/gcc/ada/libgnat/a-tifiio.adb
@@ -162,7 +162,7 @@ with System.Val_Fixed_32; use System.Val_Fixed_32;
 with System.Val_Fixed_64; use System.Val_Fixed_64;
 with System.Val_LLF;  use System.Val_LLF;
 
-package body Ada.Text_IO.Fixed_IO is
+package body Ada.Text_IO.Fixed_IO with SPARK_Mode => Off is
 
--  Note: we still use the floating-point I/O routines for types whose small
--  is not the ratio of two sufficiently small integers. This will result in


diff --git a/gcc/ada/libgnat/a-tifiio.ads b/gcc/ada/libgnat/a-tifiio.ads
--- a/gcc/ada/libgnat/a-tifiio.ads
+++ b/gcc/ada/libgnat/a-tifiio.ads
@@ -23,7 +23,7 @@
 private generic
type Num is delta <>;
 
-package Ada.Text_IO.Fixed_IO is
+package Ada.Text_IO.Fixed_IO with SPARK_Mode => On is
 
Default_Fore : Field := Num'Fore;
Default_Aft  : Field := Num'Aft;


diff --git a/gcc/ada/libgnat/a-tifiio__128.adb b/gcc/ada/libgnat/a-tifiio__128.adb
--- a/gcc/ada/libgnat/a-tifiio__128.adb
+++ b/gcc/ada/libgnat/a-tifiio__128.adb
@@ -164,7 +164,7 @@ with System.Val_Fixed_64;  use System.Val_Fixed_64;
 with System.Val_Fixed_128; use System.Val_Fixed_128;
 with System.Val_LLF;   use System.Val_LLF;
 
-package body Ada.Text_IO.Fixed_IO is
+package body Ada.Text_IO.Fixed_IO with SPARK_Mode => Off is
 
--  Note: we still use the floating-point I/O routines for types whose small
--  is not the ratio of two sufficiently small integers. This will result in

[Ada] Reject junk syntax for Contract_Cases/Test_Case/Subprogram_Variant

[Pierre-Marie de Rodat]

Reject contracts Contract_Cases, Test_Case and Subprogram_Variant whose
expression is either "null", "(null record)" or has extra parentheses.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch13.adb (Analyze_Aspect_Specifications): Add a codefix
for extra parentheses around aspect Annotate expression; reject
"(null record)" aggregate and extra parentheses around aspect
Test_Case expression.
* sem_prag.adb (Analyze_Pragma): Reject "null", "(null record)"
and extra parentheses around pragma Contract_Cases; likewise for
pragma Subprogram_Variant.diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -4145,7 +4145,8 @@ package body Sem_Ch13 is
 --  Must not be parenthesized
 
 if Paren_Count (Expr) /= 0 then
-   Error_Msg_F ("extra parentheses ignored", Expr);
+   Error_Msg -- CODEFIX
+ ("redundant parentheses", First_Sloc (Expr));
 end if;
 
 --  List of arguments is list of aggregate expressions
@@ -4426,13 +4427,24 @@ package body Sem_Ch13 is
  goto Continue;
   end if;
 
-  if Nkind (Expr) /= N_Aggregate then
+  if Nkind (Expr) /= N_Aggregate
+or else Null_Record_Present (Expr)
+  then
  Error_Msg_Name_1 := Nam;
  Error_Msg_NE
("wrong syntax for aspect `%` for &", Id, E);
  goto Continue;
   end if;
 
+  --  Check that the expression is a proper aggregate (no
+  --  parentheses).
+
+  if Paren_Count (Expr) /= 0 then
+ Error_Msg -- CODEFIX
+   ("redundant parentheses", First_Sloc (Expr));
+ goto Continue;
+  end if;
+
   --  Create the list of arguments for building the Test_Case
   --  pragma.
 


diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -545,16 +545,31 @@ package body Sem_Prag is
 
   --  Single and multiple contract cases must appear in aggregate form. If
   --  this is not the case, then either the parser or the analysis of the
-  --  pragma failed to produce an aggregate.
+  --  pragma failed to produce an aggregate, e.g. when the contract is
+  --  "null" or a "(null record)".
 
-  pragma Assert (Nkind (CCases) = N_Aggregate);
+  pragma Assert
+(if Nkind (CCases) = N_Aggregate
+ then Null_Record_Present (CCases)
+   xor (Present (Component_Associations (CCases))
+  or
+Present (Expressions (CCases)))
+ else Nkind (CCases) = N_Null);
 
   --  Only CASE_GUARD => CONSEQUENCE clauses are allowed
 
-  if Present (Component_Associations (CCases))
+  if Nkind (CCases) = N_Aggregate
+and then Present (Component_Associations (CCases))
 and then No (Expressions (CCases))
   then
 
+ --  Check that the expression is a proper aggregate (no parentheses)
+
+ if Paren_Count (CCases) /= 0 then
+Error_Msg -- CODEFIX
+  ("redundant parentheses", First_Sloc (CCases));
+ end if;
+
  --  Ensure that the formal parameters are visible when analyzing all
  --  clauses. This falls out of the general rule of aspects pertaining
  --  to subprogram declarations.
@@ -29170,16 +29185,31 @@ package body Sem_Prag is
 
   --  Single and multiple contract cases must appear in aggregate form. If
   --  this is not the case, then either the parser of the analysis of the
-  --  pragma failed to produce an aggregate.
+  --  pragma failed to produce an aggregate, e.g. when the contract is
+  --  "null" or a "(null record)".
 
-  pragma Assert (Nkind (Variants) = N_Aggregate);
+  pragma Assert
+(if Nkind (Variants) = N_Aggregate
+ then Null_Record_Present (Variants)
+   xor (Present (Component_Associations (Variants))
+  or
+Present (Expressions (Variants)))
+ else Nkind (Variants) = N_Null);
 
   --  Only "change_direction => discrete_expression" clauses are allowed
 
-  if Present (Component_Associations (Variants))
+  if Nkind (Variants) = N_Aggregate
+and then Present (Component_Associations (Variants))
 and then No (Expressions (Variants))
   then
 
+ --  Check that the expression is a proper aggregate (no parentheses)
+
+ if Paren_Count (Variants) /= 0 then
+Error_Msg -- CODEFIX
+  ("redundant parentheses", First_Sloc (Variants));
+ end if;
+

[Ada] Fix gmem.out corruption by GNAT.Expect

[Pierre-Marie de Rodat]

GNAT.Expect.Non_Blocking_Spawn executes memory allocation/deallocation
after calling fork on the child process side. The libgmem library could
write to the same gmem.out file in the parent and child processes
simultaneously before the child process would load and initialize the
new executable file.  This change disables the libgmem processing on the
child side before the new executable starts.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* adaint.h (__gnat_in_child_after_fork): New flag to express
child process side after fork call.
* adaint.c (__gnat_portable_spawn): Set flag
__gnat_in_child_after_fork.
* expect.c (__gnat_expect_fork): Set __gnat_in_child_after_fork
to one on child side.
* libgnat/memtrack.adb
(In_Child_After_Fork): Flag to disable memory tracking.
(Allow_Trace): New routine defining if memory should be tracked.
(Alloc, Realloc, Free): Use Allow_Trace in "if" condition
instead of First_Call.diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -244,6 +244,8 @@ UINT __gnat_current_ccs_encoding;
 
 #include "adaint.h"
 
+int __gnat_in_child_after_fork = 0;
+
 #if defined (__APPLE__) && defined (st_mtime)
 #define st_atim st_atimespec
 #define st_mtim st_mtimespec
@@ -2421,6 +2423,7 @@ __gnat_portable_spawn (char *args[] ATTRIBUTE_UNUSED)
   if (pid == 0)
 {
   /* The child. */
+  __gnat_in_child_after_fork = 1;
   if (execv (args[0], MAYBE_TO_PTR32 (args)) != 0)
 	_exit (1);
 }


diff --git a/gcc/ada/adaint.h b/gcc/ada/adaint.h
--- a/gcc/ada/adaint.h
+++ b/gcc/ada/adaint.h
@@ -139,7 +139,15 @@ struct file_attributes {
  * fit the above struct on any system)
  */
 
-extern int__gnat_max_path_len;
+extern int  __gnat_max_path_len;
+extern int  __gnat_in_child_after_fork;
+/* This flag expresses the state when the fork call just returned zero result,
+ * i.e. when the new born child process is created and the new executable is
+ * not loaded yet. It is used to e.g. disable tracing memory
+ * allocation/deallocation in memtrack.adb just after fork returns in the child
+ * process to avoid both parent and child writing to the same gmem.out file
+ * simultaneously */
+
 extern OS_Time __gnat_current_time		   (void);
 extern void   __gnat_current_time_string   (char *);
 extern void   __gnat_to_gm_time			   (OS_Time *, int *, int *,


diff --git a/gcc/ada/expect.c b/gcc/ada/expect.c
--- a/gcc/ada/expect.c
+++ b/gcc/ada/expect.c
@@ -39,6 +39,7 @@
 #include "system.h"
 #endif
 
+#include "adaint.h"
 #include 
 
 #ifdef __MINGW32__
@@ -78,7 +79,6 @@
 #include 
 #include 
 #include 
-#include "adaint.h"
 #include "mingw32.h"
 
 int
@@ -360,7 +360,11 @@ __gnat_pipe (int *fd)
 int
 __gnat_expect_fork (void)
 {
-  return fork ();
+  int pid = fork();
+  if (pid == 0) {
+__gnat_in_child_after_fork = 1;
+  }
+  return pid;
 }
 
 void


diff --git a/gcc/ada/libgnat/memtrack.adb b/gcc/ada/libgnat/memtrack.adb
--- a/gcc/ada/libgnat/memtrack.adb
+++ b/gcc/ada/libgnat/memtrack.adb
@@ -102,6 +102,9 @@ package body System.Memory is
pragma Import (C, OS_Exit, "__gnat_os_exit");
pragma No_Return (OS_Exit);
 
+   In_Child_After_Fork : Integer;
+   pragma Import (C, In_Child_After_Fork, "__gnat_in_child_after_fork");
+
procedure fwrite
  (Ptr: System.Address;
   Size   : size_t;
@@ -149,6 +152,24 @@ package body System.Memory is
--  themselves do dynamic allocation. We use First_Call flag to avoid
--  infinite recursion
 
+   function Allow_Trace return Boolean;
+   pragma Inline (Allow_Trace);
+   --  Check if the memory trace is allowed
+
+   -
+   -- Allow_Trace --
+   -
+
+   function Allow_Trace return Boolean is
+   begin
+  if First_Call then
+ First_Call := False;
+ return In_Child_After_Fork = 0;
+  else
+ return False;
+  end if;
+   end Allow_Trace;
+
---
-- Alloc --
---
@@ -176,14 +197,12 @@ package body System.Memory is
 
   Result := c_malloc (Actual_Size);
 
-  if First_Call then
+  if Allow_Trace then
 
  --  Logs allocation call
  --  format is:
  --   'A' ... 
 
- First_Call := False;
-
  if Needs_Init then
 Gmem_Initialize;
  end if;
@@ -243,14 +262,12 @@ package body System.Memory is
begin
   Lock_Task.all;
 
-  if First_Call then
+  if Allow_Trace then
 
  --  Logs deallocation call
  --  format is:
  --   'D'... 
 
- First_Call := False;
-
  if Needs_Init then
 Gmem_Initialize;
  end if;
@@ -334,9 +351,7 @@ package body System.Memory is
   Abort_Defer.all;
   Lock_Task.all;
 
-  if First_Call then
- First_Call := False;
-
+  if Allow_Trace then
  --  We first log deallocation call
 
  if Needs_In

[Ada] Fix glitch in comment of System.Powten_Table

[Pierre-Marie de Rodat]

There is a typo in the formula to compute Maxpow exposed in the comment.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/s-powtab.ads (Maxpow): Use explicit formula in comment.diff --git a/gcc/ada/libgnat/s-powtab.ads b/gcc/ada/libgnat/s-powtab.ads
--- a/gcc/ada/libgnat/s-powtab.ads
+++ b/gcc/ada/libgnat/s-powtab.ads
@@ -36,9 +36,9 @@ package System.Powten_Table is
 
Maxpow : constant := 22;
--  The number of entries in this table is chosen to include powers of ten
-   --  that are exactly representable with long_long_float. Assuming that on
-   --  all targets we have 53 bits of mantissa for the type, the upper bound is
-   --  given by 53/(log 5). If the scaling factor for a string is greater than
+   --  that are exactly representable with Long_Long_Float. Assuming that on
+   --  all targets we have 53 bits of mantissa for the type, the upper bound
+   --  is given by 53 * log 2 / log 5. If the scaling factor is greater than
--  Maxpow, it can be obtained by several multiplications, which is less
--  efficient than with a bigger table, but avoids anomalies at end points.
 

[Ada] Fix integer-vs-float errors in example for Test_Case pragma

[Pierre-Marie de Rodat]

The example for Test_Case pragma was rejected by the compiler; now
fixed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* doc/gnat_rm/implementation_defined_pragmas.rst
(Test_Case): Change integer to float literals.
* gnat_rm.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -6652,8 +6652,8 @@ expression. The following is an example of use within a package spec:
  function Sqrt (Arg : Float) return Float;
  pragma Test_Case (Name => "Test 1",
Mode => Nominal,
-   Requires => Arg < 1,
-   Ensures  => Sqrt'Result < 10);
+   Requires => Arg < 1.0,
+   Ensures  => Sqrt'Result < 10.0);
  ...
   end Math_Functions;
 


diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi
--- a/gcc/ada/gnat_rm.texi
+++ b/gcc/ada/gnat_rm.texi
@@ -21,7 +21,7 @@
 
 @copying
 @quotation
-GNAT Reference Manual , Nov 20, 2020
+GNAT Reference Manual , Dec 11, 2020
 
 AdaCore
 
@@ -8159,8 +8159,8 @@ package Math_Functions is
function Sqrt (Arg : Float) return Float;
pragma Test_Case (Name => "Test 1",
  Mode => Nominal,
- Requires => Arg < 1,
- Ensures  => Sqrt'Result < 10);
+ Requires => Arg < 1.0,
+ Ensures  => Sqrt'Result < 10.0);
...
 end Math_Functions;
 @end example

[Ada] Fix possible uninitialized ATCB component use

[Pierre-Marie de Rodat]

When System.Memory implementation is using Debug_Pools, Common ATCB's
uninitialized Global_Task_Lock_Nesting component may be used.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnarl/s-tporft.adb (Register_Foreign_Thread): Set
Global_Task_Lock_Nesting before using allocator.diff --git a/gcc/ada/libgnarl/s-tporft.adb b/gcc/ada/libgnarl/s-tporft.adb
--- a/gcc/ada/libgnarl/s-tporft.adb
+++ b/gcc/ada/libgnarl/s-tporft.adb
@@ -53,6 +53,7 @@ begin
 
Local_ATCB.Common.LL.Thread := Thread;
Local_ATCB.Common.Current_Priority := System.Priority'First;
+   Local_ATCB.Common.Global_Task_Lock_Nesting := 0;
Specific.Set (Local_ATCB'Unchecked_Access);
 
--  It is now safe to use an allocator

[Ada] Simplify membership tests with N_Subprogram_Call subtype

[Pierre-Marie de Rodat]

Simplify membership test on N_Procedure_Call_Statement and
N_Function_Call using the collective N_Subprogram_Call subtype. Cleanup
only; semantics is unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_ch6.adb, exp_util.adb, sem_ch4.adb, sem_disp.adb,
sem_elab.adb: Simplify membership test.diff --git a/gcc/ada/exp_ch6.adb b/gcc/ada/exp_ch6.adb
--- a/gcc/ada/exp_ch6.adb
+++ b/gcc/ada/exp_ch6.adb
@@ -3491,8 +3491,7 @@ package body Exp_Ch6 is
   --  of the dimension I/O packages.
 
   if Ada_Version >= Ada_2012
-and then
-   Nkind (Call_Node) in N_Procedure_Call_Statement | N_Function_Call
+and then Nkind (Call_Node) in N_Subprogram_Call
 and then Present (Parameter_Associations (Call_Node))
   then
  Expand_Put_Call_With_Symbol (Call_Node);


diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -12247,8 +12247,7 @@ package body Exp_Util is
--  and view swaps, the parent type is taken from the formal
--  parameter of the subprogram being called.
 
-   if Nkind (Context) in
-N_Function_Call | N_Procedure_Call_Statement
+   if Nkind (Context) in N_Subprogram_Call
  and then No (Type_Map.Get (Entity (Name (Context
then
   New_Ref :=


diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -8088,8 +8088,7 @@ package body Sem_Ch4 is
 --  resolution does not depend on the type of the parameter that
 --  includes the indexing operation.
 
-elsif Nkind (Parent (Par)) in
-N_Function_Call | N_Procedure_Call_Statement
+elsif Nkind (Parent (Par)) in N_Subprogram_Call
   and then Is_Entity_Name (Name (Parent (Par)))
 then
declare


diff --git a/gcc/ada/sem_disp.adb b/gcc/ada/sem_disp.adb
--- a/gcc/ada/sem_disp.adb
+++ b/gcc/ada/sem_disp.adb
@@ -625,7 +625,7 @@ package body Sem_Disp is
   Par := Parent (Par);
end if;
 
-   if Nkind (Par) in N_Function_Call | N_Procedure_Call_Statement
+   if Nkind (Par) in N_Subprogram_Call
  and then Is_Entity_Name (Name (Par))
then
   declare


diff --git a/gcc/ada/sem_elab.adb b/gcc/ada/sem_elab.adb
--- a/gcc/ada/sem_elab.adb
+++ b/gcc/ada/sem_elab.adb
@@ -3744,7 +3744,7 @@ package body Sem_Elab is
 
   Set_Is_Dispatching_Call
 (Marker,
- Nkind (N) in N_Function_Call | N_Procedure_Call_Statement
+ Nkind (N) in N_Subprogram_Call
and then Present (Controlling_Argument (N)));
 
   Set_Is_Elaboration_Checks_OK_Node
@@ -19368,7 +19368,7 @@ package body Sem_Elab is
 
function Is_Call_Of_Generic_Formal (N : Node_Id) return Boolean is
begin
-  return Nkind (N) in N_Function_Call | N_Procedure_Call_Statement
+  return Nkind (N) in N_Subprogram_Call
 
 --  Always return False if debug flag -gnatd.G is set
 

[Ada] Avoid artificial underflow in System.Val_Real

[Pierre-Marie de Rodat]

The final computation now needs to be protected against artificial
underflow when the value is very small.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/s-valrea.adb (Maxexp32): New constant array.
(Maxexp64): Likewise.
(Maxexp80): Likewise.
(Integer_to_Real): New local constants Maxexp and B.
When the exponent is too negative, do the divison in two steps.diff --git a/gcc/ada/libgnat/s-valrea.adb b/gcc/ada/libgnat/s-valrea.adb
--- a/gcc/ada/libgnat/s-valrea.adb
+++ b/gcc/ada/libgnat/s-valrea.adb
@@ -44,6 +44,27 @@ package body System.Val_Real is
 
package Impl is new Value_R (Uns, Precision_Limit, Floating => True);
 
+   subtype Base_T is Unsigned range 2 .. 16;
+
+   --  The following tables compute the maximum exponent of the base that can
+   --  fit in the given floating-point format, that is to say the element at
+   --  index N is the largest K such that N**K <= Num'Last.
+
+   Maxexp32 : constant array (Base_T) of Positive :=
+ (2  => 127, 3 => 80,  4 => 63,  5 => 55,  6 => 49,
+  7  => 45,  8 => 42,  9 => 40, 10 => 38, 11 => 37,
+  12 => 35, 13 => 34, 14 => 33, 15 => 32, 16 => 31);
+
+   Maxexp64 : constant array (Base_T) of Positive :=
+ (2  => 1023, 3 => 646,  4 => 511,  5 => 441,  6 => 396,
+  7  => 364,  8 => 341,  9 => 323, 10 => 308, 11 => 296,
+  12 => 285, 13 => 276, 14 => 268, 15 => 262, 16 => 255);
+
+   Maxexp80 : constant array (Base_T) of Positive :=
+ (2  => 16383, 3 => 10337, 4 => 8191,  5 => 7056,  6 => 6338,
+  7  => 5836,  8 => 5461,  9 => 5168, 10 => 4932, 11 => 4736,
+  12 => 4570, 13 => 4427, 14 => 4303, 15 => 4193, 16 => 4095);
+
function Integer_to_Real
  (Str   : String;
   Val   : Uns;
@@ -69,6 +90,15 @@ package body System.Val_Real is
 
   pragma Unsuppress (Range_Check);
 
+  Maxexp : constant Positive :=
+ (ifNum'Size = 32 then Maxexp32 (Base)
+  elsif Num'Size = 64 then Maxexp64 (Base)
+  elsif Num'Machine_Mantissa = 64 then Maxexp80 (Base)
+  else  raise Program_Error);
+  --  Maximum exponent of the base that can fit in Num
+
+  B : constant Num := Num (Base);
+
   R_Val : Num;
   S : Integer := Scale;
 
@@ -86,16 +116,25 @@ package body System.Val_Real is
 
   R_Val := Num (Val);
   if Extra > 0 then
- R_Val := R_Val * Num (Base) + Num (Extra);
+ R_Val := R_Val * B + Num (Extra);
  S := S - 1;
   end if;
 
-  --  Compute the final value
+  --  Compute the final value. When the exponent is positive, we can do the
+  --  computation directly because, if the exponentiation overflows, then
+  --  the final value overflows as well. But when the exponent is negative,
+  --  we may need to do it in two steps to avoid an artificial underflow.
+
+  if S > 0 then
+ R_Val := R_Val * B ** S;
+
+  elsif S < 0 then
+ if S < -Maxexp then
+R_Val := R_Val / B ** Maxexp;
+S := S + Maxexp;
+ end if;
 
-  if S < 0 then
- R_Val := R_Val / Num (Base) ** (-S);
-  else
- R_Val := R_Val * Num (Base) ** S;
+ R_Val := R_Val / B ** (-S);
   end if;
 
   --  Finally deal with initial minus sign, note that this processing is

[Ada] Refine types of variables for parsing formal object declarations

[Pierre-Marie de Rodat]

Local variables in parsing of formal object declarations take only
positive values, so their types can be narrowed to Pos. Cleanup only;
semantics is unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* par-ch12.adb (P_Formal_Object_Declarations): Refine types to
Pos.diff --git a/gcc/ada/par-ch12.adb b/gcc/ada/par-ch12.adb
--- a/gcc/ada/par-ch12.adb
+++ b/gcc/ada/par-ch12.adb
@@ -423,12 +423,12 @@ package body Ch12 is
 
procedure P_Formal_Object_Declarations (Decls : List_Id) is
   Decl_Node: Node_Id;
-  Ident: Nat;
+  Ident: Pos;
   Not_Null_Present : Boolean := False;
-  Num_Idents   : Nat;
+  Num_Idents   : Pos;
   Scan_State   : Saved_Scan_State;
 
-  Idents : array (Int range 1 .. 4096) of Entity_Id;
+  Idents : array (Pos range 1 .. 4096) of Entity_Id;
   --  This array holds the list of defining identifiers. The upper bound
   --  of 4096 is intended to be essentially infinite, and we do not even
   --  bother to check for it being exceeded.

[Ada] Fix memory leak in GNAT.Expect.Non_Blocking_Spawn on Windows

[Pierre-Marie de Rodat]

It is not leaking on Linux because the memory heap is reinitialized when
the new executable is loaded into the child process after calling fork.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/g-expect.adb (Non_Blocking_Spawn): Deallocate elements
on Arg_List after calling Set_Up_Child_Communications.diff --git a/gcc/ada/libgnat/g-expect.adb b/gcc/ada/libgnat/g-expect.adb
--- a/gcc/ada/libgnat/g-expect.adb
+++ b/gcc/ada/libgnat/g-expect.adb
@@ -1181,6 +1181,12 @@ package body GNAT.Expect is
  Set_Up_Child_Communications
(Descriptor, Pipe1, Pipe2, Pipe3, Command_With_Path.all,
 C_Arg_List'Address);
+
+ --  On Windows systems we need to release memory taken for Arg_List
+
+ for A of Arg_List loop
+Free (A);
+ end loop;
   end if;
 
   Free (Command_With_Path);

[Ada] Remove inconsistent colons in messages for Ada 83 violations

[Pierre-Marie de Rodat]

Most of the errors of the form "(Ada 83) ..." don't have a colon; fix
inconsistencies.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* par-ch3.adb (P_Modular_Type_Definition): Remove colon from
error message.
* sem_ch11.adb (Check_Duplication): Likewise.
* sem_ch3.adb (Derived_Type_Declaration): Likewise.diff --git a/gcc/ada/par-ch3.adb b/gcc/ada/par-ch3.adb
--- a/gcc/ada/par-ch3.adb
+++ b/gcc/ada/par-ch3.adb
@@ -2430,7 +2430,7 @@ package body Ch3 is
 
begin
   if Ada_Version = Ada_83 then
- Error_Msg_SC ("(Ada 83): modular types not allowed");
+ Error_Msg_SC ("(Ada 83) modular types not allowed");
   end if;
 
   Typedef_Node := New_Node (N_Modular_Type_Definition, Token_Ptr);


diff --git a/gcc/ada/sem_ch11.adb b/gcc/ada/sem_ch11.adb
--- a/gcc/ada/sem_ch11.adb
+++ b/gcc/ada/sem_ch11.adb
@@ -127,7 +127,7 @@ package body Sem_Ch11 is
and then Comes_From_Source (Id)
  then
 Error_Msg_N
-  ("(Ada 83): duplicate exception choice&", Id);
+  ("(Ada 83) duplicate exception choice&", Id);
  end if;
   end if;
end if;


diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -16943,7 +16943,7 @@ package body Sem_Ch3 is
   then
  if Ada_Version = Ada_83 and then Comes_From_Source (Indic) then
 Error_Msg_N
-  ("(Ada 83): premature use of type for derivation", Indic);
+  ("(Ada 83) premature use of type for derivation", Indic);
  end if;
   end if;
 

[Ada] Fix typo in checks for implementation defined units

[Pierre-Marie de Rodat]

Fix mismatch in iterating over a range for Ada 2012 and referencing an
array for Ada 95. This didn't affect the behaviour, because the
referenced boolean flags in both arrays were the same for the iterated
subrange.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* impunit.adb (Not_Impl_Defined_Unit): Fix typo in iteration
over Non_Imp_File_Names_12 array.diff --git a/gcc/ada/impunit.adb b/gcc/ada/impunit.adb
--- a/gcc/ada/impunit.adb
+++ b/gcc/ada/impunit.adb
@@ -999,7 +999,7 @@ package body Impunit is
 
   for J in Non_Imp_File_Names_12'Range loop
  if Name_Buffer (1 .. 8) = Non_Imp_File_Names_12 (J).Fname then
-return Non_Imp_File_Names_95 (J).RMdef
+return Non_Imp_File_Names_12 (J).RMdef
   and then Ada_Version >= Ada_2012;
  end if;
   end loop;

[Ada] Simplify membership tests with N_Delay_Statement subtype

[Pierre-Marie de Rodat]

Simplify membership test on N_Delay_Relative_Statement and
N_Delay_Until_Statement using the collective N_Delay_Statement subtype.
Cleanup only; semantics is unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_ch9.adb, sem_warn.adb: Simplify membership test.diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb
--- a/gcc/ada/exp_ch9.adb
+++ b/gcc/ada/exp_ch9.adb
@@ -7161,8 +7161,7 @@ package body Exp_Ch9 is
  if Ada_Version >= Ada_2005
and then
  (No (Original_Node (Ecall))
-   or else Nkind (Original_Node (Ecall)) not in
- N_Delay_Relative_Statement | N_Delay_Until_Statement)
+   or else Nkind (Original_Node (Ecall)) not in N_Delay_Statement)
  then
 Extract_Dispatching_Call (Ecall, Call_Ent, Obj, Actuals, Formals);
 


diff --git a/gcc/ada/sem_warn.adb b/gcc/ada/sem_warn.adb
--- a/gcc/ada/sem_warn.adb
+++ b/gcc/ada/sem_warn.adb
@@ -750,9 +750,7 @@ package body Sem_Warn is
  Fstm : constant Node_Id :=
   Original_Node (First (Statements (Loop_Statement)));
   begin
- if Nkind (Fstm) = N_Delay_Relative_Statement
-   or else Nkind (Fstm) = N_Delay_Until_Statement
- then
+ if Nkind (Fstm) in N_Delay_Statement then
 return;
  end if;
   end;

[Ada] Code cleanup: rename ALI.Scope

[Pierre-Marie de Rodat]

Rename it to IS_Scope so that calling scope (node) under gdb is
unambiguous, so ease debugging sessions.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* ali.ads, ali.adb, bindo-writers.adb, lib-writ.adb (Scope):
Renamed to IS_Scope.diff --git a/gcc/ada/ali.adb b/gcc/ada/ali.adb
--- a/gcc/ada/ali.adb
+++ b/gcc/ada/ali.adb
@@ -3814,15 +3814,15 @@ package body ALI is
  return No_ALI_Id;
end Scan_ALI;
 
-   ---
-   -- Scope --
-   ---
+   --
+   -- IS_Scope --
+   --
 
-   function Scope (IS_Id : Invocation_Signature_Id) return Name_Id is
+   function IS_Scope (IS_Id : Invocation_Signature_Id) return Name_Id is
begin
   pragma Assert (Present (IS_Id));
   return Invocation_Signatures.Table (IS_Id).Scope;
-   end Scope;
+   end IS_Scope;
 
-
-- SEq --


diff --git a/gcc/ada/ali.ads b/gcc/ada/ali.ads
--- a/gcc/ada/ali.ads
+++ b/gcc/ada/ali.ads
@@ -1350,8 +1350,8 @@ package ALI is
pragma Inline (Name);
--  Obtain the name of invocation signature IS_Id
 
-   function Scope (IS_Id : Invocation_Signature_Id) return Name_Id;
-   pragma Inline (Scope);
+   function IS_Scope (IS_Id : Invocation_Signature_Id) return Name_Id;
+   pragma Inline (IS_Scope);
--  Obtain the scope of invocation signature IS_Id
 
procedure Set_Invocation_Graph_Encoding


diff --git a/gcc/ada/bindo-writers.adb b/gcc/ada/bindo-writers.adb
--- a/gcc/ada/bindo-writers.adb
+++ b/gcc/ada/bindo-writers.adb
@@ -222,7 +222,7 @@ package body Bindo.Writers is
  Write_Eol;
 
  Write_Str  ("  Scope = ");
- Write_Name (Scope (IS_Id));
+ Write_Name (IS_Scope (IS_Id));
  Write_Eol;
   end Write_Invocation_Signature;
 


diff --git a/gcc/ada/lib-writ.adb b/gcc/ada/lib-writ.adb
--- a/gcc/ada/lib-writ.adb
+++ b/gcc/ada/lib-writ.adb
@@ -1724,7 +1724,7 @@ package body Lib.Writ is
 
   --  scope
 
-  Write_Info_Name (Scope (IS_Id));
+  Write_Info_Name (IS_Scope (IS_Id));
   Write_Info_Char (' ');
 
   --  line

[Ada] Add contracts to Ada.Strings.Fixed

[Pierre-Marie de Rodat]

This adds complete postconditions and contract cases to subprograms in
Ada.Strings.Fixed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-strfix.ads: Add postconditions and contract cases to
subprograms.

patch.diff.gz
Description: application/gzip

[Ada] Handle iterator filters on loop specifications over containers

[Pierre-Marie de Rodat]

A loop parameter specification over a container is rewrtten as an
iterator specification, so that expansion can use the Iterator
opwrations declared for the container type. If an Ada2020 interator
filter appears on the loop_parameter_specification it must be transfered
to the iterator, and preanalyzed for semantic correctness. Expansion of
the filter must be deferred to expansion of the enclosing loop, to
prevent premature references to the loop parameter outside of its scope.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch5.adb (Analyze_Iterator_Specification): If iterator
filter is present, preanalyze filter without expansion.
(Analyze_Loop_Parameter_Specification): When
loop_Parameter_Specification is rewritten as
Iterator_Specification, transfer Iterator_Filter if present.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -2620,7 +2620,10 @@ package body Sem_Ch5 is
   end if;
 
   if Present (Iterator_Filter (N)) then
- Analyze_And_Resolve (Iterator_Filter (N), Standard_Boolean);
+ --  Preanalyze the filter. Expansion will take place when enclosing
+ --  loop is expanded.
+
+ Preanalyze_And_Resolve (Iterator_Filter (N), Standard_Boolean);
   end if;
end Analyze_Iterator_Specification;
 
@@ -3017,6 +3020,9 @@ package body Sem_Ch5 is
 begin
Set_Iterator_Specification (Scheme, I_Spec);
Set_Loop_Parameter_Specification (Scheme, Empty);
+   Set_Iterator_Filter (I_Spec,
+ Relocate_Node (Iterator_Filter (N)));
+
Analyze_Iterator_Specification (I_Spec);
 
--  In a generic context, analyze the original domain of

[Ada] armhf-linux: symbolic tracebacks

[Pierre-Marie de Rodat]

Implement symbolic tracebacks on armhf-linux.  It's an ELF target so
just a matter of some bookkeeping changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/s-objrea.ads (Object_Arch): Add ARM enum
* libgnat/s-objrea.adb (Initialize): Add EM_ARM case.
(Read_Address): Add ARM case to 32bit read.
* Makefile.rtl: Add trasym units to the runtime for armhf-linux.diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
--- a/gcc/ada/Makefile.rtl
+++ b/gcc/ada/Makefile.rtl
@@ -2381,12 +2381,14 @@ ifeq ($(strip $(filter-out arm% linux-gnueabi%,$(target_cpu) $(target_os))),)
   s-tasinf.adb
Res.Arch := x86_64;
 
+when EM_ARM =>
+   Res.Arch := ARM;
+
 when others =>
raise Format_Error with "unrecognized architecture";
  end case;
@@ -2030,6 +2033,7 @@ package body System.Object_Reader is
 | MIPS
 | PPC
 | SPARC
+| ARM
  =>
 Address_32 := Read (S);
 return uint64 (Address_32);


diff --git a/gcc/ada/libgnat/s-objrea.ads b/gcc/ada/libgnat/s-objrea.ads
--- a/gcc/ada/libgnat/s-objrea.ads
+++ b/gcc/ada/libgnat/s-objrea.ads
@@ -117,9 +117,12 @@ package System.Object_Reader is
   PPC,
   --  32-bit PowerPC
 
-  PPC64);
+  PPC64,
   --  64-bit PowerPC
 
+  ARM);
+  --  32-bit ARM
+
--
-- Target types --
--

Re: [x86] recompute opt flags after opt level change

[Martin Liška]

On 10/1/19 10:58 AM, Alexandre Oliva wrote:

+  if (opts->x_flag_asynchronous_unwind_tables == 2)
+   opts->x_flag_unwind_tables
+ = opts->x_flag_asynchronous_unwind_tables = 1;


Hello.

Spotted that when I tried to make x_flag_asynchronous_unwind_tables a boolean 
flag.

Anyway the code seems fishy, shouldn't it be:

  if (opts->x_flag_asynchronous_unwind_tables == 2)
opts->x_flag_unwind_tables
  = opts->x_flag_asynchronous_unwind_tables == 1; < '==' instead of 
'='

Thanks,
Martin

c++tools: Fix (an) install issue

[Nathan Sidwell]

David reported an AIX problem, which I think this addresses.  I've not 
looked at pr98314 yet but there's certainly overlap


This fixes installers that don't understand -p.

c++tools/
(install): Do not use -p, use mkinstalldirs.
(clean): Fix typo.

pushing to trunk
--
Nathan Sidwell
diff --git i/c++tools/Makefile.in w/c++tools/Makefile.in
index 49b7fae1526..4ec1419fa5b 100644
--- i/c++tools/Makefile.in
+++ w/c++tools/Makefile.in
@@ -38,7 +38,7 @@ mostlyclean::
 	rm -f $(MAPPER.O)
 
 clean::
-	rm -f c++-mapper-server$(exeext)
+	rm -f g++-mapper-server$(exeext)
 
 distclean::
 	rm -f config.log config.status config.h
@@ -86,10 +86,11 @@ g++-mapper-server$(exeext): $(MAPPER.O) $(CODYLIB)
 all::../gcc/g++-mapper-server$(exeext)
 
 ../gcc/g++-mapper-server$(exeext): g++-mapper-server$(exeext)
-	$(INSTALL) -p $< $@
+	$(INSTALL) $< $@
 
 install::
-	$(INSTALL) -p g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
+	$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(libexecsubdir)
+	$(INSTALL) g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
 
 endif
 

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Pierre-Marie de Rodat]

On Wed, Dec 16, 2020 at 1:18 PM Pierre-Marie de Rodat
 wrote:
> Thank you. I can reproduce the issue: at this point I suspect that my
> testing hasn’t detected this because of some inconsistency with my
> incremental builds. The actual correction is a few patches later in my
> porting queue: I’m about to commit it. Sorry for the trouble!

The fix is now in master
(https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cbe22e189a355f19eb1344fcaf91bc2bb0b95f36),
so the bootstrap for Ada should now be fixed. I’ll update the PR:
should I wait for confirmation before moving it to RESOLVED?

-- 
Pierre-Marie de Rodat 

Re: [Ada] Fix serial port baud rate setting on GNU/Linux

[Rainer Orth]

Hi Pierre-Marie,

> On Wed, Dec 16, 2020 at 1:18 PM Pierre-Marie de Rodat
>  wrote:
>> Thank you. I can reproduce the issue: at this point I suspect that my
>> testing hasn’t detected this because of some inconsistency with my
>> incremental builds. The actual correction is a few patches later in my
>> porting queue: I’m about to commit it. Sorry for the trouble!
>
> The fix is now in master
> (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cbe22e189a355f19eb1344fcaf91bc2bb0b95f36),
> so the bootstrap for Ada should now be fixed. I’ll update the PR:
> should I wait for confirmation before moving it to RESOLVED?

The ICANON part matches almost exactly what I used to restore
Linux/x86_64 bootstrap.  I'd suggest you close the PR: in case there are
unexpected problems, it can always be reopened.

Thanks.
Rainer

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

[PATCH] doc: Document that libstdc++ uses __STRICT_ANSI__

[Jonathan Wakely via Gcc-patches]

Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
whether or not std::is_integral<__int128> should be true.

gcc/ChangeLog:

* doc/cpp.texi (Common Predefined Macros): Mention that
__STRICT_ANSI__ is used by libstdc++ too.

OK for trunk?

I'd also like to tell users they're not allowed to undefine the
macro, would that be acceptable, or is that supposed to work?

I don't see how it's possible to make it work with libstdc++ if users
do stupid things like:

#include 
#undef __STRICT_ANSI__
#include 

This causes the library to be in an inconsistent (broken) state,
because some templates are defined according to strict ISO C++ rules
and then other templates are not, but assume the earlier definitions
are consistent.

We frequently see users doing -std=c++11 -U__STRICT_ANSI__ which makes
me smash my head on the table. Just use -std=gnu++11 and stop being
dumb.


commit c516abe37ef82444e125b32933ea44a00a99d1ec
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:21:24 2020

doc: Document that libstdc++ uses __STRICT_ANSI__

Libstdc++ has been using __STRICT_ANSI__ for years, e.g. to decide
whether or not std::is_integral<__int128> should be true.

gcc/ChangeLog:

* doc/cpp.texi (Common Predefined Macros): Mention that
__STRICT_ANSI__ is used by libstdc++ too.

diff --git a/gcc/doc/cpp.texi b/gcc/doc/cpp.texi
index 5dcd67259e3..c5cdd5cb069 100644
--- a/gcc/doc/cpp.texi
+++ b/gcc/doc/cpp.texi
@@ -1996,8 +1996,8 @@ testing @code{@w{(__GNUC__ && __cplusplus)}}.
 GCC defines this macro if and only if the @option{-ansi} switch, or a
 @option{-std} switch specifying strict conformance to some version of ISO C
 or ISO C++, was specified when GCC was invoked.  It is defined to @samp{1}.
-This macro exists primarily to direct GNU libc's header files to use only
-definitions found in standard C.
+This macro exists primarily to direct libstdc++ and GNU libc's header files
+to use only definitions found in standard C and C++.
 
 @item __BASE_FILE__
 This macro expands to the name of the main input file, in the form

Re: [PATCH] genemit: Handle `const_double_zero' rtx

[Maciej W. Rozycki]

On Wed, 16 Dec 2020, Richard Sandiford wrote:

> >> Presumably you can't use CONST0_RTX (mode) here?  Assuming that's the
> >> case, then this is fine.
> >
> >  Well, `mode' is VOID for simplicity and to match what the middle end 
> > presents as an operand to the COMPARE operation, as also shown with the 
> > diff above, so with CONST0_RTX (mode) we'd be back to what amounts to 
> > `const0_rtx' aka `const_int 0', which is exactly what we want to get away 
> > from.
> >
> >  Alternatively we could possibly give `const_double_zero' a proper FP 
> > mode, but it seems to me like an unnecessary complication, as it would 
> > then have to be individually requested and iterated over all the relevant 
> > modes.
> 
> Generated FP const_double rtxes have to have a proper (non-VOID) mode
> though.  VOIDmode CONST_DOUBLEs are always (legacy) integers instead
> of FP values.
> 
> So yeah, giving const_double_zero a proper mode seems like the way to go.
> It's technically possible to drop it in a pure matching context, but I'm
> not sure how valuable that is in practice, given that other parts of the
> matched pattern would usually need to refer to the same mode anyway.

 Fair enough.  For some reason however VOIDmode CONST_DOUBLEs seem to work 
with the FP operations in the VAX backend for the purpose of post-reload 
comparison elimination while CONST_INTs do not.

> >  Have I missed anything here?
> >
> >  NB the PDP-11 pieces affected here and tripping this assertion are I 
> > believe dead code, as these insns are only ever produced by splitters and 
> > do not appear to be referred by their names.  We need this change however 
> > for completeness so that `const_double_zero' can be used in contexts where 
> > an insn actually will be referred by its name.
> >
> >  However the PDP-11 code being dead makes it a bit more difficult to 
> > examine actual consequences of such a change like I have proposed than it 
> > would otherwise be.  In these circumstances I think my proposal is safe if 
> > a bit overly cautious.
> 
> CONST_DOUBLE_ATOF ("0", VOIDmode) seems malformed though, and I'd expect
> it to assert in REAL_MODE_FORMAT (via the format_helper constructor).
> I'm not sure the patch is strictly safer than the status quo.

 I may have missed that, though I did follow the chain of calls involved 
here to see if there is anything problematic.  As I say I have a limited 
way to verify this in practice as the PDP-11 code involved appears to me 
to be dead, and the situation does not apply to the VAX backend.  Maybe I 
could simulate it somehow artificially to see what happens.

> FWIW, I agree with Jeff that this ought to be CONST0_RTX (mode).

 I'll have to update several places then and push the changes through full 
regression testing, so it'll probably take until the next week.

 Thanks for your input!

  Maciej

Re: [x86] recompute opt flags after opt level change

[Uros Bizjak via Gcc-patches]

On Wed, Dec 16, 2020 at 2:18 PM Martin Liška  wrote:
>
> On 10/1/19 10:58 AM, Alexandre Oliva wrote:
> > +  if (opts->x_flag_asynchronous_unwind_tables == 2)
> > + opts->x_flag_unwind_tables
> > +   = opts->x_flag_asynchronous_unwind_tables = 1;
>
> Hello.
>
> Spotted that when I tried to make x_flag_asynchronous_unwind_tables a boolean 
> flag.
>
> Anyway the code seems fishy, shouldn't it be:
>
>if (opts->x_flag_asynchronous_unwind_tables == 2)
> opts->x_flag_unwind_tables
>   = opts->x_flag_asynchronous_unwind_tables == 1; < '==' instead 
> of '='

It should be OK. Please note that

opts->x_flag_asynchronous_unwind_tables == 1

will never be true due to preceding condition.

Uros.
>
> Thanks,
> Martin

[PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Jakub Jelinek via Gcc-patches]

Hi!

As mentioned in the PR, shrink-wrapping disqualifies for prologue
placement basic blocks that have EDGE_CROSSING incoming edge.
I don't see why that is necessary, those edges seem to be redirected
just fine, both on x86_64 and powerpc64.  In the former case, they
are usually conditional jumps that patch_jump_insn can handle just fine,
after all, they were previously crossing and will be crossing after
the redirection too, just to a different label.  And in the powerpc64
case, it is a simple_jump instead that again seems to be handled by
patch_jump_insn just fine.
Sure, redirecting an edge that was previously not crossing to be crossing or
vice versa can fail, but that is not what shrink-wrapping needs.
Also tested in GCC 8 with this patch and don't see ICEs there either
(though, of course, I'm not suggesting we should backport this to release
branches).

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

2020-12-16  Jakub Jelinek  

PR rtl-optimization/98289
* shrink-wrap.c (can_get_prologue): Don't punt on EDGE_CROSSING
incoming edges.

* gcc.target/i386/pr98289.c: New test.
* gcc.dg/torture/pr98289.c: New test.

--- gcc/shrink-wrap.c.jj2020-07-28 15:39:09.983756571 +0200
+++ gcc/shrink-wrap.c   2020-12-15 19:15:00.213861334 +0100
@@ -494,7 +494,7 @@ can_get_prologue (basic_block pro, HARD_
   edge e;
   edge_iterator ei;
   FOR_EACH_EDGE (e, ei, pro->preds)
-if (e->flags & (EDGE_COMPLEX | EDGE_CROSSING)
+if (e->flags & EDGE_COMPLEX
&& !dominated_by_p (CDI_DOMINATORS, e->src, pro))
   return false;
 
--- gcc/testsuite/gcc.target/i386/pr98289.c.jj  2020-12-16 13:15:08.579847596 
+0100
+++ gcc/testsuite/gcc.target/i386/pr98289.c 2020-12-16 14:26:16.863157527 
+0100
@@ -0,0 +1,54 @@
+/* PR rtl-optimization/98289 */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-require-effective-target freorder } */
+/* { dg-options "-O2 -freorder-blocks-and-partition 
-fdump-rtl-pro_and_epilogue-details" } */
+/* { dg-final { scan-rtl-dump-times "Performing shrink-wrapping" 4 
"pro_and_epilogue" } } */
+
+int bar (void) __attribute__((cold));
+
+void
+foo (int x)
+{
+  if (x)
+__builtin_abort ();
+}
+
+void
+baz (int x)
+{
+  if (__builtin_expect (x, 0))
+{
+  bar ();
+  bar ();
+  bar ();
+}
+}
+
+void
+qux (int x, int y, int z, int w)
+{
+  if (x || y || z || w)
+__builtin_abort ();
+}
+
+int
+corge (int x, int y, int z, int w, int u)
+{
+  if (__builtin_expect (x, 0))
+goto lab;
+  u++;
+  if (__builtin_expect (y, 0))
+goto lab;
+  u *= 2;
+  if (__builtin_expect (z, 0))
+goto lab;
+  u |= 42;
+  if (__builtin_expect (w, 0))
+{
+  lab:;
+  bar ();
+  bar ();
+  if (bar () > 32) goto lab;
+}
+  return u;
+}
--- gcc/testsuite/gcc.dg/torture/pr98289.c.jj   2020-12-16 14:27:01.391659297 
+0100
+++ gcc/testsuite/gcc.dg/torture/pr98289.c  2020-12-16 14:27:29.442345443 
+0100
@@ -0,0 +1,52 @@
+/* PR rtl-optimization/98289 */
+/* { dg-do compile { target freorder } } */
+/* { dg-options "-O2 -freorder-blocks-and-partition" } */
+
+int bar (void) __attribute__((cold));
+
+void
+foo (int x)
+{
+  if (x)
+__builtin_abort ();
+}
+
+void
+baz (int x)
+{
+  if (__builtin_expect (x, 0))
+{
+  bar ();
+  bar ();
+  bar ();
+}
+}
+
+void
+qux (int x, int y, int z, int w)
+{
+  if (x || y || z || w)
+__builtin_abort ();
+}
+
+int
+corge (int x, int y, int z, int w, int u)
+{
+  if (__builtin_expect (x, 0))
+goto lab;
+  u++;
+  if (__builtin_expect (y, 0))
+goto lab;
+  u *= 2;
+  if (__builtin_expect (z, 0))
+goto lab;
+  u |= 42;
+  if (__builtin_expect (w, 0))
+{
+  lab:;
+  bar ();
+  bar ();
+  if (bar () > 32) goto lab;
+}
+  return u;
+}

Jakub

Re: [PATCH] varasm: Fix up __patchable_function_entries handling

[H.J. Lu via Gcc-patches]

On Wed, Dec 16, 2020 at 5:05 AM Jakub Jelinek  wrote:
>
> On Wed, Dec 02, 2020 at 05:15:21AM -0800, H.J. Lu via Gcc-patches wrote:
> > gcc/
> >
> >   PR middle-end/93195
> >   PR middle-end/93197
> >   * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define 1 if
> >   the assembler supports the section flag 'o' for specifying
> >   section with link-order.
> >   * output.h (SECTION_LINK_ORDER): New.  Defined to 0x800.
> >   (SECTION_MACH_DEP): Changed from 0x800 to 0x1000.
> >   * targhooks.c (default_print_patchable_function_entry): Pass
> >   SECTION_LINK_ORDER to switch_to_section if the section flag 'o'
> >   works.  Pass current_function_decl to switch_to_section.
> >   * varasm.c (default_elf_asm_named_section): Use 'o' flag for
> >   SECTION_LINK_ORDER if assembler supports it.
> >   * config.in: Regenerated.
> >   * configure: Likewise.
>
> Dunno if it is an assembler bug or gcc bug, but this SECTION_LINK_ORDER
> stuff doesn't seem to work properly.
>
> If I compile:
> static inline __attribute__((__gnu_inline__)) __attribute__((__unused__)) 
> __attribute__((patchable_function_entry(0, 0))) int foo (int x)
> {
>   return x + 1;
> }
>
> static inline __attribute__((__gnu_inline__)) __attribute__((__unused__)) 
> __attribute__((patchable_function_entry(0, 0))) int bar (int x)
> {
>   return x + 2;
> }
>
> int
> baz (int x)
> {
>   return foo (x) + 1;
> }
>
> int
> qux (int x)
> {
>   return bar (x) + 2;
> }
> (distilled from aarch64 Linux kernel) with
> -O2 -fpatchable-function-entry=2 on aarch64 compiler configured against
> latest binutils, I get:
> ...
> .section__patchable_function_entries,"awo",@progbits,baz
> ...
> .section__patchable_function_entries
> ...
> in the assembly, but when it is assembled, one gets:
>   [ 4] __patchable_function_entries PROGBITS 60 
> 08 00 WAL  1   0  8
>   [ 5] .rela__patchable_function_entries RELA 
> 000280 18 18   I 12   4  8
>   [ 6] __patchable_function_entries PROGBITS 68 
> 08 00  0   0  8
>   [ 7] .rela__patchable_function_entries RELA 
> 000298 18 18   I 12   6  8
> i.e. one writable allocated section with SHF_LINK_ORDER and another
> non-allocated non-writable without link order.  In the kernel case there is
> always one entry in the WAL section and then dozens or more in the
> non-allocated one.
> The kernel then fails to link:
> WARNING: modpost: vmlinux.o (__patchable_function_entries): unexpected 
> non-allocatable section.
> Did you forget to use "ax"/"aw" in a .S file?
> Note that for example  contains
> section definitions for use in .S files.
> ld: .init.data has both ordered [`__patchable_function_entries' in 
> init/main.o] and unordered [`.init.data' in 
> ./drivers/firmware/efi/libstub/vsprintf.stub.o] sections
> ld: final link failed: bad value
> make: *** [Makefile:1175: vmlinux] Error 1
>
> If it is correct that the assembler requires full section flags for the
> SECTION_LINK_ORDER .section directives in every case (like it does for

gas is correct.

> comdat or for retain), then we should do something like the following
> untested change, but if it is gas bug, it should be fixed there.
>
> 2020-12-15  Jakub Jelinek  
>
> * varasm.c (default_elf_asm_named_section): Always force
> section flags even for sections with SECTION_LINK_ORDER flag.
>
> --- gcc/varasm.c.jj 2020-12-13 17:07:53.910477664 +0100
> +++ gcc/varasm.c2020-12-15 21:33:35.169314414 +0100
> @@ -6781,10 +6781,10 @@ default_elf_asm_named_section (const cha
>
>/* If we have already declared this section, we can use an
>   abbreviated form to switch back to it -- unless this section is
> - part of a COMDAT groups or with SHF_GNU_RETAIN, in which case GAS
> - requires the full declaration every time.  */
> + part of a COMDAT groups or with SHF_GNU_RETAIN or with SHF_LINK_ORDER,
> + in which case GAS requires the full declaration every time.  */
>if (!(HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
> -  && !(flags & SECTION_RETAIN)
> +  && !(flags & (SECTION_RETAIN | SECTION_LINK_ORDER))
>&& (flags & SECTION_DECLARED))
>  {
>fprintf (asm_out_file, "\t.section\t%s\n", name);
>
>
> Jakub
>

LGTM.  But I can't approve it.

Thanks.

--
H.J.

[committed] libstdc++: Add performance test for atomic_flag [PR 46447]

[Jonathan Wakely via Gcc-patches]

This adds a test to compare the performance of std::atomic_flag with
similar operations on std::atomic_uchar and std::atomic_int.

libstdc++-v3/ChangeLog:

PR libstdc++/46447
* testsuite/performance/29_atomics/atomic_flag.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

commit 3cee0c6562e5d8df69a9d6ad613a6f3edcfcc797
Author: Jonathan Wakely 
Date:   Wed Dec 16 11:51:42 2020

libstdc++: Add performance test for atomic_flag [PR 46447]

This adds a test to compare the performance of std::atomic_flag with
similar operations on std::atomic_uchar and std::atomic_int.

libstdc++-v3/ChangeLog:

PR libstdc++/46447
* testsuite/performance/29_atomics/atomic_flag.cc: New test.

diff --git a/libstdc++-v3/testsuite/performance/29_atomics/atomic_flag.cc 
b/libstdc++-v3/testsuite/performance/29_atomics/atomic_flag.cc
new file mode 100644
index 000..af1a269a0e0
--- /dev/null
+++ b/libstdc++-v3/testsuite/performance/29_atomics/atomic_flag.cc
@@ -0,0 +1,71 @@
+// Copyright (C) 2009-2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+
+#include 
+#include 
+
+volatile std::atomic_flag af;
+volatile std::atomic_uchar ac;
+volatile std::atomic_int ai;
+
+int main()
+{
+  using namespace __gnu_test;
+  time_counter time;
+  resource_counter resource;
+
+  const int n = 1;
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+af.test_and_set();
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_flag::test_and_set()", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+af.clear();
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_flag::clear()", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ac |= 1;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_uchar::operator|=(1)", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ac = 0;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_flag::operator=(0)", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ai |= 1;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_int::operator|=(1)", time, resource);
+
+  start_counters(time, resource);
+  for (int i = 0; i < n; ++i)
+ai = 0;
+  stop_counters(time, resource);
+  report_performance(__FILE__, "atomic_int::operator=(0)", time, resource);
+
+  return 0;
+}

[committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]

[Jonathan Wakely via Gcc-patches]

This fixes a bug caused by a mismatch between the macros defined by
 when GCC is built and the macros defined by  when
users include . If the user code is compiled with
_XOPEN_SOURCE defined to 500 or 600, Darwin suppresses the
ENOTRECOVERABLE and EOWNERDEAD macros, which are not defined by SUSv3
(aka POSIX.1-2001).

Since POSIX requires the errno macros to be macros (and not variables or
enumerators) we can just test for them directly using the preprocessor.
That means that  will match what is actuallydefined when
it's included, not what was defined when GCC was built. With that change
there is no need for the GLIBCXX_CHECK_SYSTEM_ERROR configure checks and
they can be removed.

libstdc++-v3/ChangeLog:

PR libstdc++/93151
* acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove.
* configure.ac: Regenerate.
* config/os/generic/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Likewise.
* testsuite/19_diagnostics/headers/system_error/93151.cc: New
test.

Tested powerpc64le-linux. Committed to trunk.

commit a2c2eec183acf25c9b214fa0827718e4d2fdfc93
Author: Jonathan Wakely 
Date:   Tue Dec 15 20:28:11 2020

libstdc++: Test errno macros directly, not via autoconf [PR 93151]

This fixes a bug caused by a mismatch between the macros defined by
 when GCC is built and the macros defined by  when
users include . If the user code is compiled with
_XOPEN_SOURCE defined to 500 or 600, Darwin suppresses the
ENOTRECOVERABLE and EOWNERDEAD macros, which are not defined by SUSv3
(aka POSIX.1-2001).

Since POSIX requires the errno macros to be macros (and not variables or
enumerators) we can just test for them directly using the preprocessor.
That means that  will match what is actuallydefined when
it's included, not what was defined when GCC was built. With that change
there is no need for the GLIBCXX_CHECK_SYSTEM_ERROR configure checks and
they can be removed.

libstdc++-v3/ChangeLog:

PR libstdc++/93151
* acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove.
* configure.ac: Regenerate.
* config/os/generic/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Likewise.
* testsuite/19_diagnostics/headers/system_error/93151.cc: New
test.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index df8be3bf805..e4175ea3e64 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2372,35 +2372,6 @@ AC_DEFUN([GLIBCXX_CHECK_MATH11_PROTO], [
   AC_LANG_RESTORE
 ])
 
-dnl
-dnl Check whether macros, etc are present for 
-dnl
-AC_DEFUN([GLIBCXX_CHECK_SYSTEM_ERROR], [
-
-m4_pushdef([n_syserr], [1])dnl
-m4_foreach([syserr], [EOWNERDEAD, ENOTRECOVERABLE, ENOLINK, EPROTO, ENODATA,
- ENOSR, ENOSTR, ETIME, EBADMSG, ECANCELED,
- EOVERFLOW, ENOTSUP, EIDRM, ETXTBSY,
- ECHILD, ENOSPC, EPERM,
- ETIMEDOUT, EWOULDBLOCK],
-[m4_pushdef([SYSERR], m4_toupper(syserr))dnl
-AC_MSG_CHECKING([for syserr])
-AC_CACHE_VAL([glibcxx_cv_system_error[]n_syserr], [
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include ]],
-  [int i = syserr;])],
- [glibcxx_cv_system_error[]n_syserr=yes],
- [glibcxx_cv_system_error[]n_syserr=no])
-])
-AC_MSG_RESULT([$glibcxx_cv_system_error[]n_syserr])
-if test x"$glibcxx_cv_system_error[]n_syserr" = x"yes"; then
-  AC_DEFINE([HAVE_]SYSERR, 1, [Define if ]syserr[ exists.])
-fi
-m4_define([n_syserr], m4_incr(n_syserr))dnl
-m4_popdef([SYSERR])dnl
-])
-m4_popdef([n_syserr])dnl
-])
-
 dnl
 dnl Check for what type of C headers to use.
 dnl
diff --git a/libstdc++-v3/config/os/generic/error_constants.h 
b/libstdc++-v3/config/os/generic/error_constants.h
index b5b0ea6b9ad..0d34f7179b6 100644
--- a/libstdc++-v3/config/os/generic/error_constants.h
+++ b/libstdc++-v3/config/os/generic/error_constants.h
@@ -48,7 +48,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   bad_address =EFAULT,
   bad_file_descriptor =EBADF,
 
-#ifdef _GLIBCXX_HAVE_EBADMSG
+#ifdef EBADMSG
   bad_message =EBADMSG,
 #endif
 
@@ -68,7 +68,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   function_not_supported = ENOSYS,
   host_unreachable =   EHOSTUNREACH,
 
-#ifdef _GLIBCXX_HAVE_EIDRM
+#ifdef EIDRM
   identifier_removed = EIDRM,
 #endif
 
@@ -86,13 +86,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   no_buffer_space =ENOBUFS,
   no_child_process =

[committed] libstdc++: Fix errors from Library Fundamentals TS headers in C++11 [PR 98319]

[Jonathan Wakely via Gcc-patches]

Currently the ,  and
 headers can be included in C++98 and C++11 modes,
but gives errors. With this change they can be included, but define
nothing.

libstdc++-v3/ChangeLog:

PR libstdc++/98319
* include/experimental/random: Only define contents for C++14
and later.
* include/experimental/source_location: Likewise.
* include/experimental/utility: Likewise.
* testsuite/experimental/feat-lib-fund.cc: Include all LFTS
headers that are present. Allow test to run for all modes.

Tested powerpc64le-linux. Committed to trunk.

commit ab9bd93271061f436c10e35e261ecb73e2108ccc
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:37:17 2020

libstdc++: Fix errors from Library Fundamentals TS headers in C++11 [PR 
98319]

Currently the ,  and
 headers can be included in C++98 and C++11 modes,
but gives errors. With this change they can be included, but define
nothing.

libstdc++-v3/ChangeLog:

PR libstdc++/98319
* include/experimental/random: Only define contents for C++14
and later.
* include/experimental/source_location: Likewise.
* include/experimental/utility: Likewise.
* testsuite/experimental/feat-lib-fund.cc: Include all LFTS
headers that are present. Allow test to run for all modes.

diff --git a/libstdc++-v3/include/experimental/random 
b/libstdc++-v3/include/experimental/random
index 2ec1a4b7e42..4165a8520c8 100644
--- a/libstdc++-v3/include/experimental/random
+++ b/libstdc++-v3/include/experimental/random
@@ -30,6 +30,7 @@
 #ifndef _GLIBCXX_EXPERIMENTAL_RANDOM
 #define _GLIBCXX_EXPERIMENTAL_RANDOM 1
 
+#if __cplusplus >= 201402L
 #include 
 #include 
 
@@ -78,4 +79,5 @@ inline namespace fundamentals_v2 {
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
-#endif
+#endif // C++14
+#endif // _GLIBCXX_EXPERIMENTAL_RANDOM
diff --git a/libstdc++-v3/include/experimental/source_location 
b/libstdc++-v3/include/experimental/source_location
index 9d5b5eae5f3..b4f00f1c039 100644
--- a/libstdc++-v3/include/experimental/source_location
+++ b/libstdc++-v3/include/experimental/source_location
@@ -30,6 +30,7 @@
 #ifndef _GLIBCXX_EXPERIMENTAL_SRCLOC
 #define _GLIBCXX_EXPERIMENTAL_SRCLOC 1
 
+#if __cplusplus >= 201402L
 #include 
 
 namespace std {
@@ -84,4 +85,5 @@ inline namespace fundamentals_v2 {
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
-#endif
+#endif // C++14
+#endif // _GLIBCXX_EXPERIMENTAL_SRCLOC
diff --git a/libstdc++-v3/include/experimental/utility 
b/libstdc++-v3/include/experimental/utility
index f0c3b4fcd90..8abf55c0526 100644
--- a/libstdc++-v3/include/experimental/utility
+++ b/libstdc++-v3/include/experimental/utility
@@ -30,6 +30,7 @@
 #ifndef _GLIBCXX_EXPERIMENTAL_UTILITY
 #define _GLIBCXX_EXPERIMENTAL_UTILITY 1
 
+#if __cplusplus >= 201402L
 #include 
 #include 
 #include 
@@ -47,4 +48,5 @@ inline namespace fundamentals_v2 {
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
-#endif
+#endif // C++14
+#endif // _GLIBCXX_EXPERIMENTAL_UTILITY
diff --git a/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc 
b/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
index b0e6e289009..342edc5352d 100644
--- a/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
+++ b/libstdc++-v3/testsuite/experimental/feat-lib-fund.cc
@@ -1,57 +1,36 @@
-// { dg-do preprocess { target c++14 } }
+// { dg-do preprocess }
 
-#if !__has_include()
-#  error ""
+// Include all the LFTS headers. This should work with any -std flag.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if __has_include() // not supported as of GCC 11
+# include 
 #endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
-
-#if !__has_include()
-#  error ""
-#endif
-
-//#if !__has_include()
-//#  error ""
-//#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

Re: [PATCH] varasm: Fix up __patchable_function_entries handling

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 05:36:04AM -0800, H.J. Lu wrote:
> gas is correct.
> 
> > comdat or for retain), then we should do something like the following
> > untested change, but if it is gas bug, it should be fixed there.
> >
> > 2020-12-15  Jakub Jelinek  
> >
> > * varasm.c (default_elf_asm_named_section): Always force
> > section flags even for sections with SECTION_LINK_ORDER flag.
> >

> LGTM.  But I can't approve it.

Bootstrapped/regtested on x86_64-linux and i686-linux successfully.
Ok for trunk?

Jakub

c++: Fix detailed-mem-stat breakage

[Nathan Sidwell]

module.cc has a static initializer that ends up in a circular
dependency when detailed mem stats are enabled.  This removes the need
for that initializer to be dynamic, and we punt to the lazy
initializing we already had inside the object in question anyway.  At
the cost of an additional indirection.

gcc/cp/
* module.cc (loc_spans): Make spans a pointer, not inline.
Adjust all accesses.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index 1b40a72a0d6..d2806966e43 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -3273,32 +3273,34 @@ public:
   };
 
 private:
-  vec spans;
+  vec *spans;
 
 public:
   loc_spans ()
+/* Do not preallocate spans, as that causes
+   --enable-detailed-mem-stats problems.  */
+: spans (nullptr)
   {
-spans.create (20);
   }
   ~loc_spans ()
   {
-spans.release ();
+delete spans;
   }
 
 public:
   span &operator[] (unsigned ix)
   {
-return spans[ix];
+return (*spans)[ix];
   }
   unsigned length () const
   {
-return spans.length ();
+return spans->length ();
   }
 
 public:
   bool init_p () const
   {
-return spans.length () != 0;
+return spans != nullptr;
   }
   /* Initializer.  */
   void init (const line_maps *lmaps, const line_map_ordinary *map);
@@ -3321,7 +3323,7 @@ public:
 public:
   location_t main_start () const
   {
-return spans[SPAN_MAIN].ordinary.first;
+return (*spans)[SPAN_MAIN].ordinary.first;
   }
 
 public:
@@ -13656,7 +13658,8 @@ void
 loc_spans::init (const line_maps *lmaps, const line_map_ordinary *map)
 {
   gcc_checking_assert (!init_p ());
-  spans.reserve (20);
+  spans = new vec ();
+  spans->reserve (20);
 
   span interval;
   interval.ordinary.first = 0;
@@ -13668,10 +13671,10 @@ loc_spans::init (const line_maps *lmaps, const line_map_ordinary *map)
 = MAP_START_LOCATION (LINEMAPS_ORDINARY_MAP_AT (line_table, 0));
   interval.macro.first = interval.macro.second;
   dump (dumper::LOCATION)
-&& dump ("Fixed span %u ordinary:[%u,%u) macro:[%u,%u)", spans.length (),
+&& dump ("Fixed span %u ordinary:[%u,%u) macro:[%u,%u)", spans->length (),
 	 interval.ordinary.first, interval.ordinary.second,
 	 interval.macro.first, interval.macro.second);
-  spans.quick_push (interval);
+  spans->quick_push (interval);
 
   /* A span for command line & forced headers.  */
   interval.ordinary.first = interval.ordinary.second;
@@ -13682,18 +13685,18 @@ loc_spans::init (const line_maps *lmaps, const line_map_ordinary *map)
   interval.macro.first = LINEMAPS_MACRO_LOWEST_LOCATION (lmaps);
 }
   dump (dumper::LOCATION)
-&& dump ("Pre span %u ordinary:[%u,%u) macro:[%u,%u)", spans.length (),
+&& dump ("Pre span %u ordinary:[%u,%u) macro:[%u,%u)", spans->length (),
 	 interval.ordinary.first, interval.ordinary.second,
 	 interval.macro.first, interval.macro.second);
-  spans.quick_push (interval);
+  spans->quick_push (interval);
   
   /* Start an interval for the main file.  */
   interval.ordinary.first = interval.ordinary.second;
   interval.macro.second = interval.macro.first;
   dump (dumper::LOCATION)
-&& dump ("Main span %u ordinary:[%u,*) macro:[*,%u)", spans.length (),
+&& dump ("Main span %u ordinary:[%u,*) macro:[*,%u)", spans->length (),
 	 interval.ordinary.first, interval.macro.second);
-  spans.quick_push (interval);
+  spans->quick_push (interval);
 }
 
 /* Reopen the span, if we want the about-to-be-inserted set of maps to
@@ -13727,9 +13730,9 @@ loc_spans::open (location_t hwm = UNKNOWN_LOCATION)
   interval.ordinary_delta = interval.macro_delta = 0;
   dump (dumper::LOCATION)
 && dump ("Opening span %u ordinary:[%u,... macro:...,%u)",
-	 spans.length (), interval.ordinary.first,
+	 spans->length (), interval.ordinary.first,
 	 interval.macro.second);
-  spans.safe_push (interval);
+  spans->safe_push (interval);
 }
 
 /* Close out the current linemap interval.  The last maps are within
@@ -13738,7 +13741,7 @@ loc_spans::open (location_t hwm = UNKNOWN_LOCATION)
 void
 loc_spans::close ()
 {
-  span &interval = spans.last ();
+  span &interval = spans->last ();
 
   interval.ordinary.second
 = ((line_table->highest_location + (1 << line_table->default_range_bits))
@@ -13746,7 +13749,7 @@ loc_spans::close ()
   interval.macro.first = LINEMAPS_MACRO_LOWEST_LOCATION (line_table);
   dump (dumper::LOCATION)
 && dump ("Closing span %u ordinary:[%u,%u) macro:[%u,%u)",
-	 spans.length () - 1,
+	 spans->length () - 1,
 	 interval.ordinary.first,interval.ordinary.second,
 	 interval.macro.first, interval.macro.second);
 }
@@ -13757,12 +13760,12 @@ loc_spans::close ()
 const loc_spans::span *
 loc_spans::ordinary (location_t loc)
 {
-  unsigned len = spans.length ();
+  unsigned len = spans->length ();
   unsigned pos = 0;
   while (len)
 {
   unsigned half = len / 2;
-  const span &probe = spans[pos + half];
+  const span &pr

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/15/20 3:00 AM, Nikhil Benesch wrote:

If this patch looks good, I'll submit it upstream tomorrow.


Assuming no news is good news, I sent
https://go-review.googlesource.com/c/gofrontend/+/278672.

Re: libcody: Fix for dash

[Nathan Sidwell]

On 12/16/20 5:02 AM, Richard Sandiford wrote:

Nathan Sidwell  writes:

Apparently 'var+=...' is not a dash thing.  Fixed thusly.

* config.m4: Avoid non-dash idiom
  * configure: Rebuilt.

pushed (2 patches, because I didn't look carefully enough the first time)


Thanks.  I think the other uses of += need the same treatment though:


thanks, I think this gets them all.

There were still some dash-killing uses of +=.  Fixed thusly.

* config.m4: Replace V+="..." with V="$V..."
* configure: Rebuilt.

nathan

--
Nathan Sidwell
diff --git i/libcody/config.m4 w/libcody/config.m4
index 801cfbdb593..ce5e84d0278 100644
--- i/libcody/config.m4
+++ w/libcody/config.m4
@@ -2,6 +2,8 @@
 # Copyright (C) 2020 Nathan Sidwell, nat...@acm.org
 # License: Apache v2.0
 
+# Note: VAR+=... is not dashing, despite its looks
+
 AC_DEFUN([NMS_NOT_IN_SOURCE],
 [if test -e configure ; then
 AC_MSG_ERROR([Do not build in the source tree.  Reasons])
@@ -28,14 +30,13 @@ fi])
 
 AC_DEFUN([NMS_TOOL_DIRS],
 [if test "$tools" && test -d "$tools/include" ; then
-  CXX+=" -I$tools/include"
+  CXX="$CXX -I$tools/include"
 fi
 if test "$tools" && test -d "$tools/lib" ; then
   toollib="$tools/lib"
   if os=$(CXX -print-multi-os-directory 2>/dev/null) ; then
-toollib+="/${os}"
+toollib="$toollib/${os}"
   fi
-  ## VAR+=... is not dashing
   LDFLAGS="$LDFLAGS -L $toollib"
   unset toollib
 fi])
@@ -86,7 +87,7 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 ]])],
 [AC_MSG_RESULT([yes])],
 [CXX_ORIG="$CXX"
-CXX+=" -std=c++11"
+CXX="$CXX -std=c++11"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#if __cplusplus != 201103
 #error "C++11 is required"
@@ -112,7 +113,7 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 #endif
 ]])],
 [AC_MSG_RESULT([yes])],
-[CXX+=" -std=c++20"
+[CXX="$CXX -std=c++20"
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM([
 [#if __cplusplus <= 201703
 #error "C++20 is required"
@@ -248,7 +249,7 @@ if test "${enable_backtrace:-maybe}" != no ; then
 AC_CHECK_HEADERS([demangle.h libiberty/demangle.h],[break])
 # libbfd prevents distribution because of licensing
 AC_CHECK_HEADERS([bfd.h])
-AC_SEARCH_LIBS([bfd_openr],[bfd],[LIBS+="-lz -liberty -ldl"],,[-lz -liberty -ldl])
+AC_SEARCH_LIBS([bfd_openr],[bfd],[LIBS="$LIBS -lz -liberty -ldl"],,[-lz -liberty -ldl])
   fi
   if test "$ac_cv_func_backtrace" = yes ; then
 nms_backtrace=yes
@@ -272,8 +273,8 @@ for generated in config.h.in configure ; do
 done
 for dir in . $SUBDIRS
 do
-  CONFIG_FILES+=" $dir/Makesub"
-  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES+=" $dir/tests/Makesub"
+  CONFIG_FILES="$CONFIG_FILES $dir/Makesub"
+  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES="$CONFIG_FILES $dir/tests/Makesub"
 done
 AC_CONFIG_FILES([$CONFIG_FILES])
 AC_SUBST(configure_args,[$ac_configure_args])
diff --git i/libcody/configure w/libcody/configure
index 1a119c59b9f..4cc03dcaa3a 100755
--- i/libcody/configure
+++ w/libcody/configure
@@ -1824,6 +1824,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 # Copyright (C) 2020 Nathan Sidwell, nat...@acm.org
 # License: Apache v2.0
 
+# Note: VAR+=... is not dashing, despite its looks
+
 
 
 # thanks to Zack Weinberg for fixing this!
@@ -2574,7 +2576,7 @@ if ac_fn_cxx_try_compile "$LINENO"; then :
 $as_echo "yes" >&6; }
 else
   CXX_ORIG="$CXX"
-CXX+=" -std=c++11"
+CXX="$CXX -std=c++11"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -2625,14 +2627,13 @@ unset CXX_ORIG
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
 if test "$tools" && test -d "$tools/include" ; then
-  CXX+=" -I$tools/include"
+  CXX="$CXX -I$tools/include"
 fi
 if test "$tools" && test -d "$tools/lib" ; then
   toollib="$tools/lib"
   if os=$(CXX -print-multi-os-directory 2>/dev/null) ; then
-toollib+="/${os}"
+toollib="$toollib/${os}"
   fi
-  ## VAR+=... is not dashing
   LDFLAGS="$LDFLAGS -L $toollib"
   unset toollib
 fi
@@ -2671,8 +2672,8 @@ for generated in config.h.in configure ; do
 done
 for dir in . $SUBDIRS
 do
-  CONFIG_FILES+=" $dir/Makesub"
-  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES+=" $dir/tests/Makesub"
+  CONFIG_FILES="$CONFIG_FILES $dir/Makesub"
+  test -f ${srcdir}/$dir/tests/Makesub.in && CONFIG_FILES="$CONFIG_FILES $dir/tests/Makesub"
 done
 ac_config_files="$ac_config_files $CONFIG_FILES"
 

Re: [PATCH] libcody: Fix build for older GCC versions

[Nathan Sidwell]

On 12/16/20 8:05 AM, Jonathan Wakely wrote:

Before CWG DR 1955 the controlling expression for an #elif must be
syntactically correct, meaning this won't compile with C++11 compilers
such as gcc 4.8:

The solution is to define __has_include(X) as 0 for compilers that don't
support it.

The second problem is that when  is found, it is used
without the std:: qualification.

libcody/ChangeLog:

* internal.hh: Define fallback macros for __has_builtin and
__has_include. Use __has_builtin for __builtin_FILE and
__builtin_LINE. Define alias for std::source_location.

Built on GNu/Linux using both gcc-11 and gcc-4.8, and also by hacking
it so that __builtin_FILE and __builtin_LINE aren't found, and
 gets used.

OK for trunk?


great, thanks!

nathan


--
Nathan Sidwell

Re: [PATCH] varasm: Fix up __patchable_function_entries handling

[Jeff Law via Gcc-patches]

On 12/16/20 6:47 AM, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 05:36:04AM -0800, H.J. Lu wrote:
>> gas is correct.
>>
>>> comdat or for retain), then we should do something like the following
>>> untested change, but if it is gas bug, it should be fixed there.
>>>
>>> 2020-12-15  Jakub Jelinek  
>>>
>>> * varasm.c (default_elf_asm_named_section): Always force
>>> section flags even for sections with SECTION_LINK_ORDER flag.
>>>
>> LGTM.  But I can't approve it.
> Bootstrapped/regtested on x86_64-linux and i686-linux successfully.
> Ok for trunk?
Yes.  I probably wasn't clear about that yesterday ;-)

jeff

libcody: fix --enable-checking=... [PR 98311]

[Nathan Sidwell]

Thanks Jakub for pointing at libcpp.

The -enable-checking configure code in libcody didn't play well with
us.  This just uses libcpp's configurey for that piece.

libcody/
* configure.ac: Use libcpp's enable-checking code.
* configure: Rebuilt.

pushing to trunk

--
Nathan Sidwell
diff --git i/libcody/configure w/libcody/configure
index 4cc03dcaa3a..76ff932d61b 100755
--- i/libcody/configure
+++ w/libcody/configure
@@ -1285,7 +1285,11 @@ Optional Features:
   --enable-maintainer-mode
   enable maintainer mode. Add rules to rebuild
   configurey bits
-  --enable-checking   enable run-time checking
+  --enable-checking[=LIST]
+  enable expensive run-time checks. With LIST, enable
+  only specific categories of checks. Categories are:
+  yes,no,all,none,release. Flags are: misc,valgrind or
+  other strings
   --enable-exceptions enable exceptions & rtti
 
 Optional Packages:
@@ -2708,30 +2712,45 @@ _ACEOF
 
 # Check whether --enable-checking was given.
 if test "${enable_checking+set}" = set; then :
-  enableval=$enable_checking;
+  enableval=$enable_checking; ac_checking_flags="${enableval}"
 else
-  enable_checking="yes"
+
+# Determine the default checks.
+if test x$is_release = x ; then
+  ac_checking_flags=yes
+else
+  ac_checking_flags=release
+fi
 fi
 
-case $enable_checking in #(
-  yes|all|yes,*) :
-nms_checking=yes ;; #(
-  no|none|release) :
-nms_checking= ;; #(
-  *) :
-as_fn_error $? "unknown check \"$enable_checking\"" "$LINENO" 5 ;;
-esac
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking checking" >&5
-$as_echo_n "checking checking... " >&6; }
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: ${nms_checking:-no}" >&5
-$as_echo "${nms_checking:-no}" >&6; }
-if test "$nms_checking" = yes ; then
+IFS="${IFS= 	}"; ac_save_IFS="$IFS"; IFS="$IFS,"
+for check in release $ac_checking_flags
+do
+	case $check in
+	# these set all the flags to specific states
+	yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
+	release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	# these enable particular checks
+	assert) ac_assert_checking=1 ;;
+	misc) ac_checking=1 ;;
+	valgrind) ac_valgrind_checking=1 ;;
+	# accept
+	*) ;;
+	esac
+done
+IFS="$ac_save_IFS"
 
-cat >>confdefs.h <<_ACEOF
-#define NMS_CHECKING 0${nms_checking:+1}
-_ACEOF
+if test x$ac_checking != x ; then
+
+$as_echo "#define NMS_CHECKING 1" >>confdefs.h
+
+else
+  $as_echo "#define NMS_CHECKING 0" >>confdefs.h
 
 fi
+
+
 # Check whether --enable-exceptions was given.
 if test "${enable_exceptions+set}" = set; then :
   enableval=$enable_exceptions;
diff --git i/libcody/configure.ac w/libcody/configure.ac
index 31f041e6679..c3db5534f1f 100644
--- i/libcody/configure.ac
+++ w/libcody/configure.ac
@@ -24,7 +24,47 @@ NMS_LINK_OPT([-Wl,--no-undefined])
 NMS_CONFIG_FILES([gdbinit dox.cfg])
 
 NMS_BUGURL
-NMS_ENABLE_CHECKING
+dnl NMS_ENABLE_CHECKING
+dnl cloned from ../libcpp/configure.ac
+AC_ARG_ENABLE(checking,
+[AS_HELP_STRING([[--enable-checking[=LIST]]],
+		[enable expensive run-time checks.  With LIST,
+		 enable only specific categories of checks.
+		 Categories are: yes,no,all,none,release.
+		 Flags are: misc,valgrind or other strings])],
+[ac_checking_flags="${enableval}"],[
+# Determine the default checks.
+if test x$is_release = x ; then
+  ac_checking_flags=yes
+else
+  ac_checking_flags=release
+fi])
+IFS="${IFS= 	}"; ac_save_IFS="$IFS"; IFS="$IFS,"
+for check in release $ac_checking_flags
+do
+	case $check in
+	# these set all the flags to specific states
+	yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
+	release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+	# these enable particular checks
+	assert) ac_assert_checking=1 ;;
+	misc) ac_checking=1 ;;
+	valgrind) ac_valgrind_checking=1 ;;
+	# accept
+	*) ;;
+	esac
+done
+IFS="$ac_save_IFS"
+
+if test x$ac_checking != x ; then
+  AC_DEFINE(NMS_CHECKING, 1,
+[Define to 1 if you want more run-time sanity checks.])
+else
+  AC_DEFINE(NMS_CHECKING, 0)
+fi
+
+
 NMS_ENABLE_EXCEPTIONS
 
 AC_CONFIG_HEADERS([config.h])

[committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.

commit 96d9670e88333d8896a5d2f2bb0403c1e2ad19ab
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:50:34 2020

libstdc++: Only use __builtin_sprintf if supported [PR 96083]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

diff --git a/libstdc++-v3/include/ext/throw_allocator.h 
b/libstdc++-v3/include/ext/throw_allocator.h
index 0ab174f19a5..2364827a632 100644
--- a/libstdc++-v3/include/ext/throw_allocator.h
+++ b/libstdc++-v3/include/ext/throw_allocator.h
@@ -64,6 +64,10 @@
 #endif
 #include 
 
+#if !__has_builtin(__builtin_sprintf)
+# include 
+#endif
+
 namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -310,6 +314,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static void
 log_to_string(std::string& s, const_reference ref)
 {
+#if ! __has_builtin(__builtin_sprintf)
+  __typeof__(&std::sprintf) __builtin_sprintf = &std::sprintf;
+#endif
+
   char buf[40];
   const char tab('\t');
   s += "label: ";
@@ -332,6 +340,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 static void
 log_to_string(std::string& s, const std::pair& ref)
 {
+#if ! __has_builtin(__builtin_sprintf)
+  auto __builtin_sprintf = &std::sprintf;
+#endif
+
   char buf[40];
   const char tab('\t');
   s += "label: ";
@@ -566,6 +578,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static gen_t generator(engine(), distribution);
 #endif
 
+#if ! __has_builtin(__builtin_sprintf)
+  __typeof__(&std::sprintf) __builtin_sprintf = &std::sprintf;
+#endif
+
   double random = generator();
   if (random < distribution.min() || random > distribution.max())
{

[PATCH, OpenMP 5.0] Allow duplicate mapping of variables

[Chung-Lin Tang]

Hi Jakub,
when running sollve_vv tests (which we're trying to make work out-of-the-box),
some of the 5.0 tests which were testing map clause ordering also required
supporting mapping the same variable multiple times.

This was not allowed before, so besides the small changes needed in the
front-ends, the omp-lowering conventions for field lookup had to be adjusted.
For map clauses, we now use the whole OMP_CLAUSE expression to lookup
fields, instead of the variable DECL, which will clash and ICE when
multiple occurrences happen.

The modifications OpenACC firstprivate variables exist because they seem
to share code with normal map handling in many ways, so they were adjusted
to use the clause-as-key convention too (including the adjustments in
lower_oacc_reductions).

This has been tested for no regressions for gcc, g++, gfortran, and libgomp.
Is this okay for trunk after stage1 reopens?

Thanks,
Chung-Lin

2020-12-16  Chung-Lin Tang  

gcc/c/
* c-typeck.c (c_finish_omp_clauses): Adjust to allow duplicate
mapped variables for OpenMP.

gcc/cp/
* semantics.c (finish_omp_clauses):  Adjust to allow duplicate
mapped variables for OpenMP.

gcc/
* omp-low.c (install_var_field): Add new 'tree key_expr = NULL_TREE'
default parameter. Set splay-tree lookup key to key_expr instead of
var if key_expr is non-NULL.
(scan_sharing_clauses): Use clause tree expression as splay-tree key
for map/to/from and OpenACC firstprivate cases when installing the
variable field into the send/receive record type.
(lower_oacc_reductions): Adjust to find map-clause of reduction
variable, then create receiver-ref.
(lower_omp_target): Adjust to lookup var field using clause expression.

gcc/testsuite/
* c-c++-common/gomp/clauses-2.c: Adjust testcase.
diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 7d58e8de342..6bf57ae2ba1 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -14776,12 +14776,12 @@ c_finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
}
  else
bitmap_set_bit (&generic_head, DECL_UID (t));
}
  else if (bitmap_bit_p (&map_head, DECL_UID (t))
-  && (ort != C_ORT_OMP
-  || !bitmap_bit_p (&map_field_head, DECL_UID (t
+  && !bitmap_bit_p (&map_field_head, DECL_UID (t))
+  && ort != C_ORT_OMP)
{
  if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_MAP)
error_at (OMP_CLAUSE_LOCATION (c),
  "%qD appears more than once in motion clauses", t);
  else if (ort == C_ORT_ACC)
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 92e32c8e0ad..4159b770613 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7643,11 +7643,12 @@ finish_omp_clauses (tree clauses, enum 
c_omp_region_type ort)
}
  else
bitmap_set_bit (&generic_head, DECL_UID (t));
}
  else if (bitmap_bit_p (&map_head, DECL_UID (t))
-  && !bitmap_bit_p (&map_field_head, DECL_UID (t)))
+  && !bitmap_bit_p (&map_field_head, DECL_UID (t))
+  && ort != C_ORT_OMP)
{
  if (OMP_CLAUSE_CODE (c) != OMP_CLAUSE_MAP)
error_at (OMP_CLAUSE_LOCATION (c),
  "%qD appears more than once in motion clauses", t);
  else if (ort == C_ORT_ACC)
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 91a5e3d1431..f8109d9752a 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -761,24 +761,31 @@ build_sender_ref (tree var, omp_context *ctx)
 
 /* Add a new field for VAR inside the structure CTX->SENDER_DECL.  If
BASE_POINTERS_RESTRICT, declare the field with restrict.  */
 
 static void
-install_var_field (tree var, bool by_ref, int mask, omp_context *ctx)
+install_var_field (tree var, bool by_ref, int mask, omp_context *ctx,
+  tree key_expr = NULL_TREE)
 {
   tree field, type, sfield = NULL_TREE;
   splay_tree_key key = (splay_tree_key) var;
 
-  if ((mask & 16) != 0)
-{
-  key = (splay_tree_key) &DECL_NAME (var);
-  gcc_checking_assert (key != (splay_tree_key) var);
-}
-  if ((mask & 8) != 0)
+  if (key_expr)
+/* Allow user to explicitly set the expression used as the key.  */
+key = (splay_tree_key) key_expr;
+  else
 {
-  key = (splay_tree_key) &DECL_UID (var);
-  gcc_checking_assert (key != (splay_tree_key) var);
+  if ((mask & 16) != 0)
+   {
+ key = (splay_tree_key) &DECL_NAME (var);
+ gcc_checking_assert (key != (splay_tree_key) var);
+   }
+  if ((mask & 8) != 0)
+   {
+ key = (splay_tree_key) &DECL_UID (var);
+ gcc_checking_assert (key != (splay_tree_key) var);
+   }
 }
   gcc_assert ((mask & 1) == 0
  || !splay_tree_lookup

[PATCH, OpenMP 5.0] Basic support of release/delete clauses on target/target-data directives

[Chung-Lin Tang]

Hi Jakub,
we have some other sollve_vv tests for OpenMP 5.0, which tests the occurrence of
'delete' map kind on the target directive.

Looking through the specification, as early as 4.5, it seems that there's no
wording that release/delete map kinds are explicitly prohibited on structured 
block
device directives like target and target data (though may not be intuitive if
used in those cases)

According to the description of map clause operation, 'release' seems to be 
essentially
the equivalent of 'alloc' if used this way.

The 'delete' map kind might be of some special use to "deep de-allocate" some
mappings on the way out of a target[data] region. Seems to be sometimes useful, 
I think.

The attached patch is basically just a preliminary patch that lifts the 
rejection of
release/delete map clauses on target/target-data; it no longer rejects those 
kinds,
but has not yet any special handling of 'delete' in 
gomp_map/unmap_vars_internal yet,
making them essentially just the same as 'alloc'. That said, it helps with some 
testcase
compilation that doesn't test all the limitations.
(proper implementation of these clauses inside libgomp will be finished later)

Is this okay for trunk after stage1 reopens?

Thanks,
Chung-Lin

2020-12-16  Chung-Lin Tang  

gcc/c/
* c-parser.c (c_parser_omp_target_data): Allow 'release' and 'delete'
map kinds, update error message string.
(c_parser_omp_target): Likewise.

gcc/cp/
* parser.c (cp_parser_omp_target_data): Allow 'release' and 'delete'
map kinds, update error message string.
(cp_parser_omp_target): Likewise.

libgomp/
* target.c (gomp_map_vars_internal): Add GOMP_MAP_RELEASE and
GOMP_MAP_DELETE cases.
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 69ecdb5e822..970e620b63c 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -19563,26 +19563,28 @@ c_parser_omp_target_data (location_t loc, c_parser 
*parser, bool *if_p)
  case GOMP_MAP_TO:
  case GOMP_MAP_ALWAYS_TO:
  case GOMP_MAP_FROM:
  case GOMP_MAP_ALWAYS_FROM:
  case GOMP_MAP_TOFROM:
  case GOMP_MAP_ALWAYS_TOFROM:
  case GOMP_MAP_ALLOC:
+ case GOMP_MAP_RELEASE:
+ case GOMP_MAP_DELETE:
map_seen = 3;
break;
  case GOMP_MAP_FIRSTPRIVATE_POINTER:
  case GOMP_MAP_ALWAYS_POINTER:
  case GOMP_MAP_ATTACH_DETACH:
break;
  default:
map_seen |= 1;
error_at (OMP_CLAUSE_LOCATION (*pc),
  "%<#pragma omp target data%> with map-type other "
- "than %, %, % or % "
- "on % clause");
+ "than %, %, %, %, "
+ "%, or % on % clause");
*pc = OMP_CLAUSE_CHAIN (*pc);
continue;
  }
   else if (OMP_CLAUSE_CODE (*pc) == OMP_CLAUSE_USE_DEVICE_PTR
   || OMP_CLAUSE_CODE (*pc) == OMP_CLAUSE_USE_DEVICE_ADDR)
map_seen = 3;
   pc = &OMP_CLAUSE_CHAIN (*pc);
@@ -20027,23 +20029,25 @@ check_clauses:
  case GOMP_MAP_TO:
  case GOMP_MAP_ALWAYS_TO:
  case GOMP_MAP_FROM:
  case GOMP_MAP_ALWAYS_FROM:
  case GOMP_MAP_TOFROM:
  case GOMP_MAP_ALWAYS_TOFROM:
  case GOMP_MAP_ALLOC:
+ case GOMP_MAP_RELEASE:
+ case GOMP_MAP_DELETE:
  case GOMP_MAP_FIRSTPRIVATE_POINTER:
  case GOMP_MAP_ALWAYS_POINTER:
  case GOMP_MAP_ATTACH_DETACH:
break;
  default:
error_at (OMP_CLAUSE_LOCATION (*pc),
  "%<#pragma omp target%> with map-type other "
- "than %, %, % or % "
- "on % clause");
+ "than %, %, %, %, "
+ "%, or % on % clause");
*pc = OMP_CLAUSE_CHAIN (*pc);
continue;
  }
   pc = &OMP_CLAUSE_CHAIN (*pc);
 }
   cfun->has_omp_target = true;
   return true;
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7ea8c28830e..55f3ab3f852 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -41430,27 +41430,29 @@ cp_parser_omp_target_data (cp_parser *parser, 
cp_token *pragma_tok, bool *if_p)
  case GOMP_MAP_TO:
  case GOMP_MAP_ALWAYS_TO:
  case GOMP_MAP_FROM:
  case GOMP_MAP_ALWAYS_FROM:
  case GOMP_MAP_TOFROM:
  case GOMP_MAP_ALWAYS_TOFROM:
  case GOMP_MAP_ALLOC:
+ case GOMP_MAP_RELEASE:
+ case GOMP_MAP_DELETE:
map_seen = 3;
break;
  case GOMP_MAP_FIRSTPRIVATE_POINTER:
  case GOMP_MAP_FIRSTPRIVATE_REFERENCE:
  case GOMP_MAP_ALWAYS_POINTER:
  case GOMP_MAP_ATTACH_DETACH:
break;
  default:
map_seen |= 1;
error_at (OMP_CLAUSE_LOCATION (*pc),
  "%<#pragma omp target data%> with map-type other "
- 

Re: Libcody breaks configure

[Nathan Sidwell]

On 12/16/20 3:38 AM, Kewen.Lin via Gcc-patches wrote:

on 2020/12/16 下午2:35, Stott Graham via Gcc-patches wrote:

If any ---checking options used



The related PR PR98311[1] has been filed by David.

BR,
Kewen

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98311


now fixed


--
Nathan Sidwell

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Segher Boessenkool]

Hi!

On Wed, Dec 16, 2020 at 02:35:32PM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, shrink-wrapping disqualifies for prologue
> placement basic blocks that have EDGE_CROSSING incoming edge.
> I don't see why that is necessary, those edges seem to be redirected
> just fine, both on x86_64 and powerpc64.

This used to not work, as mentioned in the original patch submission:
https://patchwork.ozlabs.org/project/gcc/patch/52f14532eb742ac8d878a185a46a88da7b0326eb.1442588483.git.seg...@kernel.crashing.org/
I wonder what changed?

So, the situation is there are multiple incoming edges to where we want
to place the prologue.  Because we have to have one single edge to put
the prologue on (that is how the infrastructure we have works, it is not
anything fundamental), we create a new block that just jumps to the
block that needs the prologue, use that new edge for where we place the
prologue, and then redirect all edges to the first block to the new
block.  (We cannot in all case simply fall through.)

> In the former case, they
> are usually conditional jumps that patch_jump_insn can handle just fine,
> after all, they were previously crossing and will be crossing after
> the redirection too, just to a different label.  And in the powerpc64
> case, it is a simple_jump instead that again seems to be handled by
> patch_jump_insn just fine.

So what changed in the last five years that makes redirecting
EDGE_CROSSING jumps now always work?  Does that also apply to
EDGE_COMPLEX, btw?  Knowing this would make at least me a lot less
nervous about this patch :-)

> Sure, redirecting an edge that was previously not crossing to be crossing or
> vice versa can fail, but that is not what shrink-wrapping needs.

It used to ICE when not disallowing EDGE_CROSSING.

> Also tested in GCC 8 with this patch and don't see ICEs there either
> (though, of course, I'm not suggesting we should backport this to release
> branches).

The patch looks fine to me of course, modulo that worry.


Segher

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 09:28:56AM -0600, Segher Boessenkool wrote:
> This used to not work, as mentioned in the original patch submission:
> https://patchwork.ozlabs.org/project/gcc/patch/52f14532eb742ac8d878a185a46a88da7b0326eb.1442588483.git.seg...@kernel.crashing.org/
> I wonder what changed?

There is no testcase in that thread I could find, on which it would ICE.
The testcase in the patch (which I've excended today compared to what
the patch had yesterday) has the cases of a single as well as multiple
edges to the ideal prologue bb in the cold partition, yet I can't reproduce
the ICE.
As for what changed, I remember fixing PR87475 which is related to
redirection of crossing jumps.

> So, the situation is there are multiple incoming edges to where we want
> to place the prologue.  Because we have to have one single edge to put
> the prologue on (that is how the infrastructure we have works, it is not
> anything fundamental), we create a new block that just jumps to the
> block that needs the prologue, use that new edge for where we place the
> prologue, and then redirect all edges to the first block to the new
> block.  (We cannot in all case simply fall through.)

I believe this case is covered in the testcase.

> > In the former case, they
> > are usually conditional jumps that patch_jump_insn can handle just fine,
> > after all, they were previously crossing and will be crossing after
> > the redirection too, just to a different label.  And in the powerpc64
> > case, it is a simple_jump instead that again seems to be handled by
> > patch_jump_insn just fine.
> 
> So what changed in the last five years that makes redirecting
> EDGE_CROSSING jumps now always work?  Does that also apply to
> EDGE_COMPLEX, btw?  Knowing this would make at least me a lot less
> nervous about this patch :-)

I think EDGE_COMPLEX generally can't be redirected, it is ok to punt on
those.

Jakub

Re: libcody: fix --enable-checking=... [PR 98311]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 09:22:49AM -0500, Nathan Sidwell wrote:
> Thanks Jakub for pointing at libcpp.
> 
> The -enable-checking configure code in libcody didn't play well   with
> us.  This just uses libcpp's configurey   for that piece.
> 
>   libcody/
> * configure.ac:   Use libcpp's enable-checking code.
> * configure: Rebuilt.
> 
> pushing to trunk

This doesn't set is_release anywhere, which means when --enable-checking*
or --disable-checking isn't specified, it always treats it as
--enable-checking=yes, while the normal gcc behavior is treat only trunk
as --enable-checking=yes and treat release branches as
--enable-checking=release by default.

On the other side, nothing uses those ac_assert_checking and
ac_valgrind_checking variables, so it is a waste to compute those.

Is this ok if it passes testing?

2020-12-16  Jakub Jelinek  

* configure.ac: Compute is_release.
(NMS_ENABLE_CHECKING): Simplify but not computing ac_assert_checking
and ac_valgrind_checking the code doesn't use.
* configure: Regenerated.

--- libcody/configure.ac.jj 2020-12-16 16:14:49.468351790 +0100
+++ libcody/configure.ac2020-12-16 16:23:57.630214135 +0100
@@ -23,6 +23,14 @@ NMS_TOOL_DIRS
 NMS_LINK_OPT([-Wl,--no-undefined])
 NMS_CONFIG_FILES([gdbinit dox.cfg])
 
+# Enable expensive internal checks
+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
 NMS_BUGURL
 dnl NMS_ENABLE_CHECKING
 dnl cloned from ../libcpp/configure.ac
@@ -44,13 +52,8 @@ for check in release $ac_checking_flags
 do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac
--- libcody/configure.jj2020-12-16 16:14:49.459351891 +0100
+++ libcody/configure   2020-12-16 16:29:28.204514512 +0100
@@ -2686,6 +2686,14 @@ configure_args=$ac_configure_args
 
 
 
+# Enable expensive internal checks
+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking bugurl" >&5
 $as_echo_n "checking bugurl... " >&6; }
 
@@ -2728,13 +2736,8 @@ for check in release $ac_checking_flags
 do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac


Jakub

Re: [PATCH] improve caching and enhance array bounds checking

[Martin Sebor via Gcc-patches]

On 12/15/20 10:29 PM, Jeff Law wrote:



On 11/11/20 6:09 PM, Martin Sebor via Gcc-patches wrote:

The attached patch builds on top of the series I posted last
week(*) to improve the detection of out of bounds pointers
and C++ references, as well as a subset of invalid pointer
relational and subtraction expressions.

First, as I mentioned last week, the simple compute_objsize
cache I implemented then is space inefficient.  The changes
in this update enhance the  cache to reduce the space overhead
and improve compile-time efficiency.  The cache now consists
of two arrays, one storing the indices to the other.
The former is indexed by SSA_NAME version.  The latter also
contains separate entries for sizes of enclosing objects and
their members (missing from the first attempt, leading to
inefficient hacks to overcome the limitation).   These
improvements let clients look up the provenance of any pointer
in O(1) time and avoid the hacks.

Second, with the necessary cache improvements above,
the gimple-array-bounds changes enhance array bounds checking
in two ways:
1) pointers passed to functions or used to initialize C++
references are checked to see if they're valid and in bounds
and diagnosed if not (a subset of instances of passing valid
just-past-past-the-end and so non-dereferenceable pointers to
functions are also diagnosed)
2) relational or difference expressions involving pointers are
checked to make sure they point to the same object and diagnosed
if not.

Besides bootstrapping and regtesting I have also tested the full
patch series with a few packages, including Binutils/GDB, Glibc
and Valgrind, and verified that it doesn't cause any false
positives.  The new -Wpointer-compare warning does trigger in
two or three places in each, for subtracting pointers to distinct
objects.  Those are true positives, but the code I checked looks
benign.  In such cases the warning can be suppressed by converting
the pointers to intptr_t before the subtraction.

Martin

[*] Prerequisite patches:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558127.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557807.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html

gcc-wpointer-compare.diff

Improve detection of invalid pointer operations.

gcc/ChangeLog:

PR middle-end/93848
* builtins.c (compute_objsize_r): Add argument.
(access_ref::parm): New function.
(access_ref::get_ref): Add argument.  Avoid null pointers.  Treat
multiple PHIs with all arguments referencing the same object the same
as references to that object with a range of offsets.  Clear BASE0
for PHIs with arguments referencing distinct objects and different
offsets.
(access_ref::get_ref_type): New function.
(access_ref::size_remaining): Make sure low bound of size is
nonnegative.
(pointer_query::pointer_query): Adjust ctor.
(pointer_query::get_ref): Handle separate index and var caches.
(pointer_query::put_ref): Same.
(pointer_query::flush_cache): New function.
(access_ref::inform_access): Differentiate pointers to allocated
objects from those returned by non-allocation functions.
(get_offset_range): Make extern.
(handle_min_max_size): Add argument.  Pass it to compute_objsize.
(compute_objsize_r, compute_objsize): Same.
(gimple_call_alloc_p): Make extern.
(maybe_emit_free_warning): Adjust and simplify test for built-in
functions.
* builtins.h (struct access_ref): Add new members, adjust existing.
(get_offset_range): Declare.
(gimple_call_alloc_p): Same.
(compute_objsize): Add argument.
* common.opt (-Wpointer-compare): Move option here from gcc/c.opt.
* doc/invoke.texi (-Wpointer-compare): Update.
* gimple-array-bounds.cc (ptrrefs): New variable.
(format_offset_range): New function.
(format_subscript_range): New function.
(array_bounds_checker::check_array_ref): Remove argument.
(array_bounds_checker::check_mem_ref): Remove argument.  Check
no-warning bit on the current statement.  Use format_subscript_range.
Simplify informational messages.
(array_bounds_checker::check_addr_expr): Remove redundant argument
from calls.
(array_bounds_checker::ptrs_to_distinct): New function.
(array_bounds_checker::check_pointer_op): Same.
(array_bounds_checker::handle_assign): Same.
(array_bounds_checker::handle_call): Same.
(array_bounds_checker::check_array_bounds): Set new
array_bounds_checker members.  Adjust calls.
(check_array_bounds_dom_walker::before_dom_children): Call new
array_bounds_checker members.  Set statement visited bit.
(array_bounds_checker::check): Create and a pointer_query instance
and flush its cache.
* gimple-array-bounds.h (class 

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Martin Sebor via Gcc-patches]

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)

Martin

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)

The #ifdef __has_builtin in  was added more than three years
ago, before GCC supported __has_builtin. So that check was there to
make the code work with GCC, not other compilers.

Now that GCC supports it, I can simplify that.

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

On 16/12/20 17:02 +, Jonathan Wakely wrote:

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)


I recently discussed this subject with Judy Ward at Intel, and their
preference is for libstdc++ to use __has_builtin, see
6aa12274007bccbae2691a9d336c37fe167bb535 for a recent change to fix
feature detection for Intel.

Re: libcody: fix --enable-checking=... [PR 98311]

[Nathan Sidwell]

On 12/16/20 10:40 AM, Jakub Jelinek wrote:

On Wed, Dec 16, 2020 at 09:22:49AM -0500, Nathan Sidwell wrote:

Thanks Jakub for pointing at libcpp.

The -enable-checking configure code in libcody didn't play well with
us.  This just uses libcpp's configurey for that piece.

libcody/
 * configure.ac:Use libcpp's enable-checking code.
 * configure: Rebuilt.

pushing to trunk


This doesn't set is_release anywhere, which means when --enable-checking*
or --disable-checking isn't specified, it always treats it as
--enable-checking=yes, while the normal gcc behavior is treat only trunk
as --enable-checking=yes and treat release branches as
--enable-checking=release by default.

On the other side, nothing uses those ac_assert_checking and
ac_valgrind_checking variables, so it is a waste to compute those.

Is this ok if it passes testing?


yes. hehe, I checked that -enable-checking=set,of,options worked :)


2020-12-16  Jakub Jelinek  

* configure.ac: Compute is_release.
(NMS_ENABLE_CHECKING): Simplify but not computing ac_assert_checking
and ac_valgrind_checking the code doesn't use.
* configure: Regenerated.

--- libcody/configure.ac.jj 2020-12-16 16:14:49.468351790 +0100
+++ libcody/configure.ac2020-12-16 16:23:57.630214135 +0100
@@ -23,6 +23,14 @@ NMS_TOOL_DIRS
  NMS_LINK_OPT([-Wl,--no-undefined])
  NMS_CONFIG_FILES([gdbinit dox.cfg])
  
+# Enable expensive internal checks

+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
  NMS_BUGURL
  dnl NMS_ENABLE_CHECKING
  dnl cloned from ../libcpp/configure.ac
@@ -44,13 +52,8 @@ for check in release $ac_checking_flags
  do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac
--- libcody/configure.jj2020-12-16 16:14:49.459351891 +0100
+++ libcody/configure   2020-12-16 16:29:28.204514512 +0100
@@ -2686,6 +2686,14 @@ configure_args=$ac_configure_args
  
  
  
+# Enable expensive internal checks

+is_release=
+if test -d $srcdir/../gcc \
+   && test -f $srcdir/../gcc/DEV-PHASE \
+   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
+  is_release=yes
+fi
+
  { $as_echo "$as_me:${as_lineno-$LINENO}: checking bugurl" >&5
  $as_echo_n "checking bugurl... " >&6; }
  
@@ -2728,13 +2736,8 @@ for check in release $ac_checking_flags

  do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
-   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
-   # these enable particular checks
-   assert) ac_assert_checking=1 ;;
-   misc) ac_checking=1 ;;
-   valgrind) ac_valgrind_checking=1 ;;
+   yes|all|misc) ac_checking=1 ;;
+   no|none|release) ac_checking= ;;
# accept
*) ;;
esac


Jakub




--
Nathan Sidwell

Re: [PATCH] libgcc: Thumb-1 Floating-Point Library for Cortex M0

[Christophe Lyon via Gcc-patches]

On Wed, 2 Dec 2020 at 04:31, Daniel Engel  wrote:
>
> Hi Christophe,
>
> On Thu, Nov 26, 2020, at 1:14 AM, Christophe Lyon wrote:
> > Hi,
> >
> > On Fri, 13 Nov 2020 at 00:03, Daniel Engel  wrote:
> > >
> > > Hi,
> > >
> > > This patch adds an efficient assembly-language implementation of IEEE-
> > > 754 compliant floating point routines for Cortex M0 EABI (v6m, thumb-
> > > 1).  This is the libgcc portion of a larger library originally
> > > described in 2018:
> > >
> > > https://gcc.gnu.org/legacy-ml/gcc/2018-11/msg00043.html
> > >
> > > Since that time, I've separated the libm functions for submission to
> > > newlib.  The remaining libgcc functions in the attached patch have
> > > the following characteristics:
> > >
> > > Function(s) Size (bytes)Cycles  
> > > Stack   Accuracy
> > > __clzsi242  23  0 
> > >   exact
> > > __clzsi2 (OPTIMIZE_SIZE)22  55  0 
> > >   exact
> > > __clzdi28+__clzsi2  4+__clzsi2  0 
> > >   exact
> > >
> > > __umulsidi3 44  24  0 
> > >   exact
> > > __mulsidi3  30+__umulsidi3  24+__umulsidi3  8 
> > >   exact
> > > __muldi3 (__aeabi_lmul) 10+__umulsidi3  6+__umulsidi3   0 
> > >   exact
> > > __ashldi3 (__aeabi_llsl)22  13  0 
> > >   exact
> > > __lshrdi3 (__aeabi_llsr)22  13  0 
> > >   exact
> > > __ashrdi3 (__aeabi_lasr)22  13  0 
> > >   exact
> > >
> > > __aeabi_lcmp20   13 0 
> > >   exact
> > > __aeabi_ulcmp   16  10  0 
> > >   exact
> > >
> > > __udivsi3 (__aeabi_uidiv)   56  72 – 3850 
> > >   < 1 lsb
> > > __divsi3 (__aeabi_idiv) 38+__udivsi326+__udivsi38 
> > >   < 1 lsb
> > > __udivdi3 (__aeabi_uldiv)   164 103 – 1394  
> > > 16  < 1 lsb
> > > __udivdi3 (OPTIMIZE_SIZE)   142 120 – 1392  
> > > 16  < 1 lsb
> > > __divdi3 (__aeabi_ldiv) 54+__udivdi336+__udivdi3
> > > 32  < 1 lsb
> > >
> > > __shared_float  178
> > > __shared_float (OPTIMIZE_SIZE)  154
> > >
> > > __addsf3 (__aeabi_fadd) 116+__shared_float  31 – 76 8 
> > >   <= 0.5 ulp
> > > __addsf3 (OPTIMIZE_SIZE)112+__shared_float  74  8 
> > >   <= 0.5 ulp
> > > __subsf3 (__aeabi_fsub) 8+__addsf3  6+__addsf3  8 
> > >   <= 0.5 ulp
> > > __aeabi_frsub   8+__addsf3  6+__addsf3  8 
> > >   <= 0.5 ulp
> > > __mulsf3 (__aeabi_fmul) 112+__shared_float  73 – 97 8 
> > >   <= 0.5 ulp
> > > __mulsf3 (OPTIMIZE_SIZE)96+__shared_float   93  8 
> > >   <= 0.5 ulp
> > > __divsf3 (__aeabi_fdiv) 132+__shared_float  83 – 3618 
> > >   <= 0.5 ulp
> > > __divsf3 (OPTIMIZE_SIZE)120+__shared_float  263 – 359   8 
> > >   <= 0.5 ulp
> > >
> > > __cmpsf2/__lesf2/__ltsf272  33  0 
> > >   exact
> > > __eqsf2/__nesf2 4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __gesf2/__gesf2 4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __unordsf2 (__aeabi_fcmpun) 4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmpeq  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmpne  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmplt  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmple  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > > __aeabi_fcmpge  4+__cmpsf2  3+__cmpsf2  0 
> > >   exact
> > >
> > > __floatundisf (__aeabi_ul2f)14+__shared_float   40 – 81 8 
> > >   <= 0.5 ulp
> > > __floatundisf (OPTIMIZE_SIZE)   14+__shared_float   40 – 2378 
> > >   <= 0.5 ulp
> > > __floatunsisf (__aeabi_ui2f)0+__floatundisf 1+__floatundisf 8 
> > >   <= 0.5 ulp
> > > __floatdisf (__aeabi_l2f)   14+__floatundisf7+__floatundisf 8 
> > >   <= 0.5 ulp
> > > __floatsisf (__aeabi_i2f)   0+__floatdisf   1+__floatdisf   8 
> > >   <= 0.5 ulp
> > >
> > > __fixsfdi (__aeabi_f2lz)74  27 – 33 0 
> > >   exact
> > > __fixunssfdi (__aeabi_f2ulz)4+__fixsfdi 3+__fixsfdi 0 
> > >

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Segher Boessenkool]

On Wed, Dec 16, 2020 at 04:36:37PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 09:28:56AM -0600, Segher Boessenkool wrote:
> > This used to not work, as mentioned in the original patch submission:
> > https://patchwork.ozlabs.org/project/gcc/patch/52f14532eb742ac8d878a185a46a88da7b0326eb.1442588483.git.seg...@kernel.crashing.org/
> > I wonder what changed?
> 
> There is no testcase in that thread I could find, on which it would ICE.

It was just a bootstrap+regression check, so no new testcase was needed.
I don't remember what target, but powerpc (32+64, BE) probably.

> The testcase in the patch (which I've excended today compared to what
> the patch had yesterday) has the cases of a single as well as multiple
> edges to the ideal prologue bb in the cold partition, yet I can't reproduce
> the ICE.
> As for what changed, I remember fixing PR87475 which is related to
> redirection of crossing jumps.

But that is for cfglayout mode?  Shrink-wrap has to do everything in
cfgrtl mode unfortunately, because of the partitioning stuff.  Sounds
like a good cancidate otherwise.

> > So, the situation is there are multiple incoming edges to where we want
> > to place the prologue.  Because we have to have one single edge to put
> > the prologue on (that is how the infrastructure we have works, it is not
> > anything fundamental), we create a new block that just jumps to the
> > block that needs the prologue, use that new edge for where we place the
> > prologue, and then redirect all edges to the first block to the new
> > block.  (We cannot in all case simply fall through.)
> 
> I believe this case is covered in the testcase.

Yeah...  It is never certaint what it will look like in the generated
machine code, but yup, probably.

In either case, if regstrap now works with this on all targets, this is
great :-)  I just wish I knew what changed.

> > > In the former case, they
> > > are usually conditional jumps that patch_jump_insn can handle just fine,
> > > after all, they were previously crossing and will be crossing after
> > > the redirection too, just to a different label.  And in the powerpc64
> > > case, it is a simple_jump instead that again seems to be handled by
> > > patch_jump_insn just fine.
> > 
> > So what changed in the last five years that makes redirecting
> > EDGE_CROSSING jumps now always work?  Does that also apply to
> > EDGE_COMPLEX, btw?  Knowing this would make at least me a lot less
> > nervous about this patch :-)
> 
> I think EDGE_COMPLEX generally can't be redirected, it is ok to punt on
> those.

Yeah, it is the kitchen sink "do not touch this" flag :-)

Thanks again,


Segher

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Jakub Jelinek via Gcc-patches]

On Wed, Dec 16, 2020 at 11:17:29AM -0600, Segher Boessenkool wrote:
> It was just a bootstrap+regression check, so no new testcase was needed.
> I don't remember what target, but powerpc (32+64, BE) probably.

I'll bootstrap/regtest the patch on powerpc64 and powerpc64le then.
> 
> > The testcase in the patch (which I've excended today compared to what
> > the patch had yesterday) has the cases of a single as well as multiple
> > edges to the ideal prologue bb in the cold partition, yet I can't reproduce
> > the ICE.
> > As for what changed, I remember fixing PR87475 which is related to
> > redirection of crossing jumps.
> 
> But that is for cfglayout mode?  Shrink-wrap has to do everything in
> cfgrtl mode unfortunately, because of the partitioning stuff.  Sounds
> like a good cancidate otherwise.

The patch affects both modes.  patch_jump_insn would in some cases ICE
and now it doesn't, instead returns false and rtl_redirect_edge_and_branch_force
then can deal with it another way.

Jakub

Re: [PATCH] shrink-wrap: Don't put on incoming EDGE_CROSSING [PR98289]

[Segher Boessenkool]

On Wed, Dec 16, 2020 at 06:31:35PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 16, 2020 at 11:17:29AM -0600, Segher Boessenkool wrote:
> > It was just a bootstrap+regression check, so no new testcase was needed.
> > I don't remember what target, but powerpc (32+64, BE) probably.
> 
> I'll bootstrap/regtest the patch on powerpc64 and powerpc64le then.

Thanks!

> > > The testcase in the patch (which I've excended today compared to what
> > > the patch had yesterday) has the cases of a single as well as multiple
> > > edges to the ideal prologue bb in the cold partition, yet I can't 
> > > reproduce
> > > the ICE.
> > > As for what changed, I remember fixing PR87475 which is related to
> > > redirection of crossing jumps.
> > 
> > But that is for cfglayout mode?  Shrink-wrap has to do everything in
> > cfgrtl mode unfortunately, because of the partitioning stuff.  Sounds
> > like a good cancidate otherwise.
> 
> The patch affects both modes.  patch_jump_insn would in some cases ICE
> and now it doesn't, instead returns false and 
> rtl_redirect_edge_and_branch_force
> then can deal with it another way.

But that can also ICE then, it's just pushing the problem around, unless
the original test was wrong?

In any case, if you see no problems anymore, I'll just try to stop
worrying :-)


Segher

c++: Fix offsetof use [PR 98232]

[Nathan Sidwell]

offsetof is underspecified.  GCC happened to accept an unneeded
explicit scoping, clang does not.

gcc/cp/
* module.cc (dumper::push): Clangify offsetof use.

pushed
--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index d2806966e43..e9ea18636b4 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -4153,7 +4153,7 @@ dumper::push (module_state *m)
   /* Create or extend the dump implementor.  */
   unsigned current = dumps ? dumps->stack.length () : 0;
   unsigned count = current ? current * 2 : EXPERIMENT (1, 20);
-  size_t alloc = (offsetof (impl, impl::stack)
+  size_t alloc = (offsetof (impl, stack)
 		  + impl::stack_t::embedded_size (count));
   dumps = XRESIZEVAR (impl, dumps, alloc);
   dumps->stack.embedded_init (count, current);

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Martin Sebor via Gcc-patches]

On 12/16/20 10:04 AM, Jonathan Wakely wrote:

On 16/12/20 17:02 +, Jonathan Wakely wrote:

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)


I recently discussed this subject with Judy Ward at Intel, and their
preference is for libstdc++ to use __has_builtin, see
6aa12274007bccbae2691a9d336c37fe167bb535 for a recent change to fix
feature detection for Intel.


Looks good, thanks.

Martin

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Dimitar Dimitrov]

On понеделник, 14 декември 2020 г. 20:53:36 EET Dimitar Dimitrov wrote:
> On петък, 11 декември 2020 г. 19:00:35 EET abebeos wrote:
> > After "digesting" a bit more your review, I need to thank you for opening
> > my eyes re "cherrypick" suggestion and... the missing g++ summaries. I
> > need
> > to update my setup to provide the g++ test-deltas, too. Note that in my
> > test-setup, more c++ tests pass than in yours, not exactly sure why. It's
> > in the "unresovled testcases".
> 
> Regarding the additional "unresolved testcases" in my results. I traced it
> to a bug in my setup. I did not prepare $HOME/.dejagnurc properly for AVR.
> I'll rerun the tests and post the results.
> 
> I'm using stock avr-libc, while I see you are using the avr-libc3 fork.
> Hopefully the main differences are in HW support, not core libc.
> 
> Regards,
> Dimitar

Here are the tests results with my environment fixes. Outcome is the same - 
saaadhu has no regressions.


=
baseline beb9afcaf1466996a301c778596c5df209e7913c
=== gcc Summary ===

# of expected passes105527
# of unexpected failures584
# of unexpected successes   16
# of expected failures  582
# of untested testcases 2
# of unresolved testcases   33
# of unsupported tests  5031

=== g++ Summary ===

# of expected passes146432
# of unexpected failures8012
# of unexpected successes   21
# of expected failures  624
# of untested testcases 10
# of unresolved testcases   3174
# of unsupported tests  2


=
pipcet/avr-ccmode
=== gcc Summary ===

# of expected passes105431
# of unexpected failures709
# of unexpected successes   16
# of expected failures  582
# of untested testcases 2
# of unresolved testcases   69
# of unsupported tests  5032

=== g++ Summary ===

# of expected passes146229
# of unexpected failures8291
# of unexpected successes   21
# of expected failures  624
# of untested testcases 10
# of unresolved testcases   3236
# of unsupported tests  2

=
saadhu/avr-cc0
=== gcc Summary ===

# of expected passes105527
# of unexpected failures584
# of unexpected successes   16
# of expected failures  582
# of untested testcases 2
# of unresolved testcases   33
# of unsupported tests  5031

=== g++ Summary ===

# of expected passes146432
# of unexpected failures8012
# of unexpected successes   21
# of expected failures  624
# of untested testcases 10
# of unresolved testcases   3174
# of unsupported tests  2

Regards,
Dimitar

[PATCH] doc: reflect the publication of C++20 in invoke.texi and standards.texi

[Jakub Jelinek via Gcc-patches]

Hi!

Jonathan mentioned on IRC that ISO/IEC 14882:2020 has been published
yesterday (and indeed it appears on www.iso.org for sale).
I think we should reflect that in our documentation and in cxx-status.html,
patches attached.
I understand we want to keep C++20 support experimental even in GCC 11,
though not sure if we should still talk about "almost certainly change in
incompatible ways" rather than that it might change in incompatible ways.

If the library is feature complete for C++17, we need to adjust the wording
slightly too.

2020-12-16  Jakub Jelinek  

* doc/invoke.texi (-std=c++20): Adjust for the publication of
ISO 14882:2020 standard.
* standards.texi: Likewise.

--- gcc/doc/invoke.texi.jj  2020-12-16 13:05:58.996994744 +0100
+++ gcc/doc/invoke.texi 2020-12-16 19:12:07.794336129 +0100
@@ -2418,8 +2418,8 @@ The name @samp{gnu++1z} is deprecated.
 
 @item c++20
 @itemx c++2a
-The next revision of the ISO C++ standard, planned for
-2020.  Support is highly experimental, and will almost certainly
+The 2020 ISO C++ standard plus amendments.
+Support is highly experimental, and will almost certainly
 change in incompatible ways in future releases.
 
 @item gnu++20
--- gcc/doc/standards.texi.jj   2020-07-28 15:39:09.874758070 +0200
+++ gcc/doc/standards.texi  2020-12-16 19:18:28.421078276 +0100
@@ -221,11 +221,18 @@ To select this standard in GCC, use the
 
 The C++ language was further revised in 2017 and ISO/IEC 14882:2017 was
 published.  This is referred to as C++17, and before publication was
-often referred to as C++1z.  GCC supports all the changes in the new
+often referred to as C++1z.  GCC supports all the changes in that
 specification.  For further details see
-@uref{https://gcc.gnu.org/projects/@/cxx-status.html#cxx1z}.  Use the option
+@uref{https://gcc.gnu.org/projects/@/cxx-status.html#cxx17}.  Use the option
 @option{-std=c++17} to select this variant of C++.
 
+Another revised ISO C++ standard was published in 2020 as ISO/IEC
+14882:2020, and is referred to as C++20; before its publication it was
+sometimes referred to as C++2a.  GCC supports most of the changes in the
+new specification.  For further details see
+@uref{https://gcc.gnu.org/projects/@/cxx-status.html@cxx20}.
+To select this standard in GCC, use the option @option{-std=c++20}.
+
 More information about the C++ standards is available on the ISO C++
 committee's web site at @uref{http://www.open-std.org/@/jtc1/@/sc22/@/wg21/}.
 
@@ -243,7 +250,8 @@ select an extended version of the C++ la
 @option{-std=gnu++98} (for C++98 with GNU extensions), or
 @option{-std=gnu++11} (for C++11 with GNU extensions), or
 @option{-std=gnu++14} (for C++14 with GNU extensions), or
-@option{-std=gnu++17} (for C++17 with GNU extensions).  
+@option{-std=gnu++17} (for C++17 with GNU extensions), or
+@option{-std=gnu++20} (for C++20 with GNU extensions).
 
 The default, if
 no C++ language dialect options are given, is @option{-std=gnu++17}.

Jakub
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 403d6740..3d3ed0fe 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -33,8 +33,8 @@
 
   C++20 Support in GCC
 
-  GCC has experimental support for the next revision of the C++
-  standard, which is expected to be published in 2020.
+  GCC has experimental support for the latest revision of the C++
+  standard, which was published in 2020.
 
   C++20 features are available since GCC 8. To enable C++20
   support, add the command-line parameter -std=c++20
@@ -44,9 +44,7 @@
 add -std=gnu++20.
 
   Important: Because the ISO C++20 standard is
-  still evolving, GCC's support is experimental. No attempt
-  will be made to maintain backward compatibility with implementations of
-  C++20 features that do not reflect the final standard.
+  very recent, GCC's support is experimental.
 
   C++20 Language Features
 
@@ -575,7 +573,7 @@
 
   C++17 Support in GCC
 
-  GCC has almost full support for the latest revision of the C++
+  GCC has almost full support for the previous revision of the C++
   standard, which was published in 2017.
   Some library features are missing or incomplete, as described in
   https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017";>the
 library documentation.
@@ -902,8 +900,7 @@
 
   C++14 Support in GCC
 
-  GCC has full support for the previous revision of the C++
-  standard, which was published in 2014.
+  GCC has full support for the of the 2014 C++ standard.
 
   This mode is the default in GCC 6.1 up until GCC 10 (including); it can
   be explicitly selected with the -std=c++14 command-line flag,

[PATCH] configure: Extend SHF_GNU_RETAIN conftest to check for unsupported gold

[Jozef Lawrynowicz]

Since "6fbec038f7a Use SHF_GNU_RETAIN to preserve symbol definitions",
GCC could create sections with the 'R' flag, which GAS would map to
SHF_GNU_RETAIN.

SHF_GNU_RETAIN support was not available in gold until Binutils commit
ff4bc37d77, on 2020-12-14. Until the support was added, invalid binaries
could be created if some special sections, such as .init_array, had
SHF_GNU_RETAIN set.

HAVE_GAS_SHF_GNU_RETAIN is now disabled if a version of gold without
SHF_GNU_RETAIN support is detected.

I tested that HAVE_GAS_SHF_GNU_RETAIN was enabled/disabled as
appropriate in a number of configurations, using both in-tree and
out-of-tree Binutils:
- Before the Binutils gold patch:
  * gold disabled == SHF_GNU_RETAIN enabled
  * gold enabled == SHF_GNU_RETAIN disabled
- After the Binutils gold patch:
  * gold disabled == SHF_GNU_RETAIN enabled
  * gold enabled == SHF_GNU_RETAIN enabled 

Successfully bootstrapped for x86_64-pc-linux-gnu.

Ok to apply?
>From af3000bbacc6d8ca57581c11790032b73ea944ac Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Wed, 16 Dec 2020 18:33:54 +
Subject: [PATCH] configure: Extend SHF_GNU_RETAIN conftest to check for
 unsupported gold

Since "6fbec038f7a Use SHF_GNU_RETAIN to preserve symbol definitions",
GCC could create sections with the 'R' flag, which GAS would map to
SHF_GNU_RETAIN.

SHF_GNU_RETAIN support was not available in gold until Binutils commit
ff4bc37d77, on 2020-12-14. Until the support was added, invalid binaries
could be created if some special sections, such as .init_array, had
SHF_GNU_RETAIN set.

HAVE_GAS_SHF_GNU_RETAIN is now disabled if a version of gold without
SHF_GNU_RETAIN support is detected.

gcc/ChangeLog:

PR target/98210
* configure: Regenerate.
* configure.ac (gcc_cv_as_shf_gnu_retain): Disable
HAVE_GAS_SHF_GNU_RETAIN for gold versions that do not support it.
---
 gcc/configure| 60 -
 gcc/configure.ac | 64 +---
 2 files changed, 120 insertions(+), 4 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index 9a27e459f14..544ec92463e 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -24442,7 +24442,63 @@ case "${target}" in
 gcc_cv_as_shf_gnu_retain=no
 ;;
   *)
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for section 
'R' flag" >&5
+# gold did not support SHF_GNU_RETAIN until 2.35.50.20201215.
+# Support for SHF_GNU_RETAIN in GCC was only added on 2020-12-01, so rather
+# than only disabling the GCC functionality if gold is the default, disable
+# it if a gold without the support has been built at all.
+
+ld_gold=`which ${gcc_cv_ld}.gold`
+check_gold_ver=no
+if test x$ld_is_gold = xyes; then
+  # Always check_gold_ver when gold is the default linker.
+  check_gold_ver=yes
+  gold_date=$ld_date
+elif test -f ../gold/ld-new$build_exeext; then
+  # Always check_gold_ver when gold has been built in-tree.
+  check_gold_ver=yes
+  gold_ver=`../gold/ld-new$build_exeext --version 2>/dev/null | sed 1q`
+  gold_date=`echo $gold_ver | sed -n 
's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
+elif test -n "$ld_gold"; then
+  gold_ver=`${gcc_cv_ld}.gold --version 2>/dev/null | sed 1q`
+  gold_vers=`echo $gold_ver | sed -n \
+ -e 's,^[^)]*[  ]\([0-9][0-9]*\.[0-9][0-9]*[^)]*\)) .*$,\1,p'`
+  gold_date=`echo $gold_ver | sed -n 
's,^.*\([2-9][0-9][0-9][0-9]\)\(-*\)\([01][0-9]\)\2\([0-3][0-9]\).*$,\1\3\4,p'`
+  gold_vers_major=`expr "$gold_vers" : '\([0-9]*\)'`
+  gold_vers_minor=`expr "$gold_vers" : '[0-9]*\.\([0-9]*\)'`
+  gold_vers_patch=`expr "$gold_vers" : '[0-9]*\.[0-9]*\.\([0-9]*\)'`
+
+  # If gold exists but is not the default linker, we assume that it is
+  # still intended to be used if the version matches the default ld.
+  if test 0"$gold_vers_major" -eq 0"$ld_vers_major" \
+ && test 0"$gold_vers_minor" -eq 0"$ld_vers_minor" \
+ && test 0"$gold_vers_patch" -eq 0"$ld_vers_patch" \
+ && test 0"$gold_date" -eq 0"$ld_date"; then
+   check_gold_ver=yes
+  fi
+fi
+
+# To test for the period of time when the SHF_GNU_RETAIN flag is supported
+# in ld, but not in gold, check the date in the version string.  If there
+# is no date, then we let gcc_GAS_CHECK_FEATURE make the correct
+# choice.
+if test $check_gold_ver = yes && test -n "$gold_date" \
+   && test 0"$gold_date" -lt 20201215; then
+  gcc_cv_as_shf_gnu_retain=no
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking gold support for 
SHF_GNU_RETAIN" >&5
+$as_echo_n "checking gold support for SHF_GNU_RETAIN... " >&6; }
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$gcc_cv_as_shf_gnu_retain" >&5
+$as_echo "$gcc_cv_as_shf_gnu_retain" >&6; }
+else
+  # Versions of Binutils with SHF_GNU_RETAIN support do not directly
+  # correspond

Re: [PATCH] genemit: Handle `const_double_zero' rtx

[Paul Koning via Gcc-patches]

> On Dec 16, 2020, at 6:35 AM, Maciej W. Rozycki  wrote:
> 
> ...
> NB the PDP-11 pieces affected here and tripping this assertion are I 
> believe dead code, as these insns are only ever produced by splitters and 
> do not appear to be referred by their names.  

Right; I gave them names for documentation purposes, after all insns are 
allowed to have names whether or not the name is referenced or is a required 
name for RTL generation.

paul

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Rainer Orth]

Hi Nikhil,

> On 12/15/20 3:00 AM, Nikhil Benesch wrote:
>> If this patch looks good, I'll submit it upstream tomorrow.
>
> Assuming no news is good news, I sent
> https://go-review.googlesource.com/c/gofrontend/+/278672.

sorry for the delay, but unfortunately news is not so good: I get

runtime_sysinfo.go:315:18: error: use of undefined type '_ucontext'
  315 | type _ucontext_t _ucontext
  |  ^
runtime_sysinfo.go:963:22: error: use of undefined type '_nv_alloc_ops'
  963 | type _nv_alloc_ops_t _nv_alloc_ops
  |  ^
runtime_sysinfo.go:945:267: error: use of undefined type '_ns_postinit_s'
  945 | type _netstack struct { netstack_u struct { nu_modules [21+1]*byte; }; 
netstack_m_state [21+1]uint32; netstack_lock _kmutex_t; netstack_next 
*_netstack; netstack_stackid int32; netstack_numzones int32; netstack_refcnt 
int32; netstack_flags int32; netstack_postinit *_ns_postinit_s; }
  | 


  ^

on both sparc and x86.

gen-sysinfo.go has

type _ucontext_t _ucontext
// type _ucontext struct { uc_flags uint32; uc_link *_ucontext_t; uc_sigmask 
_sigset_t; uc_stack _stack_t; uc_mcontext _mcontext_t; uc_xrs _xrs_t; uc_filler 
[2+1]int32; }

type _nv_alloc_ops_t _nv_alloc_ops
// type _nv_alloc_ops struct { nv_ao_init func(*_nv_alloc_t, ___va_list) int32; 
nv_ao_fini func(*_nv_alloc_t); nv_ao_alloc func(*_nv_alloc_t, uint32) *byte; 
nv_ao_free func(*_nv_alloc_t, *byte, uint32); nv_ao_reset func(*_nv_alloc_t); }

type _netstack struct { netstack_u struct { nu_modules [21+1]*byte; }; 
netstack_m_state [21+1]uint32; netstack_lock _kmutex_t; netstack_next 
*_netstack; netstack_stackid int32; netstack_numzones int32; netstack_refcnt 
int32; netstack_flags int32; netstack_postinit *_ns_postinit_s; }
// type _ns_postinit_s struct { ns_pi_fn func_ns_applyfn_t; ns_pi_arg uint32; 
ns_pi_next *_ns_postinit_s; }
// type _ns_postinit_t _ns_postinit_s

Rainer

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

Re: [PATCH] doc: reflect the publication of C++20 in invoke.texi and standards.texi

[Jonathan Wakely via Gcc-patches]

On 16/12/20 19:36 +0100, Jakub Jelinek wrote:

Hi!

Jonathan mentioned on IRC that ISO/IEC 14882:2020 has been published
yesterday (and indeed it appears on www.iso.org for sale).
I think we should reflect that in our documentation and in cxx-status.html,
patches attached.
I understand we want to keep C++20 support experimental even in GCC 11,
though not sure if we should still talk about "almost certainly change in
incompatible ways" rather than that it might change in incompatible ways.

If the library is feature complete for C++17, we need to adjust the wording
slightly too.


It isn't. I still need to finished reviewing Patrick's std::to_chars
patch.

[committed] libstdc++: Warn if __STRICT_ANSI has been undefined

[Jonathan Wakely via Gcc-patches]

Recent changes to use __int128 as an integer-like type in  and
to optimize std::uniform_int_distribution mean that the library relies
on __int128 more heavily than in the past.

The library expects that if __int128 is supported then either
__GLIBCXX_TYPE_INT_N_0 is defined (and we treat is like the standard
integer types), or __STRICT_ANSI__ is defined (and we need to add
special handling for __int128 as a non-standard integer type).

If users compile with -std=c++NN -U__STRICT_ANSI__ then it puts the
library into a broken and inconsistent state, where the compiler doesn't
define the __GLIBCXX_TYPE_INT_N_0 macro, but the library thinks it
doesn't need special handling for __int128. What the user should do is
compile with -std=gnu++NN instead.

This adds a warning if it appears that __int128 is supported but neither
__GLIBCXX_TYPE_INT_N_0 nor __STRICT_ANSI__ is defined.

libstdc++-v3/ChangeLog:

* include/bits/c++config: Warn if __STRICT_ANSI__ state is
inconsistent with __GLIBCXX_TYPE_INT_N_0.

Tested powerpc64-linux. Committed to trunk.

commit 767537a8b027bcb5807bb45b0268c5da98c2c7a0
Author: Jonathan Wakely 
Date:   Wed Dec 16 15:54:50 2020

libstdc++: Warn if __STRICT_ANSI has been undefined

Recent changes to use __int128 as an integer-like type in  and
to optimize std::uniform_int_distribution mean that the library relies
on __int128 more heavily than in the past.

The library expects that if __int128 is supported then either
__GLIBCXX_TYPE_INT_N_0 is defined (and we treat is like the standard
integer types), or __STRICT_ANSI__ is defined (and we need to add
special handling for __int128 as a non-standard integer type).

If users compile with -std=c++NN -U__STRICT_ANSI__ then it puts the
library into a broken and inconsistent state, where the compiler doesn't
define the __GLIBCXX_TYPE_INT_N_0 macro, but the library thinks it
doesn't need special handling for __int128. What the user should do is
compile with -std=gnu++NN instead.

This adds a warning if it appears that __int128 is supported but neither
__GLIBCXX_TYPE_INT_N_0 nor __STRICT_ANSI__ is defined.

libstdc++-v3/ChangeLog:

* include/bits/c++config: Warn if __STRICT_ANSI__ state is
inconsistent with __GLIBCXX_TYPE_INT_N_0.

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 155d0f46b16..cd7678eb16d 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -524,6 +524,15 @@ namespace std
 
 #define _GLIBCXX_USE_ALLOCATOR_NEW
 
+#ifdef __SIZEOF_INT128__
+#if ! defined __GLIBCXX_TYPE_INT_N_0 && ! defined __STRICT_ANSI__
+// If __int128 is supported, we expect __GLIBCXX_TYPE_INT_N_0 to be defined
+// unless the compiler is in strict mode. If it's not defined and the strict
+// macro is not defined, something is wrong.
+#warning "__STRICT_ANSI__ seems to have been undefined; this is not supported"
+#endif
+#endif
+
 #else // !__cplusplus
 # define _GLIBCXX_BEGIN_EXTERN_C
 # define _GLIBCXX_END_EXTERN_C

Re: [committed] libstdc++: Only use __builtin_sprintf if supported [PR 96083]

[Jonathan Wakely via Gcc-patches]

On 16/12/20 17:02 +, Jonathan Wakely wrote:

On 16/12/20 09:23 -0700, Martin Sebor via Libstdc++ wrote:

On 12/16/20 8:00 AM, Jonathan Wakely via Gcc-patches wrote:

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

Tested powerpc64le-linux. Committed to trunk.



I expected to see the test itself guarded by #ifdef __has_builtin
like in .  Or is this code only [meant to be] used with
compilers that understand __has_builtin?  (I'm mostly just curious
here about support for other compilers like ICC, not necessarily
pointing out a problem with the patch.)


All recent versions of Intel and Clang support __has_builtin.
(For Intel __has_builtin(__builtin_sprintf) is true, for Clang it's
false. But they both support checking it.)

The #ifdef __has_builtin in  was added more than three years
ago, before GCC supported __has_builtin. So that check was there to
make the code work with GCC, not other compilers.

Now that GCC supports it, I can simplify that.


Like so.

Tested powerpc64-linux, committed to trunk.


commit 4d4f82959aa0802611f1183389c4c74d22431e49
Author: Jonathan Wakely 
Date:   Wed Dec 16 17:18:10 2020

libstdc++: Simplify built-in detection in 

Now that GCC supports __has_builtin there is no need to test whether
it's defined, we can just use it unconditionally.

libstdc++-v3/ChangeLog:

* include/std/utility: Use __has_builtin without checking if
it's defined.

diff --git a/libstdc++-v3/include/std/utility b/libstdc++-v3/include/std/utility
index 4a9ad604cbc..61573f42f3f 100644
--- a/libstdc++-v3/include/std/utility
+++ b/libstdc++-v3/include/std/utility
@@ -297,27 +297,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // extract the elements in a tuple.
   template struct _Index_tuple { };
 
-#ifdef __has_builtin
-# if __has_builtin(__make_integer_seq)
-#  define _GLIBCXX_USE_MAKE_INTEGER_SEQ 1
-# endif
-#endif
-
   // Builds an _Index_tuple<0, 1, 2, ..., _Num-1>.
   template
 struct _Build_index_tuple
 {
-#if _GLIBCXX_USE_MAKE_INTEGER_SEQ
+#if __has_builtin(__make_integer_seq)
   template
 using _IdxTuple = _Index_tuple<_Indices...>;
 
+  // Clang defines __make_integer_seq for this purpose.
   using __type = __make_integer_seq<_IdxTuple, size_t, _Num>;
 #else
+  // For GCC and other compilers, use __integer_pack instead.
   using __type = _Index_tuple<__integer_pack(_Num)...>;
 #endif
 };
 
-#if __cplusplus > 201103L
+#if __cplusplus >= 201402L
 
 #define __cpp_lib_integer_sequence 201304
 
@@ -332,14 +328,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /// Alias template make_integer_sequence
   template
 using make_integer_sequence
-#if _GLIBCXX_USE_MAKE_INTEGER_SEQ
+#if __has_builtin(__make_integer_seq)
   = __make_integer_seq;
 #else
   = integer_sequence<_Tp, __integer_pack(_Num)...>;
 #endif
 
-#undef _GLIBCXX_USE_MAKE_INTEGER_SEQ
-
   /// Alias template index_sequence
   template
 using index_sequence = integer_sequence;

c++tools: fix install-strip [PR 98328]

[Nathan Sidwell]

I'd missed an install-strip rule in c++tools.  Here it is, cribbed
from gcc/ subdir.

c++tools/
* Makefile.in (INSTALL): Replace with ...
(INSTALL_PROGRAM): ... this.
(INSTALL_STRIP_PROGRAM): New.
(install-strip): New target.
(install): Use INSTALL_PROGRAM.
* configure.ac: Add INSTALL_PROGRAM.
* configure: Regenerated.

pushing to trunk
--
Nathan Sidwell
diff --git i/c++tools/Makefile.in w/c++tools/Makefile.in
index 4ec1419fa5b..310b5674fec 100644
--- i/c++tools/Makefile.in
+++ w/c++tools/Makefile.in
@@ -22,7 +22,8 @@ libexecdir := @libexecdir@
 target_noncanonical := @target_noncanonical@
 version := $(shell cat $(srcdir)/../gcc/BASE-VER)
 libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(version)
-INSTALL := @INSTALL@
+INSTALL_PROGRAM := @INSTALL_PROGRAM@
+INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s
 AUTOCONF := @AUTOCONF@
 AUTOHEADER := @AUTOHEADER@
 CXX := @CXX@
@@ -47,16 +48,23 @@ maintainer-clean::
 
 install::
 
-check:
-installcheck:
-dvi:
-pdf:
-html:
-info:
-install-info:
-install-pdf:
-install-man:
-install-html:
+check::
+installcheck::
+dvi::
+pdf::
+html::
+info::
+install-info::
+install-pdf::
+install-man::
+install-html::
+
+install-strip: override INSTALL_PROGRAM = $(INSTALL_STRIP_PROGRAM)
+ifneq ($(STRIP),)
+install-strip: STRIPPROG = $(STRIP)
+export STRIPPROG
+endif
+install-strip: install
 
 vpath %.cc $(srcdir)
 vpath %.in $(srcdir)
@@ -90,8 +98,7 @@ all::../gcc/g++-mapper-server$(exeext)
 
 install::
 	$(SHELL) $(srcdir)/../mkinstalldirs $(DESTDIR)$(libexecsubdir)
-	$(INSTALL) g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
-
+	$(INSTALL_PROGRAM) g++-mapper-server$(exeext) $(DESTDIR)$(libexecsubdir)
 endif
 
 ifneq ($(MAINTAINER),)
diff --git i/c++tools/configure w/c++tools/configure
index 82975120393..e8658aac16e 100755
--- i/c++tools/configure
+++ w/c++tools/configure
@@ -2060,6 +2060,8 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL}'
 
 test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
 
+test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
+
 
 ac_ext=cpp
 ac_cpp='$CXXCPP $CPPFLAGS'
diff --git i/c++tools/configure.ac w/c++tools/configure.ac
index 75773650be7..c5560f68d4d 100644
--- i/c++tools/configure.ac
+++ w/c++tools/configure.ac
@@ -32,6 +32,8 @@ ACX_NONCANONICAL_TARGET
 
 AC_CANONICAL_SYSTEM
 AC_PROG_INSTALL
+test -z "$INSTALL_PROGRAM" && INSTALL_PROGRAM='${INSTALL}'
+AC_SUBST(INSTALL_PROGRAM)
 
 AC_PROG_CXX
 MISSING=`cd $ac_aux_dir && ${PWDCMD-pwd}`/missing

Re: c++tools: fix install-strip [PR 98328]

[H.J. Lu via Gcc-patches]

On Wed, Dec 16, 2020 at 11:49 AM Nathan Sidwell  wrote:
>
>
> I'd missed an install-strip rule in c++tools.  Here it is, cribbed
> from gcc/ subdir.
>
>  c++tools/

Missing PR other/98328 here.

>  * Makefile.in (INSTALL): Replace with ...
>  (INSTALL_PROGRAM): ... this.
>  (INSTALL_STRIP_PROGRAM): New.
>  (install-strip): New target.
>  (install): Use INSTALL_PROGRAM.
> * configure.ac: Add INSTALL_PROGRAM.
>  * configure: Regenerated.
>
> pushing to trunk
> --
> Nathan Sidwell



-- 
H.J.

c++: Fix template parm ICE [PR 98297]

[Nathan Sidwell]

I think this is nonsense code, we seem to be naming an instantiation
of a template template parm.  But this fixes the ICE.  Perhaps we
should diagnose the issue earlier?

gcc/cp/
* parser.c (cp_parser_elaborated_type_specifier): Test
BOUND_TEMPLATE_TEMPLATE_PARM before checking for instantiation.
gcc/testsuite/
* g++.dg/template/pr98297.C: New.

pushing to trunk
--
Nathan Sidwell
diff --git c/gcc/cp/parser.c w/gcc/cp/parser.c
index 7ea8c28830e..3883339aa64 100644
--- c/gcc/cp/parser.c
+++ w/gcc/cp/parser.c
@@ -19650,7 +19650,9 @@ cp_parser_elaborated_type_specifier (cp_parser* parser,
   if (TREE_CODE (type) == TYPENAME_TYPE)
 	warning (OPT_Wattributes,
 		 "attributes ignored on uninstantiated type");
-  else if (tag_type != enum_type && CLASSTYPE_TEMPLATE_INSTANTIATION (type)
+  else if (tag_type != enum_type
+	   && TREE_CODE (type) != BOUND_TEMPLATE_TEMPLATE_PARM
+	   && CLASSTYPE_TEMPLATE_INSTANTIATION (type)
 	   && ! processing_explicit_instantiation)
 	warning (OPT_Wattributes,
 		 "attributes ignored on template instantiation");
diff --git c/gcc/testsuite/g++.dg/template/pr98297.C w/gcc/testsuite/g++.dg/template/pr98297.C
new file mode 100644
index 000..0dd63a57b5c
--- /dev/null
+++ w/gcc/testsuite/g++.dg/template/pr98297.C
@@ -0,0 +1,6 @@
+// PR 98297, ICE
+// { dg-do compile { target c++11 } }
+template  class a>
+struct [[b]]
+a ; // { dg-error "does not declare anything" }
+// { dg-warning "ignored" "" { target *-*-* } .-1 }

c++: Another solaris header use [PR 98315]

[Nathan Sidwell]

Rather than early-include sys/socket.h, let's allow the includer to
tell cody no networking.

libcody/
* cody.hh: Allow user to set CODY_NETWORKING.
gcc/cp/
* mapper-resolver.cc: Remove early include of
sys/socket.h.  Specify no CODY_NETWORKING instead.
* module.cc: Specify no CODY_NETWORKING.

pushing to trunk
--
Nathan Sidwell
diff --git i/gcc/cp/mapper-resolver.cc w/gcc/cp/mapper-resolver.cc
index 8e968c52556..53c482441b4 100644
--- i/gcc/cp/mapper-resolver.cc
+++ w/gcc/cp/mapper-resolver.cc
@@ -21,13 +21,9 @@ along with GCC; see the file COPYING3.  If not see
 /* Forward to the resolver in c++tools.  */
 
 #include "config.h"
-#if defined (__unix__)
-// Solaris11's socket header used bcopy, which we poison.  cody.hh
-// will include it later under the above check
-#include 
-#endif
-
 #define INCLUDE_ALGORITHM
 #include "system.h"
 
+// We don't want or need to be aware of networking
+#define CODY_NETWORKING 0
 #include "../../c++tools/resolver.cc"
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index e9ea18636b4..2318489d9d4 100644
--- i/gcc/cp/module.cc
+++ w/gcc/cp/module.cc
@@ -207,7 +207,6 @@ Classes used:
 
 #define _DEFAULT_SOURCE 1 /* To get TZ field of struct tm, if available.  */
 #include "config.h"
-
 #include "system.h"
 #include "coretypes.h"
 #include "cp-tree.h"
@@ -229,6 +228,8 @@ Classes used:
 #include "attribs.h"
 #include "intl.h"
 #include "langhooks.h"
+/* This TU doesn't need or want to see the networking.  */
+#define CODY_NETWORKING 0
 #include "mapper-client.h"
 
 #if HAVE_MMAP_FILE && _POSIX_MAPPED_FILES > 0
diff --git i/libcody/cody.hh w/libcody/cody.hh
index 31d9c182cbe..789ce9e70b7 100644
--- i/libcody/cody.hh
+++ w/libcody/cody.hh
@@ -5,6 +5,9 @@
 #ifndef CODY_HH
 #define CODY_HH 1
 
+// If the user specifies this as non-zero, it must be what we expect,
+// generally only good for requesting no networking
+#if !defined (CODY_NETWORKING)
 // Have a known-good list of networking systems
 #if defined (__unix__) || defined (__MACH__)
 #define CODY_NETWORKING 1
@@ -15,6 +18,7 @@
 #undef CODY_NETWORKING
 #define CODY_NETWORKING 0
 #endif
+#endif
 
 // C++
 #include 

Re: [PATCH] Correct -fdump-go-spec's handling of incomplete types

[Nikhil Benesch via Gcc-patches]

On 12/16/20 2:20 PM, Rainer Orth wrote:

Hi Nikhil,


On 12/15/20 3:00 AM, Nikhil Benesch wrote:

If this patch looks good, I'll submit it upstream tomorrow.


Assuming no news is good news, I sent
https://go-review.googlesource.com/c/gofrontend/+/278672.


sorry for the delay, but unfortunately news is not so good: I get

runtime_sysinfo.go:315:18: error: use of undefined type '_ucontext'
   315 | type _ucontext_t _ucontext
   |  ^


No problem, Rainer. I figured there would be some hiccups. The somewhat good 
news
is that this error appears to be independent of the patch I sent upstream.

I suspect what is happening here is that godump sees "typedef ucontext_t struct
ucontext" and outputs the typedef immediately. Only later does it observe that
"struct ucontext" is invalid. At that point it is too late to comment out the
typedef for _ucontext_t.

Nikhil

[PATCH 2/2]Arm: Add NEON and MVE RTL patterns for Complex Addition.

[Tamar Christina via Gcc-patches]

Hi All,

This adds implementation for the optabs for complex additions.  With this the
following C code:

  void f90 (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
  {
for (int i=0; i < N; i++)
  c[i] = a[i] + (b[i] * I);
  }

generates

  f90:
  add r3, r2, #1600
  .L2:
  vld1.32 {q8}, [r0]!
  vld1.32 {q9}, [r1]!
  vcadd.f32   q8, q8, q9, #90
  vst1.32 {q8}, [r2]!
  cmp r3, r2
  bne .L2
  bx  lr


instead of

  f90:
  add r3, r2, #1600
  .L2:
  vld2.32 {d24-d27}, [r0]!
  vld2.32 {d20-d23}, [r1]!
  vsub.f32  q8, q12, q11
  vadd.f32  q9, q13, q10
  vst2.32 {d16-d19}, [r2]!
  cmp r3, r2
  bne .L2
  bx  lr

Bootstrapped Regtested on arm-none-linux-gnueabihf and no issues.
Codegen tested for -march=armv8.1-m.main+mve.fp -mfloat-abi=hard -mfpu=auto
and no issues.

This is just a splitting of a previously approved patch due to it having a
dependency on the AArch64 bits which have been requested to be reworked.

Will commit under the previous approval.

Thanks,
Tamar

gcc/ChangeLog:

* config/arm/arm_mve.h (__arm_vcaddq_rot90_u8, __arm_vcaddq_rot270_u8,
__arm_vcaddq_rot90_s8, __arm_vcaddq_rot270_s8,
__arm_vcaddq_rot90_u16, __arm_vcaddq_rot270_u16,
__arm_vcaddq_rot90_s16, __arm_vcaddq_rot270_s16,
__arm_vcaddq_rot90_u32, __arm_vcaddq_rot270_u32,
__arm_vcaddq_rot90_s32, __arm_vcaddq_rot270_s32,
__arm_vcaddq_rot90_f16, __arm_vcaddq_rot270_f16,
__arm_vcaddq_rot90_f32, __arm_vcaddq_rot270_f32):  Update builtin calls.
* config/arm/arm_mve_builtins.def (vcaddq_rot90_u, vcaddq_rot270_u,
vcaddq_rot90_s, vcaddq_rot270_s, vcaddq_rot90_f, vcaddq_rot270_f):
Removed.
(vcaddq_rot90, vcaddq_rot270): New.
* config/arm/constraints.md (Dz): Include MVE.
* config/arm/iterators.md (mve_rot): New.
(supf): Remove VCADDQ_ROT270_S, VCADDQ_ROT270_U, VCADDQ_ROT90_S,
VCADDQ_ROT90_U.
(VCADDQ_ROT270, VCADDQ_ROT90): Removed.
* config/arm/mve.md (mve_vcaddq_rot270_, mve_vcaddq_rot270_f,
mve_vcaddq_rot90_f): Removed.
(mve_vcaddq, mve_vcaddq): New.
* config/arm/unspecs.md (VCADDQ_ROT270_S, VCADDQ_ROT90_S,
VCADDQ_ROT270_U, VCADDQ_ROT90_U, VCADDQ_ROT270_F,
VCADDQ_ROT90_F): Removed.
* config/arm/vec-common.md (cadd3): New.

--- inline copy of patch -- 
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 
6c0d1e2e634a32196eb31079166a7733dcd3a4b6..987495dd234ad96ba1163a1f482fe183a46ff437
 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -3981,14 +3981,16 @@ __extension__ extern __inline uint8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot90_u8 (uint8x16_t __a, uint8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot90_uv16qi (__a, __b);
+  return (uint8x16_t)
+__builtin_mve_vcaddq_rot90v16qi ((int8x16_t)__a, (int8x16_t)__b);
 }
 
 __extension__ extern __inline uint8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot270_u8 (uint8x16_t __a, uint8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot270_uv16qi (__a, __b);
+  return (uint8x16_t)
+__builtin_mve_vcaddq_rot270v16qi ((int8x16_t)__a, (int8x16_t)__b);
 }
 
 __extension__ extern __inline uint8x16_t
@@ -4520,14 +4522,14 @@ __extension__ extern __inline int8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot90_s8 (int8x16_t __a, int8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot90_sv16qi (__a, __b);
+  return __builtin_mve_vcaddq_rot90v16qi (__a, __b);
 }
 
 __extension__ extern __inline int8x16_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot270_s8 (int8x16_t __a, int8x16_t __b)
 {
-  return __builtin_mve_vcaddq_rot270_sv16qi (__a, __b);
+  return __builtin_mve_vcaddq_rot270v16qi (__a, __b);
 }
 
 __extension__ extern __inline int8x16_t
@@ -4821,14 +4823,16 @@ __extension__ extern __inline uint16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot90_u16 (uint16x8_t __a, uint16x8_t __b)
 {
-  return __builtin_mve_vcaddq_rot90_uv8hi (__a, __b);
+  return (uint16x8_t)
+__builtin_mve_vcaddq_rot90v8hi ((int16x8_t)__a, (int16x8_t)__b);
 }
 
 __extension__ extern __inline uint16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 __arm_vcaddq_rot270_u16 (uint16x8_t __a, uint16x8_t __b)
 {
-  return __builtin_mve_vcaddq_rot270_uv8hi (__a, __b);
+  return (uint16x8_t)
+__builtin_mve_vcaddq_rot270v8hi ((int16x8_t)__a, (int16x8_t)__b);
 }
 
 __extension__ extern __inline uint16x8_t
@@ -5360,14 +5364,14 @@ __extension__ extern __inline int16x8_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__