Re: [PATCH 2/3] MIPS: use mips_isa enum instead hardcoded numbers

[Xi Ruoyao via Gcc-patches]

On Sat, 2021-08-28 at 08:05 -0400, YunQiang Su wrote:
> Currently mips-cpu.defs and mips.h are using hardcoded numbers
> for isa level.
> 
> Let's replace them with more readable enum mips_isa.

Good, but there is something like "mips_isa_rev >= 32 && mips_isa_rev <
64" in mips.h and netbsd.h.  Not sure if they should be replaced
altogether.

If they are replaced as well, it will be not necessary to set special
enum values.

How do the others think?

> gcc/ChangeLog:
> * config/mips/mips.md: define_enum "mips_isa".
> * config/mips/mips.h (struct mips_cpu_info): use enum
>   instead of int for 'isa' member.
> * config/mips/mips{.h,-cpus.def}: replace hardcoded
>   numbers with enum.
> ---
>  gcc/config/mips/mips-cpus.def | 228 +
> -
>  gcc/config/mips/mips.h    |  50 
>  gcc/config/mips/mips.md   |  17 +++
>  3 files changed, 156 insertions(+), 139 deletions(-)
> 
> diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-
> cpus.def
> index b02294be4..45fb6bc8b 100644
> --- a/gcc/config/mips/mips-cpus.def
> +++ b/gcc/config/mips/mips-cpus.def
> @@ -33,146 +33,146 @@ along with GCC; see the file COPYING3.  If not
> see
>     where the arguments are the fields of struct mips_cpu_info.  */
>  
>  /* Entries for generic ISAs.  */
> -MIPS_CPU ("mips1", PROCESSOR_R3000, 1, 0)
> -MIPS_CPU ("mips2", PROCESSOR_R6000, 2, PTF_AVOID_BRANCHLIKELY_SIZE)
> -MIPS_CPU ("mips3", PROCESSOR_R4000, 3, PTF_AVOID_BRANCHLIKELY_SIZE)
> -MIPS_CPU ("mips4", PROCESSOR_R1, 4, PTF_AVOID_BRANCHLIKELY_SIZE)
> +MIPS_CPU ("mips1", PROCESSOR_R3000, MIPS_ISA_MIPS1, 0)
> +MIPS_CPU ("mips2", PROCESSOR_R6000, MIPS_ISA_MIPS2,
> PTF_AVOID_BRANCHLIKELY_SIZE)
> +MIPS_CPU ("mips3", PROCESSOR_R4000, MIPS_ISA_MIPS3,
> PTF_AVOID_BRANCHLIKELY_SIZE)
> +MIPS_CPU ("mips4", PROCESSOR_R1, MIPS_ISA_MIPS4,
> PTF_AVOID_BRANCHLIKELY_SIZE)
>  /* Prefer not to use branch-likely instructions for generic MIPS32rX
>     and MIPS64rX code.  The instructions were officially deprecated
>     in revisions 2 and earlier, but revision 3 is likely to downgrade
>     that to a recommendation to avoid the instructions in code that
>     isn't tuned to a specific processor.  */
> -MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY_ALWAYS)
> -MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, 33,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips32", PROCESSOR_4KC, MIPS_ISA_MIPS32,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, MIPS_ISA_MIPS32R2,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
>  /* mips32r3 is micromips hense why it uses the M4K processor.  */
> -MIPS_CPU ("mips32r3", PROCESSOR_M4K, 34,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> -MIPS_CPU ("mips32r5", PROCESSOR_P5600, 36,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> -MIPS_CPU ("mips32r6", PROCESSOR_I6400, 37, 0)
> -MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips32r3", PROCESSOR_M4K, MIPS_ISA_MIPS32R3,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips32r5", PROCESSOR_P5600, MIPS_ISA_MIPS32R5,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips32r6", PROCESSOR_I6400, MIPS_ISA_MIPS32R6, 0)
> +MIPS_CPU ("mips64", PROCESSOR_5KC, MIPS_ISA_MIPS64,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
>  /* ??? For now just tune the generic MIPS64r2 and above for 5KC as
> well.   */
> -MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> -MIPS_CPU ("mips64r3", PROCESSOR_5KC, 66,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> -MIPS_CPU ("mips64r5", PROCESSOR_5KC, 68,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> -MIPS_CPU ("mips64r6", PROCESSOR_I6400, 69, 0)
> +MIPS_CPU ("mips64r2", PROCESSOR_5KC, MIPS_ISA_MIPS64R2,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips64r3", PROCESSOR_5KC, MIPS_ISA_MIPS64R3,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips64r5", PROCESSOR_5KC, MIPS_ISA_MIPS64R5,
> PTF_AVOID_BRANCHLIKELY_ALWAYS)
> +MIPS_CPU ("mips64r6", PROCESSOR_I6400, MIPS_ISA_MIPS64R6, 0)
>  
>  /* MIPS I processors.  */
> -MIPS_CPU ("r3000", PROCESSOR_R3000, 1, 0)
> -MIPS_CPU ("r2000", PROCESSOR_R3000, 1, 0)
> -MIPS_CPU ("r3900", PROCESSOR_R3900, 1, 0)
> +MIPS_CPU ("r3000", PROCESSOR_R3000, MIPS_ISA_MIPS1, 0)
> +MIPS_CPU ("r2000", PROCESSOR_R3000, MIPS_ISA_MIPS1, 0)
> +MIPS_CPU ("r3900", PROCESSOR_R3900, MIPS_ISA_MIPS1, 0)
>  
>  /* MIPS II processors.  */
> -MIPS_CPU ("r6000", PROCESSOR_R6000, 2, 0)
> +MIPS_CPU ("r6000", PROCESSOR_R6000, MIPS_ISA_MIPS2, 0)
>  
>  /* MIPS III processors.  */
> -MIPS_CPU ("r4000", PROCESSOR_R4000, 3, 0)
> -MIPS_CPU ("vr4100", PROCESSOR_R4100, 3, 0)
> -MIPS_CPU ("vr4111", PROCESSOR_R4111, 3, 0)
> -MIPS_CPU ("vr4120", PROCESSOR_R4120, 3, 0)
> -MIPS_CPU ("vr4130", PROCESSOR_R4130, 3, 0)
> -MIPS_CPU ("vr4300", PROCESSOR_R4300, 3, 0)
> -MIPS_CPU ("r4400", PROCESSOR_R4000, 3, 0)
> -MIPS_CPU ("r4600", PROCESSOR_R4600, 3, 0)
> -MIPS_CPU ("orion", PROCESSOR_R4600, 3, 0)
> -MIPS_CPU ("r4650", PROCESSOR_R4650, 3, 0)
> -MIPS_CPU ("r4700", PROCESSOR_R4700, 3, 0)
> 

Re: [PATCH 1/3] md/define_c_enum: support value assignation

[Xi Ruoyao via Gcc-patches]

On Sat, 2021-08-28 at 08:05 -0400, YunQiang Su wrote:
> Currently, the enums from define_c_enum and define_enum can only
> has values one by one from 0.
> 
> In fact we can support the behaviour just like C, aka like
>   (define_enum "mips_isa" [mips1=1 mips2 mips32=32 mips32r2]),
> then we can get
>   enum mips_isa {
>     MIPS_ISA_MIPS1 = 1,
>     MIPS_ISA_MIPS2 = 2,
>     MIPS_ISA_MIPS32 = 32,
>     MIPS_ISA_MIPS32R2 = 33
>   };

IMO we can just define the enum in mips.h.  In a private communication
YunQiang has explained he doesn't want to introduce a new large enum at
the top of mips.h though.

How do others think?

> gcc/ChangeLog:
> * read-md.c (md_reader::handle_enum): support value
> assignation.
> * doc/md.texi: record define_c_enum value assignation support.
> ---
>  gcc/doc/md.texi |  4 
>  gcc/read-md.c   | 15 +--
>  2 files changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index f8047aefc..1c1282c4c 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -11074,6 +11074,8 @@ The syntax is as follows:
>  (define_c_enum "@var{name}" [
>    @var{value0}
>    @var{value1}
> +  @var{value32}=32
> +  @var{value33}
>    @dots{}
>    @var{valuen}
>  ])
> @@ -11086,6 +11088,8 @@ in @file{insn-constants.h}:
>  enum @var{name} @{
>    @var{value0} = 0,
>    @var{value1} = 1,
> +  @var{value32} = 32,
> +  @var{value33} = 33,
>    @dots{}
>    @var{valuen} = @var{n}
>  @};
> diff --git a/gcc/read-md.c b/gcc/read-md.c
> index bb419e0f6..43dfbe264 100644
> --- a/gcc/read-md.c
> +++ b/gcc/read-md.c
> @@ -901,7 +901,8 @@ md_decimal_string (int number)
>  void
>  md_reader::handle_enum (file_location loc, bool md_p)
>  {
> -  char *enum_name, *value_name;
> +  char *enum_name, *value_name, *token;
> +  unsigned int cur_value;
>    struct md_name name;
>    struct enum_type *def;
>    struct enum_value *ev;
> @@ -928,6 +929,7 @@ md_reader::handle_enum (file_location loc, bool
> md_p)
>    *slot = def;
>  }
>  
> +  cur_value = def->num_values;
>    require_char_ws ('[');
>  
>    while ((c = read_skip_spaces ()) != ']')
> @@ -945,20 +947,29 @@ md_reader::handle_enum (file_location loc, bool
> md_p)
>    if (md_p)
> {
>   value_name = concat (def->name, "_", name.string, NULL);
> + value_name = strtok (value_name, "=");
> + token = strtok (NULL, "=");
> + if (token)
> +   cur_value = atoi (token);
>   upcase_string (value_name);
>   ev->name = xstrdup (name.string);
> }
>    else
> {
>   value_name = xstrdup (name.string);
> + value_name = strtok (value_name, "=");
> + token = strtok (NULL, "=");
> + if (token)
> +   cur_value = atoi (token);
>   ev->name = value_name;
> }
>    ev->def = add_constant (get_md_constants (), value_name,
> - md_decimal_string (def->num_values),
> def);
> + md_decimal_string (cur_value), def);
>  
>    *def->tail_ptr = ev;
>    def->tail_ptr = >next;
>    def->num_values++;
> +  cur_value++;
>  }
>  }
>  

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Improve merging of modref_access_node

[Jan Hubicka]

Hi,
this should be final bit of the fancy access merging.  We limit number of
accesses to 16 and on the overflow we currently just throw away the whole
table.  This patch instead looks for closest pair of entries in the table and
merge them (losing some precision).  This is not very often during normal gcc
bootstrap, but with -fno-strict-aliasing the overflows are much more common
and happens 272 times (for stuff like our autogenerated param handling).

I hope this may be useful for some real world code that does a lot of array 
manipulations.
Bootstrapped/regtested x86_64-linux, comitted.

Since I produced aliasing stats for cc1plus build with lto-bootstrap and
-fno-strict-aliasing, I am attaching it.

Alias oracle query stats:
  refs_may_alias_p: 73520790 disambiguations, 96898146 queries
  ref_maybe_used_by_call_p: 515551 disambiguations, 74487359 queries
  call_may_clobber_ref_p: 348504 disambiguations, 352504 queries
  nonoverlapping_component_refs_p: 0 disambiguations, 0 queries
  nonoverlapping_refs_since_match_p: 33251 disambiguations, 42895 must 
overlaps, 76905 queries
  aliasing_component_refs_p: 0 disambiguations, 0 queries
  TBAA oracle: 0 disambiguations 128 queries
   0 are in alias set 0
   0 queries asked about the same object
   128 queries asked about the same alias set
   0 access volatile
   0 are dependent in the DAG
   0 are aritificially in conflict with void *

Modref stats:
  modref use: 7260 disambiguations, 640326 queries
  modref clobber: 591264 disambiguations, 20039893 queries
  0 tbaa queries (0.00 per modref query)
  1145567 base compares (0.057164 per modref query)

PTA query stats:
  pt_solution_includes: 13729755 disambiguations, 35737015 queries
  pt_solutions_intersect: 1703678 disambiguations, 13200534 queries

It seems that modref is still quite effective on handling clobbers.

gcc/ChangeLog:

* ipa-modref-tree.h (modref_access_node::merge): Break out
logic combining offsets and logic merging ranges to ...
(modref_access_node::combined_offsets): ... here
(modref_access_node::update2): ... here
(modref_access_node::closer_pair_p): New member function.
(modref_access_node::forced_merge): New member function.
(modre_ref_node::insert): Do merging when table is full.

gcc/testsuite/ChangeLog:

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

diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
index a86e684a030..6a9ed5ce54b 100644
--- a/gcc/ipa-modref-tree.h
+++ b/gcc/ipa-modref-tree.h
@@ -196,8 +196,9 @@ struct GTY(()) modref_access_node
  was prolonged and punt when there are too many.  */
   bool merge (const modref_access_node , bool record_adjustments)
 {
-  poly_int64 aoffset_adj = 0, offset_adj = 0;
-  poly_int64 new_parm_offset = parm_offset;
+  poly_int64 offset1 = 0;
+  poly_int64 aoffset1 = 0;
+  poly_int64 new_parm_offset = 0;
 
   /* We assume that containment was tested earlier.  */
   gcc_checking_assert (!contains (a) && !a.contains (*this));
@@ -209,29 +210,13 @@ struct GTY(()) modref_access_node
{
  if (!a.parm_offset_known)
return false;
- if (known_le (a.parm_offset, parm_offset))
-   {
- offset_adj = (parm_offset - a.parm_offset)
-   << LOG2_BITS_PER_UNIT;
- aoffset_adj = 0;
- new_parm_offset = a.parm_offset;
-   }
- else if (known_le (parm_offset, a.parm_offset))
-   {
- aoffset_adj = (a.parm_offset - parm_offset)
-<< LOG2_BITS_PER_UNIT;
- offset_adj = 0;
-   }
- else
+ if (!combined_offsets (a, _parm_offset, , ))
return false;
}
}
   /* See if we can merge ranges.  */
   if (range_info_useful_p ())
{
- poly_int64 offset1 = offset + offset_adj;
- poly_int64 aoffset1 = a.offset + aoffset_adj;
-
  /* In this case we have containment that should be
 handled earlier.  */
  gcc_checking_assert (a.range_info_useful_p ());
@@ -255,46 +240,211 @@ struct GTY(()) modref_access_node
return false;
  if (known_le (offset1, aoffset1))
{
- if (!known_size_p (max_size))
+ if (!known_size_p (max_size)
+ || known_ge (offset1 + max_size, aoffset1))
{
- update (new_parm_offset, offset1, size, max_size,
- record_adjustments);
- return true;
-   }
- else if (known_ge (offset1 + max_size, aoffset1))
-   {
- poly_int64 new_max_size = max_size;
- if (known_le (max_size, a.max_size + aoffset1 - offset1))
-   

Re: fix latent bootstrap-debug issue (modref, tree-inline, tree jump-threading)

[Jan Hubicka]

> On Aug 22, 2021, Jan Hubicka  wrote:
> 
> > OK, thanks for looking into this issue!
> 
> Thanks, I've finally installed it in the trunk.
> 
> > It seems that analye_stmt indeed does not skip debug stmts.  It is very
> > odd we got so far without hitting build difference.
> 
> Indeed.  That got me thinking...  The comments state:
> 
>  If the statement cannot be analyzed (for any reason), the entire
>  function cannot be analyzed by modref.
> 
> but the implementation also tests, for every statement:
> 
> || ((!summary || !summary->useful_p (ecf_flags, false))
> && (!summary_lto
> || !summary_lto->useful_p (ecf_flags, false
> 
> which means that, if the first stmt of a block doesn't add useful
> information to the summary, we give up.  Was this really the intent?
It is just early exit condition in case we already found enough side
effects to give up on any useful info about loads/stores.
Summaries are computed from optimistic one (function has no side
effects) by becoming more pesimistic as statements are being visited.

So in most cases useful_p is true at the begining of the loop (since we
see now loads/stores).  I suppose we was hitting the difference because
in const functions the summaries can be !useful_p from begining of the
loop.  I guess it is harmless to process the first statement in that
case (if we do not produce debug bootstrap difference)
Honza
> 
> -- 
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCH] Only simplify TRUNCATE to SUBREG on TRULY_NOOP_TRUNCATION targets

[Segher Boessenkool]

Hi!

On Fri, Aug 27, 2021 at 05:20:22PM -0600, Jeff Law via Gcc-patches wrote:
> On 8/27/2021 3:57 PM, Roger Sayle wrote:
> >As recently remarked by Jeff Law, SUBREGs are the "forever chemicals"
> >of GCC's RTL; once created they persist in the environment.  The problem,
> >according to the comment on lines 5428-5438 of combine.c is that
> >non-tieable SUBREGs interfere with reload/register allocation, so
> >combine often doesn't touch/clean-up instructions containing a SUBREG.
> Forever chemicals.  I like that term.

It is a very clever name in its original meaning.  Not only are PFAS and
the like not degraded in the environment, but that is because the F-C
bond is so strong...  the "Forever-Chemical" bond.  Chemists make even
worse puns than compiler developers :-)

SUBREGs are like perfluoralkyls in more ways: they have huge problems,
but there is no real replacement for them either.

> >Alas currently, during combine the middle TRUNCATE is converted into
> >a lowpart SUBREG, which subst then turns into (clobber (const_int 0)),
> >abandoning the attempted combination, that then never reaches recog.

Yeah, combine notices it can optimise away the TRUNCATE (a SUBREG is
free, is just a reinterpret_cast thingy, no machine operation).  With
this code disabled (for !TRULY_NOOP_TRUNCATION_MODES_P) you will get
less optimised code.

> >But it only affects !TRULY_NOOP_TRUNCATION targets, and the motivating
> >example above is derived from the behaviour of backend patches not yet
> >in the tree [nvptx is currently a STORE_FLAG_VALUE=-1 target].

Should the TARGET_TRULY_NOOP_TRUNCATION documentation be updated now?
In particular the part that talks about TARGET_MODES_TIEABLE_P.


Segher

[committed] libstdc++: Fix std::allocator for versioned namespace

[Jonathan Wakely via Gcc-patches]

Removing the allocator specialization for the versioned namespace
breaks _Extptr_allocator because the allocator
specialization was still declared in , making it an
incomplete type.  It wrong to remove that specialization anyway, because
it is still needed pre-C++20.

This removes the #if ! _GLIBCXX_INLINE_VERSION check, so that
allocator is still explicitly specialized for the versioned
namespace, consistent with the normal unversioned namespace mode.

To make _Extptr_allocator usable as a ProtoAllocator, this change
adds a default constructor and converting constructor. That is
consistent with std::allocator since C++20 (and harmless to do for
earlier standards).

I'm also explicitly specializing allocator_traits> so
that it doesn't need to use allocator::construct and destroy.
Doing that allows those members to be removed, further simplifying
allocator.  That new explicit specialization can delete the
allocate, deallocate and max_size members, which are always ill-formed
for allocator.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* include/bits/alloc_traits.h (allocator_traits): Add explicit
specialization for allocator. Improve doxygen comments.
* include/bits/allocator.h (allocator): Restore for the
versioned namespace.
(allocator::construct, allocator::destroy): Remove.
* include/ext/extptr_allocator.h (_Extptr_allocator):
Add default constructor and converting constructor.

Tested powerpc64le-linux. Committed to trunk.

commit 754fca77e82a59d85c735a5aff49ee2b1ec4c6df
Author: Jonathan Wakely 
Date:   Sat Aug 28 11:05:58 2021

libstdc++: Fix std::allocator for versioned namespace

Removing the allocator specialization for the versioned namespace
breaks _Extptr_allocator because the allocator
specialization was still declared in , making it an
incomplete type.  It wrong to remove that specialization anyway, because
it is still needed pre-C++20.

This removes the #if ! _GLIBCXX_INLINE_VERSION check, so that
allocator is still explicitly specialized for the versioned
namespace, consistent with the normal unversioned namespace mode.

To make _Extptr_allocator usable as a ProtoAllocator, this change
adds a default constructor and converting constructor. That is
consistent with std::allocator since C++20 (and harmless to do for
earlier standards).

I'm also explicitly specializing allocator_traits> so
that it doesn't need to use allocator::construct and destroy.
Doing that allows those members to be removed, further simplifying
allocator.  That new explicit specialization can delete the
allocate, deallocate and max_size members, which are always ill-formed
for allocator.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* include/bits/alloc_traits.h (allocator_traits): Add explicit
specialization for allocator. Improve doxygen comments.
* include/bits/allocator.h (allocator): Restore for the
versioned namespace.
(allocator::construct, allocator::destroy): Remove.
* include/ext/extptr_allocator.h (_Extptr_allocator):
Add default constructor and converting constructor.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h 
b/libstdc++-v3/include/bits/alloc_traits.h
index 34412583064..05b584f742f 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -559,6 +559,110 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return __rhs; }
 };
 
+  /// Explicit specialization for std::allocator.
+  template<>
+struct allocator_traits>
+{
+  /// The allocator type
+  using allocator_type = allocator;
+
+  /// The allocated type
+  using value_type = void;
+
+  /// The allocator's pointer type.
+  using pointer = void*;
+
+  /// The allocator's const pointer type.
+  using const_pointer = const void*;
+
+  /// The allocator's void pointer type.
+  using void_pointer = void*;
+
+  /// The allocator's const void pointer type.
+  using const_void_pointer = const void*;
+
+  /// The allocator's difference type
+  using difference_type = std::ptrdiff_t;
+
+  /// The allocator's size type
+  using size_type = std::size_t;
+
+  /// How the allocator is propagated on copy assignment
+  using propagate_on_container_copy_assignment = false_type;
+
+  /// How the allocator is propagated on move assignment
+  using propagate_on_container_move_assignment = true_type;
+
+  /// How the allocator is propagated on swap
+  using propagate_on_container_swap = false_type;
+
+  /// Whether all instances of the allocator type compare equal.
+  using is_always_equal = true_type;
+
+  template
+   using rebind_alloc = allocator<_Up>;
+
+  template
+   using rebind_traits = allocator_traits>;
+
+  /// 

[PATCH v2] libffi: Fix MIPS r6 support

[YunQiang Su]

for some instructions, MIPS r6 uses different encoding other than
the previous releases.

1. mips/n32.S disable .set mips4: since it casuses old insn encoding
   is used.
   https://github.com/libffi/libffi/pull/396 has been accepted as:
 94c102aa69b04337f63498e0e6551fcdce549ae5
2. mips/ffi.c: the encoding for JR is hardcoded: we need to use
   different value for r6 and pre-r6.
   https://github.com/libffi/libffi/pull/401 has been accpeted as:
 746dbe3a6a79a41931c03b51df2972be4d5e5028

libffi/
PR libffi/83636
* src/mips/n32.S: disable .set mips4
* src/mips/ffi.c: use different JR encoding for r6.
---
 libffi/src/mips/ffi.c | 8 
 libffi/src/mips/n32.S | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/libffi/src/mips/ffi.c b/libffi/src/mips/ffi.c
index 5d0dd70cb..ecd783a56 100644
--- a/libffi/src/mips/ffi.c
+++ b/libffi/src/mips/ffi.c
@@ -698,7 +698,11 @@ ffi_prep_closure_loc (ffi_closure *closure,
   /* lui  $12,high(codeloc) */
   tramp[2] = 0x3c0c | ((unsigned)codeloc >> 16);
   /* jr   $25  */
+#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
   tramp[3] = 0x0328;
+#else
+  tramp[3] = 0x0329;
+#endif
   /* ori  $12,low(codeloc)  */
   tramp[4] = 0x358c | ((unsigned)codeloc & 0x);
 #else
@@ -726,7 +730,11 @@ ffi_prep_closure_loc (ffi_closure *closure,
   /* ori  $25,low(fn)  */
   tramp[10] = 0x3739 | ((unsigned long)fn  & 0x);
   /* jr   $25  */
+#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
   tramp[11] = 0x0328;
+#else
+  tramp[11] = 0x0329;
+#endif
   /* ori  $12,low(codeloc)  */
   tramp[12] = 0x358c | ((unsigned long)codeloc & 0x);
 
diff --git a/libffi/src/mips/n32.S b/libffi/src/mips/n32.S
index c6985d30a..06e6c4607 100644
--- a/libffi/src/mips/n32.S
+++ b/libffi/src/mips/n32.S
@@ -43,7 +43,9 @@
 #ifdef __GNUC__
.abicalls
 #endif
+#if !defined(__mips_isa_rev) || (__mips_isa_rev<6)
.set mips4
+#endif
.text
.align  2
.globl  ffi_call_N32
-- 
2.30.2

[committed] libstdc++: Fix inefficiency in filesystem::absolute [PR99876]

[Jonathan Wakely via Gcc-patches]

When the path is already absolute, the call to current_path() is
wasteful, because operator/ will ignore the left operand anyway.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/99876
* src/c++17/fs_ops.cc (fs::absolute): Call non-throwing form,
to avoid unnecessary current_path() call.

Tested powerpc64le-linux. Committed to trunk.

I'll backport to gcc-10 and gcc-11 too.


commit 07b990ee23e0c7a92d362dbb25fd5d57d95eb8be
Author: Jonathan Wakely 
Date:   Fri Aug 27 10:59:54 2021

libstdc++: Fix inefficiency in filesystem::absolute [PR99876]

When the path is already absolute, the call to current_path() is
wasteful, because operator/ will ignore the left operand anyway.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/99876
* src/c++17/fs_ops.cc (fs::absolute): Call non-throwing form,
to avoid unnecessary current_path() call.

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 0e2d952673f..2eac9977785 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -65,19 +65,12 @@ namespace posix = std::filesystem::__gnu_posix;
 fs::path
 fs::absolute(const path& p)
 {
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
   error_code ec;
   path ret = absolute(p, ec);
   if (ec)
 _GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot make absolute path", p,
 ec));
   return ret;
-#else
-  if (p.empty())
-_GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot make absolute path", p,
- make_error_code(std::errc::invalid_argument)));
-  return current_path() / p;
-#endif
 }
 
 fs::path

Re: [PATCH] libffi: Fix MIPS r6 support

[YunQiang Su]

Xi Ruoyao via Gcc-patches  于2021年8月28日周六 下午3:25写道：
>
> On Fri, 2021-08-27 at 15:28 -0600, Jeff Law via Gcc-patches wrote:
> >
> >
> > On 8/26/2021 10:58 PM, YunQiang Su wrote:
> > > for some instructions, MIPS r6 uses different encoding other than
> > > the previous releases.
> > >
> > > 1. mips/n32.S disable .set mips4: since it casuses old insn encoding
> > > is used.
> > > https://github.com/libffi/libffi/pull/396
> > > 2. mips/ffi.c: the encoding for JR is hardcoded: we need to use
> > > different value for r6 and pre-r6.
> > > https://github.com/libffi/libffi/pull/401
> > >
> > > libffi/
> > > PR libffi/83636
> > > * src/mips/n32.S: disable .set mips4
> > > * src/mips/ffi.c: use different JR encoding for r6.
> > These should go to the upstream libffi project.  Once accepted there
> > you
> > can add them to GCC.
>
> Hi Jeff,
>
> The two PRs are already merged, and released since libffi-3.3.0 (now the
> upstream latest release is 3.4.2).
>
> I don't have a MIPSr6 so I can't test though.
>

We do have a qemu tarball. Please see:
Debian: http://58.246.137.130:20180/README.txt
Arch: http://58.246.137.130:20180/archlinux/dist/

> YunQiang: the commit message should mention the commit SHA in upstream
> libffi repo's main branch, instead of a URL to PR.  You can use "git
> log" in gcc repo and search for commits for libffi and learn from it.
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University
>

Re: [committed] libstdc++: Avoid a move in std::function construction (LWG 2447)

[Jonathan Wakely via Gcc-patches]

On 27/08/21 00:13 +0100, Jonathan Wakely wrote:

This makes the std::function constructor use perfect forwarding, to
avoid an unnecessary move-construction of the target. This means we need
to rewrite the _Function_base::_Base_manager::_M_init_functor function
to use a forwarding reference, and so can reuse it for the clone
operation.

Also simplify the SFINAE constraints on the constructor, by combining
the !is_same_v, function> constraint into the
_Callable trait.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* include/bits/std_function.h (_function_base::_Base_manager):
Replace _M_init_functor with a function template using a
forwarding reference, and a pair of _M_create function
templates. Reuse _M_create for the clone operation.
(function::_Decay_t): New alias template.
(function::_Callable): Simplify by using _Decay.
(function::function(F)): Change parameter to forwarding
reference, as per LWG 2447. Add noexcept-specifier. Simplify
constraints.
(function::operator=(F&&)): Add noexcept-specifier.
* testsuite/20_util/function/cons/lwg2774.cc: New test.
* testsuite/20_util/function/cons/noexcept.cc: New test.



This makes the new static_asserts give a slightly nicer error message
that doesn't involve .

Tested powerpc64le-linux. Committed to trunk.

commit 952095bb053cfef47b48cc4345d658b8d8829800
Author: Jonathan Wakely 
Date:   Fri Aug 27 00:20:31 2021

libstdc++: Name std::function template parameter

This avoids "" being shown in the diagnostics
for ill-formed uses of std::function constructor:

In instantiation of 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&)
[with _Functor = f(f()::_Z1fv.frame*)::;
 = void; _Res = void; _ArgTypes = {}]'

Instead we get:

In instantiation of 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&)
[with _Functor = f(f()::_Z1fv.frame*)::;
_Constraints = void; _Res = void; _ArgTypes = {}]'

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* include/bits/std_function.h (function::function(F&&)): Give
name to defaulted template parameter, to improve diagnostics.
Use markdown for more doxygen comments.

diff --git a/libstdc++-v3/include/bits/std_function.h b/libstdc++-v3/include/bits/std_function.h
index 82c932e0db5..3dda820bd1a 100644
--- a/libstdc++-v3/include/bits/std_function.h
+++ b/libstdc++-v3/include/bits/std_function.h
@@ -326,10 +326,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { };
 
   /**
-   *  @brief Primary class template for std::function.
+   *  @brief Polymorphic function wrapper.
*  @ingroup functors
-   *
-   *  Polymorphic function wrapper.
+   *  @since C++11
*/
   template
 class function<_Res(_ArgTypes...)>
@@ -364,7 +363,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   /**
*  @brief Default construct creates an empty function call wrapper.
-   *  @post @c !(bool)*this
+   *  @post `!(bool)*this`
*/
   function() noexcept
   : _Function_base() { }
@@ -379,10 +378,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /**
*  @brief %Function copy constructor.
*  @param __x A %function object with identical call signature.
-   *  @post @c bool(*this) == bool(__x)
+   *  @post `bool(*this) == bool(__x)`
*
-   *  The newly-created %function contains a copy of the target of @a
-   *  __x (if it has one).
+   *  The newly-created %function contains a copy of the target of
+   *  `__x` (if it has one).
*/
   function(const function& __x)
   : _Function_base()
@@ -399,7 +398,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  @brief %Function move constructor.
*  @param __x A %function object rvalue with identical call signature.
*
-   *  The newly-created %function contains the target of @a __x
+   *  The newly-created %function contains the target of `__x`
*  (if it has one).
*/
   function(function&& __x) noexcept
@@ -418,22 +417,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  @brief Builds a %function that targets a copy of the incoming
*  function object.
*  @param __f A %function object that is callable with parameters of
-   *  type @c T1, @c T2, ..., @c TN and returns a value convertible
-   *  to @c Res.
+   *  type `ArgTypes...` and returns a value convertible to `Res`.
*
*  The newly-created %function object will target a copy of
-   *  @a __f. If @a __f is @c reference_wrapper, then this function
-   *  object will contain a reference to the function object @c
-   *  __f.get(). If @a __f is a NULL function pointer or NULL
-   *  pointer-to-member, the newly-created object will be empty.
+   *  `__f`. If `__f` is `reference_wrapper`, then this function
+   *  object will contain a reference to the 

[PATCH 3/3] MIPS: add .module mipsREV to all output asm file

[YunQiang Su]

Currently, the asm output file for MIPS has no rev info.
It can make some trouble, for example:
  assembler is mips1 by default,
  gcc is fpxx by default.
To assemble the output of gcc -S, we have to pass -mips2
to assembler.

gcc/ChangeLog:

* gcc/config/mips/mips.c (mips_module_isa_name): New.
mips_file_start: add .module mipsREV to all asm output
---
 gcc/config/mips/mips.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 2f7ffe846..b344cf3fc 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -9841,6 +9841,44 @@ mips_mdebug_abi_name (void)
 }
 }
 
+static const char *
+mips_module_isa_name ()
+{
+  switch (mips_isa)
+{
+case MIPS_ISA_MIPS1:
+  return "mips1";
+case MIPS_ISA_MIPS2:
+  return "mips2";
+case MIPS_ISA_MIPS3:
+  return "mips3";
+case MIPS_ISA_MIPS4:
+  return "mips4";
+case MIPS_ISA_MIPS32:
+  return "mips32";
+case MIPS_ISA_MIPS32R2:
+  return "mips32r2";
+case MIPS_ISA_MIPS32R3:
+  return "mips32r3";
+case MIPS_ISA_MIPS32R5:
+  return "mips32r5";
+case MIPS_ISA_MIPS32R6:
+  return "mips32r6";
+case MIPS_ISA_MIPS64:
+  return "mips64";
+case MIPS_ISA_MIPS64R2:
+  return "mips64r2";
+case MIPS_ISA_MIPS64R3:
+  return "mips64r3";
+case MIPS_ISA_MIPS64R5:
+  return "mips64r5";
+case MIPS_ISA_MIPS64R6:
+  return "mips64r6";
+default:
+  gcc_unreachable ();
+}
+}
+
 /* Implement TARGET_ASM_FILE_START.  */
 
 static void
@@ -9873,6 +9911,9 @@ mips_file_start (void)
 mips_nan == MIPS_IEEE_754_2008 ? "2008" : "legacy");
 
 #ifdef HAVE_AS_DOT_MODULE
+  fprintf (asm_out_file, "\t.module\t%s\n",
+  mips_module_isa_name ());
+
   /* Record the FP ABI.  See below for comments.  */
   if (TARGET_NO_FLOAT)
 #ifdef HAVE_AS_GNU_ATTRIBUTE
-- 
2.30.2

[PATCH 2/3] MIPS: use mips_isa enum instead hardcoded numbers

[YunQiang Su]

Currently mips-cpu.defs and mips.h are using hardcoded numbers
for isa level.

Let's replace them with more readable enum mips_isa.

gcc/ChangeLog:
* config/mips/mips.md: define_enum "mips_isa".
* config/mips/mips.h (struct mips_cpu_info): use enum
  instead of int for 'isa' member.
* config/mips/mips{.h,-cpus.def}: replace hardcoded
  numbers with enum.
---
 gcc/config/mips/mips-cpus.def | 228 +-
 gcc/config/mips/mips.h|  50 
 gcc/config/mips/mips.md   |  17 +++
 3 files changed, 156 insertions(+), 139 deletions(-)

diff --git a/gcc/config/mips/mips-cpus.def b/gcc/config/mips/mips-cpus.def
index b02294be4..45fb6bc8b 100644
--- a/gcc/config/mips/mips-cpus.def
+++ b/gcc/config/mips/mips-cpus.def
@@ -33,146 +33,146 @@ along with GCC; see the file COPYING3.  If not see
where the arguments are the fields of struct mips_cpu_info.  */
 
 /* Entries for generic ISAs.  */
-MIPS_CPU ("mips1", PROCESSOR_R3000, 1, 0)
-MIPS_CPU ("mips2", PROCESSOR_R6000, 2, PTF_AVOID_BRANCHLIKELY_SIZE)
-MIPS_CPU ("mips3", PROCESSOR_R4000, 3, PTF_AVOID_BRANCHLIKELY_SIZE)
-MIPS_CPU ("mips4", PROCESSOR_R1, 4, PTF_AVOID_BRANCHLIKELY_SIZE)
+MIPS_CPU ("mips1", PROCESSOR_R3000, MIPS_ISA_MIPS1, 0)
+MIPS_CPU ("mips2", PROCESSOR_R6000, MIPS_ISA_MIPS2, 
PTF_AVOID_BRANCHLIKELY_SIZE)
+MIPS_CPU ("mips3", PROCESSOR_R4000, MIPS_ISA_MIPS3, 
PTF_AVOID_BRANCHLIKELY_SIZE)
+MIPS_CPU ("mips4", PROCESSOR_R1, MIPS_ISA_MIPS4, 
PTF_AVOID_BRANCHLIKELY_SIZE)
 /* Prefer not to use branch-likely instructions for generic MIPS32rX
and MIPS64rX code.  The instructions were officially deprecated
in revisions 2 and earlier, but revision 3 is likely to downgrade
that to a recommendation to avoid the instructions in code that
isn't tuned to a specific processor.  */
-MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY_ALWAYS)
-MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, 33, PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips32", PROCESSOR_4KC, MIPS_ISA_MIPS32, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips32r2", PROCESSOR_74KF2_1, MIPS_ISA_MIPS32R2, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
 /* mips32r3 is micromips hense why it uses the M4K processor.  */
-MIPS_CPU ("mips32r3", PROCESSOR_M4K, 34, PTF_AVOID_BRANCHLIKELY_ALWAYS)
-MIPS_CPU ("mips32r5", PROCESSOR_P5600, 36, PTF_AVOID_BRANCHLIKELY_ALWAYS)
-MIPS_CPU ("mips32r6", PROCESSOR_I6400, 37, 0)
-MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips32r3", PROCESSOR_M4K, MIPS_ISA_MIPS32R3, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips32r5", PROCESSOR_P5600, MIPS_ISA_MIPS32R5, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips32r6", PROCESSOR_I6400, MIPS_ISA_MIPS32R6, 0)
+MIPS_CPU ("mips64", PROCESSOR_5KC, MIPS_ISA_MIPS64, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
 /* ??? For now just tune the generic MIPS64r2 and above for 5KC as well.   */
-MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY_ALWAYS)
-MIPS_CPU ("mips64r3", PROCESSOR_5KC, 66, PTF_AVOID_BRANCHLIKELY_ALWAYS)
-MIPS_CPU ("mips64r5", PROCESSOR_5KC, 68, PTF_AVOID_BRANCHLIKELY_ALWAYS)
-MIPS_CPU ("mips64r6", PROCESSOR_I6400, 69, 0)
+MIPS_CPU ("mips64r2", PROCESSOR_5KC, MIPS_ISA_MIPS64R2, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips64r3", PROCESSOR_5KC, MIPS_ISA_MIPS64R3, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips64r5", PROCESSOR_5KC, MIPS_ISA_MIPS64R5, 
PTF_AVOID_BRANCHLIKELY_ALWAYS)
+MIPS_CPU ("mips64r6", PROCESSOR_I6400, MIPS_ISA_MIPS64R6, 0)
 
 /* MIPS I processors.  */
-MIPS_CPU ("r3000", PROCESSOR_R3000, 1, 0)
-MIPS_CPU ("r2000", PROCESSOR_R3000, 1, 0)
-MIPS_CPU ("r3900", PROCESSOR_R3900, 1, 0)
+MIPS_CPU ("r3000", PROCESSOR_R3000, MIPS_ISA_MIPS1, 0)
+MIPS_CPU ("r2000", PROCESSOR_R3000, MIPS_ISA_MIPS1, 0)
+MIPS_CPU ("r3900", PROCESSOR_R3900, MIPS_ISA_MIPS1, 0)
 
 /* MIPS II processors.  */
-MIPS_CPU ("r6000", PROCESSOR_R6000, 2, 0)
+MIPS_CPU ("r6000", PROCESSOR_R6000, MIPS_ISA_MIPS2, 0)
 
 /* MIPS III processors.  */
-MIPS_CPU ("r4000", PROCESSOR_R4000, 3, 0)
-MIPS_CPU ("vr4100", PROCESSOR_R4100, 3, 0)
-MIPS_CPU ("vr4111", PROCESSOR_R4111, 3, 0)
-MIPS_CPU ("vr4120", PROCESSOR_R4120, 3, 0)
-MIPS_CPU ("vr4130", PROCESSOR_R4130, 3, 0)
-MIPS_CPU ("vr4300", PROCESSOR_R4300, 3, 0)
-MIPS_CPU ("r4400", PROCESSOR_R4000, 3, 0)
-MIPS_CPU ("r4600", PROCESSOR_R4600, 3, 0)
-MIPS_CPU ("orion", PROCESSOR_R4600, 3, 0)
-MIPS_CPU ("r4650", PROCESSOR_R4650, 3, 0)
-MIPS_CPU ("r4700", PROCESSOR_R4700, 3, 0)
-MIPS_CPU ("r5900", PROCESSOR_R5900, 3, 0)
+MIPS_CPU ("r4000", PROCESSOR_R4000, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("vr4100", PROCESSOR_R4100, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("vr4111", PROCESSOR_R4111, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("vr4120", PROCESSOR_R4120, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("vr4130", PROCESSOR_R4130, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("vr4300", PROCESSOR_R4300, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("r4400", PROCESSOR_R4000, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("r4600", PROCESSOR_R4600, MIPS_ISA_MIPS3, 0)
+MIPS_CPU ("orion", 

[PATCH 1/3] md/define_c_enum: support value assignation

[YunQiang Su]

Currently, the enums from define_c_enum and define_enum can only
has values one by one from 0.

In fact we can support the behaviour just like C, aka like
  (define_enum "mips_isa" [mips1=1 mips2 mips32=32 mips32r2]),
then we can get
  enum mips_isa {
MIPS_ISA_MIPS1 = 1,
MIPS_ISA_MIPS2 = 2,
MIPS_ISA_MIPS32 = 32,
MIPS_ISA_MIPS32R2 = 33
  };

gcc/ChangeLog:
* read-md.c (md_reader::handle_enum): support value assignation.
* doc/md.texi: record define_c_enum value assignation support.
---
 gcc/doc/md.texi |  4 
 gcc/read-md.c   | 15 +--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index f8047aefc..1c1282c4c 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -11074,6 +11074,8 @@ The syntax is as follows:
 (define_c_enum "@var{name}" [
   @var{value0}
   @var{value1}
+  @var{value32}=32
+  @var{value33}
   @dots{}
   @var{valuen}
 ])
@@ -11086,6 +11088,8 @@ in @file{insn-constants.h}:
 enum @var{name} @{
   @var{value0} = 0,
   @var{value1} = 1,
+  @var{value32} = 32,
+  @var{value33} = 33,
   @dots{}
   @var{valuen} = @var{n}
 @};
diff --git a/gcc/read-md.c b/gcc/read-md.c
index bb419e0f6..43dfbe264 100644
--- a/gcc/read-md.c
+++ b/gcc/read-md.c
@@ -901,7 +901,8 @@ md_decimal_string (int number)
 void
 md_reader::handle_enum (file_location loc, bool md_p)
 {
-  char *enum_name, *value_name;
+  char *enum_name, *value_name, *token;
+  unsigned int cur_value;
   struct md_name name;
   struct enum_type *def;
   struct enum_value *ev;
@@ -928,6 +929,7 @@ md_reader::handle_enum (file_location loc, bool md_p)
   *slot = def;
 }
 
+  cur_value = def->num_values;
   require_char_ws ('[');
 
   while ((c = read_skip_spaces ()) != ']')
@@ -945,20 +947,29 @@ md_reader::handle_enum (file_location loc, bool md_p)
   if (md_p)
{
  value_name = concat (def->name, "_", name.string, NULL);
+ value_name = strtok (value_name, "=");
+ token = strtok (NULL, "=");
+ if (token)
+   cur_value = atoi (token);
  upcase_string (value_name);
  ev->name = xstrdup (name.string);
}
   else
{
  value_name = xstrdup (name.string);
+ value_name = strtok (value_name, "=");
+ token = strtok (NULL, "=");
+ if (token)
+   cur_value = atoi (token);
  ev->name = value_name;
}
   ev->def = add_constant (get_md_constants (), value_name,
- md_decimal_string (def->num_values), def);
+ md_decimal_string (cur_value), def);
 
   *def->tail_ptr = ev;
   def->tail_ptr = >next;
   def->num_values++;
+  cur_value++;
 }
 }
 
-- 
2.30.2

[PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

[nick huang via Gcc-patches]

Reference with cv-qualifiers should be ignored instead of causing an error 
because standard accepts cv-qualified references introduced by typedef which 
is ignored.
Therefore, the fix prevents GCC from reporting error by not setting variable
"bad_quals" in case the reference is introduced by typedef. Still the 
cv-qualifier is silently ignored. 
Here I quote spec (https://timsong-cpp.github.io/cppwp/dcl.ref#1):
"Cv-qualified references are ill-formed except when the cv-qualifiers
are introduced through the use of a typedef-name ([dcl.typedef],
[temp.param]) or decltype-specifier ([dcl.type.decltype]),
in which case the cv-qualifiers are ignored."

PR c++/101783

gcc/cp/ChangeLog:

2021-08-27  qingzhe huang  

* tree.c (cp_build_qualified_type_real):

gcc/testsuite/ChangeLog:

2021-08-27  qingzhe huang  

* g++.dg/parse/pr101783.C: New test.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 8840932dba2..7aa4318a574 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1356,12 +1356,22 @@ cp_build_qualified_type_real (tree type,
   /* A reference or method type shall not be cv-qualified.
  [dcl.ref], [dcl.fct].  This used to be an error, but as of DR 295
  (in CD1) we always ignore extra cv-quals on functions.  */
+
+  /* PR 101783
+ Cv-qualified references are ill-formed except when the cv-qualifiers
+ are introduced through the use of a typedef-name ([dcl.typedef],
+ [temp.param]) or decltype-specifier ([dcl.type.decltype]),
+ in which case the cv-qualifiers are ignored.
+   */
   if (type_quals & (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE)
   && (TYPE_REF_P (type)
  || FUNC_OR_METHOD_TYPE_P (type)))
 {
-  if (TYPE_REF_P (type))
+  // do NOT set bad_quals when non-method reference is introduced by 
typedef.
+  if (TYPE_REF_P (type)
+ && (!typedef_variant_p (type) || FUNC_OR_METHOD_TYPE_P (type)))
bad_quals |= type_quals & (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
+  // non-method reference introduced by typedef is also dropped silently
   type_quals &= ~(TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
 }
 
diff --git a/gcc/testsuite/g++.dg/parse/pr101783.C 
b/gcc/testsuite/g++.dg/parse/pr101783.C
new file mode 100644
index 000..4e0a435dd0b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/pr101783.C
@@ -0,0 +1,5 @@
+template struct A{
+typedef T& Type;
+};
+template void f(const typename A::Type){}
+template <> void f(const typename A::Type){}

Re: [PATCH] Fix inline versioned namespace bootstrap

[Jonathan Wakely via Gcc-patches]

On Sat, 28 Aug 2021 at 10:26, Jonathan Wakely  wrote:
>
> On Fri, 27 Aug 2021 at 22:17, Jonathan Wakely  wrote:
> >
> > On Fri, 27 Aug 2021 at 21:58, François Dumont via Libstdc++
> >  wrote:
> > >
> > > Since std::allocator is not specialized anymore in
> > > _GLIBCXX_INLINE_VERSION mode _ExtPtr_allocator specialization do
> > > not compile
> > >
> > > because std::allocator is incomplete.
> >
> > That doesn't look right ... it should be complete. This suggests there
> > is a deeper problem, which I'll look into.
>
> This is the correct fix:
>
> --- a/libstdc++-v3/include/bits/memoryfwd.h
> +++ b/libstdc++-v3/include/bits/memoryfwd.h
> @@ -63,8 +63,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   template
> class allocator;
>
> +#if ! _GLIBCXX_INLINE_VERSION
>   template<>
> class allocator;
> +#endif
>
> #if __cplusplus >= 201103L
>   /// Declare uses_allocator so it can be specialized in `` etc.


Actually, the allocator specialization is still needed for
pre-C++20 with the versioned namespace, and that means there's the
same trivial default ctor ABI concern for the versioned namespace. I'm
testing a fix now, but it might not be committed until I'm back at
work on Tuesday.

Re: [PATCH] Fix inline versioned namespace bootstrap

[Jonathan Wakely via Gcc-patches]

On Fri, 27 Aug 2021 at 22:17, Jonathan Wakely  wrote:
>
> On Fri, 27 Aug 2021 at 21:58, François Dumont via Libstdc++
>  wrote:
> >
> > Since std::allocator is not specialized anymore in
> > _GLIBCXX_INLINE_VERSION mode _ExtPtr_allocator specialization do
> > not compile
> >
> > because std::allocator is incomplete.
>
> That doesn't look right ... it should be complete. This suggests there
> is a deeper problem, which I'll look into.

This is the correct fix:

--- a/libstdc++-v3/include/bits/memoryfwd.h
+++ b/libstdc++-v3/include/bits/memoryfwd.h
@@ -63,8 +63,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  template
class allocator;

+#if ! _GLIBCXX_INLINE_VERSION
  template<>
class allocator;
+#endif

#if __cplusplus >= 201103L
  /// Declare uses_allocator so it can be specialized in `` etc.




>
>
> >
> > So I think primary _ExtPtr_allocator template should also be prefered in
> > _GLIBCXX_INLINE_VERSION mode.
>
> I think it should always be preferred. The _ExtPtr_allocator
> specialization is useless, it is missing the converting constructor
> that would be needed to convert to/from that type to any other
> _ExtPtr_allocator specialization.

Re: [PATCH v2] [MIPS]: add .module mipsREV to all output asm file

[YunQiang Su]

Xi Ruoyao via Gcc-patches  于2021年8月28日周六 下午3:09写道：
>
> On Fri, 2021-08-27 at 15:36 -0600, Jeff Law wrote:
>
> > It's easier when someone has to debug the code later.
> > enums show up in debug output by default, while #defines do not.
>
> > >
> > > switch (mips_isa)
> > >{
> > >  case MIPS_ISA_MIPS1: return "mips1";
> > >  // ...
> > >}
> > >
> > > It looks better, and (maybe) generates better code.  Just my 2 cents
> > > though.
>
> > Coding standards would have that as
> >
> > switch (mips_isa)
> >{
> >case MIPS_ISA_MIPS_1:
> >  return "mips1";
> >...
> >}
>
> There is some existing code using "case ... : return ..." in one line in
> mips.c, so I thought it was standard :(.
>
> > Presumably .module is supported by all reasonably modern versions of
> > GAS?
>
> It's added by the commit in binutils-gdb:
>
> > commit 919731affbef19fcad8dddb0a595bb05755cb345
> > Author: mfortune 
> > Date:   Tue May 20 13:28:20 2014 +0100
> >
> > Add MIPS .module directive
> >
>
> So it should be supported since binutils-2.25.
>
> If we want to support old binutils we'll need something like "-fno-mips-
> module-directive" and "--without-mips-module-directive".  My suggestion
> is just bumping the binutils requirement for mips*-*-*.
>

There is a macro, HAVE_AS_DOT_MODULE, so that we can just use it.

#ifdef HAVE_AS_DOT_MODULE
  /* Record the FP ABI.  See below for comments.  */
  if (TARGET_NO_FLOAT)
#ifdef HAVE_AS_GNU_ATTRIBUTE
fputs ("\t.gnu_attribute 4, 0\n", asm_out_file);
#else
;
#endif
  else if (!TARGET_HARD_FLOAT_ABI)
fputs ("\t.module\tsoftfloat\n", asm_out_file);
  else if (!TARGET_DOUBLE_FLOAT)
fputs ("\t.module\tsinglefloat\n", asm_out_file);
  else if (TARGET_FLOATXX)
fputs ("\t.module\tfp=xx\n", asm_out_file);
  else if (TARGET_FLOAT64)
fputs ("\t.module\tfp=64\n", asm_out_file);
  else
fputs ("\t.module\tfp=32\n", asm_out_file);

  if (TARGET_ODD_SPREG)
fputs ("\t.module\toddspreg\n", asm_out_file);
  else
fputs ("\t.module\tnooddspreg\n", asm_out_file);

#else

Thank you for your help.
>

Re: [PATCH] PR fortran/87737 - ICE tree check: expected ssa_name, have addr_expr in remap_gimple_op_r, at tree-inline.c:923

[Paul Richard Thomas via Gcc-patches]

Hi Harald,

It looks good to me. OK for mainline. You might even consider backporting
to 11-branch.

Best regards

Paul


On Fri, 27 Aug 2021 at 21:15, Harald Anlauf via Fortran 
wrote:

> Dear all,
>
> the ICE in the original testcase does no longer occur but leads to an
> error in a later stage of compilation, and we accepted invalid code.
> (Cross-checked with other compilers, such as Intel and NAG).
>
> F2018 states:
>
> 15.6.2.6  ENTRY statement
>
> (3) ... If the characteristics of the result of the function named in the
> ENTRY statement are the same as the characteristics of the result of the
> function named in the FUNCTION statement, their result names identify the
> same
> entity, although their names need not be the same. Otherwise, they are
> storage
> associated and shall all be nonpointer, nonallocatable scalar variables
> that
> are default integer, default real, double precision real, default complex,
> or
> default logical.
>
> We thus better reject the testcase example during resolution with an
> appropriate error message.  (I hope the chosen one is fine enough.)
>
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>
> Thanks,
> Harald
>
>
> Fortran - reject function entries with mismatched characteristics
>
> gcc/fortran/ChangeLog:
>
> PR fortran/87737
> * resolve.c (resolve_entries): For functions of type CHARACTER
> tighten the checks for matching characteristics.
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/87737
> * gfortran.dg/entry_24.f90: New test.
>
>

-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

[r12-3159 Regression] FAIL: gfortran.dg/pr68251.f90 -O (test for excess errors) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

f075b8c5adcf9cb6336563c472c8d624c54184db is the first bad commit
commit f075b8c5adcf9cb6336563c472c8d624c54184db
Author: Jan Hubicka 
Date:   Thu Aug 26 15:33:56 2021 +0200

Fix off-by-one error in try_merge_with

caused

FAIL: 20_util/to_address/debug.cc (test for excess errors)
FAIL: 21_strings/basic_string/cons/char/self_move.cc (test for excess errors)
FAIL: 21_strings/basic_string/requirements/citerators.cc (test for excess 
errors)
FAIL: 21_strings/basic_string/requirements/exception/basic.cc (test for excess 
errors)
FAIL: 21_strings/basic_string/requirements/exception/generation_prohibited.cc 
(test for excess errors)
FAIL: 21_strings/basic_string/requirements/exception/propagation_consistent.cc 
(test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/char16_t/1.cc 
(test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/char/1.cc 
(test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/char32_t/1.cc 
(test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/char8_t/1.cc 
(test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/debug.cc 
(test for excess errors)
FAIL: 21_strings/basic_string/requirements/explicit_instantiation/wchar_t/1.cc 
(test for excess errors)
FAIL: 21_strings/debug/shrink_to_fit.cc (test for excess errors)
FAIL: 23_containers/deque/cons/self_move.cc (test for excess errors)
FAIL: 23_containers/deque/debug/98466.cc (test for excess errors)
FAIL: 23_containers/deque/debug/insert4_neg.cc (test for excess errors)
FAIL: 23_containers/deque/debug/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/deque/debug/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/deque/debug/invalidation/3.cc (test for excess errors)
FAIL: 23_containers/deque/debug/invalidation/4.cc (test for excess errors)
FAIL: 23_containers/forward_list/cons/self_move.cc (test for excess errors)
FAIL: 23_containers/forward_list/debug/construct4_neg.cc (test for excess 
errors)
FAIL: 23_containers/forward_list/debug/move_assign_neg.cc (test for excess 
errors)
FAIL: 23_containers/forward_list/debug/move_neg.cc (test for excess errors)
FAIL: 23_containers/list/cons/self_move.cc (test for excess errors)
FAIL: 23_containers/list/debug/insert4_neg.cc (test for excess errors)
FAIL: 23_containers/list/debug/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/list/debug/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/list/debug/invalidation/3.cc (test for excess errors)
FAIL: 23_containers/list/debug/invalidation/4.cc (test for excess errors)
FAIL: 23_containers/map/debug/construct5_neg.cc (test for excess errors)
FAIL: 23_containers/map/debug/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/map/debug/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/map/debug/move_assign_neg.cc (test for excess errors)
FAIL: 23_containers/map/debug/move_neg.cc (test for excess errors)
FAIL: 23_containers/map/modifiers/insert/16813.cc (test for excess errors)
FAIL: 23_containers/multimap/debug/construct5_neg.cc (test for excess errors)
FAIL: 23_containers/multimap/debug/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/multimap/debug/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/multimap/debug/move_assign_neg.cc (test for excess errors)
FAIL: 23_containers/multimap/debug/move_neg.cc (test for excess errors)
FAIL: 23_containers/multiset/debug/construct5_neg.cc (test for excess errors)
FAIL: 23_containers/multiset/debug/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/multiset/debug/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/multiset/debug/move_assign_neg.cc (test for excess errors)
FAIL: 23_containers/multiset/debug/move_neg.cc (test for excess errors)
FAIL: 23_containers/set/cons/self_move.cc (test for excess errors)
FAIL: 23_containers/set/debug/construct5_neg.cc (test for excess errors)
FAIL: 23_containers/set/debug/invalidation/1.cc (test for excess errors)
FAIL: 23_containers/set/debug/invalidation/2.cc (test for excess errors)
FAIL: 23_containers/set/debug/move_assign_neg.cc (test for excess errors)
FAIL: 23_containers/set/debug/move_neg.cc (test for excess errors)
FAIL: 23_containers/unordered_map/debug/98466.cc (test for excess errors)
FAIL: 23_containers/unordered_map/debug/construct5_neg.cc (test for excess 
errors)
FAIL: 23_containers/unordered_map/debug/move_assign_neg.cc (test for excess 
errors)
FAIL: 23_containers/unordered_map/debug/move_neg.cc (test for excess errors)
FAIL: 23_containers/unordered_map/requirements/debug_container.cc (test for 
excess errors)
FAIL: 23_containers/unordered_multimap/debug/construct5_neg.cc (test for excess 
errors)
FAIL: 23_containers/unordered_multimap/debug/move_assign_neg.cc (test for 
excess errors)
FAIL: 23_containers/unordered_multimap/debug/move_neg.cc (test 

Re: [PATCH] libffi: Fix MIPS r6 support

[Xi Ruoyao via Gcc-patches]

On Fri, 2021-08-27 at 15:28 -0600, Jeff Law via Gcc-patches wrote:
> 
> 
> On 8/26/2021 10:58 PM, YunQiang Su wrote:
> > for some instructions, MIPS r6 uses different encoding other than
> > the previous releases.
> > 
> > 1. mips/n32.S disable .set mips4: since it casuses old insn encoding
> >     is used.
> >     https://github.com/libffi/libffi/pull/396
> > 2. mips/ffi.c: the encoding for JR is hardcoded: we need to use
> >     different value for r6 and pre-r6.
> >     https://github.com/libffi/libffi/pull/401
> > 
> > libffi/
> > PR libffi/83636
> > * src/mips/n32.S: disable .set mips4
> > * src/mips/ffi.c: use different JR encoding for r6.
> These should go to the upstream libffi project.  Once accepted there
> you 
> can add them to GCC.

Hi Jeff,

The two PRs are already merged, and released since libffi-3.3.0 (now the
upstream latest release is 3.4.2).

I don't have a MIPSr6 so I can't test though.

YunQiang: the commit message should mention the commit SHA in upstream
libffi repo's main branch, instead of a URL to PR.  You can use "git
log" in gcc repo and search for commits for libffi and learn from it.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Committed: [PATCH] MIPS: use N64 ABI by default if the triple end with -gnuabi64

[Xi Ruoyao via Gcc-patches]

On Fri, 2021-08-27 at 15:38 -0600, Jeff Law wrote:
> 
> 
> On 8/26/2021 10:20 PM, Xi Ruoyao via Gcc-patches wrote:
> > On Thu, 2021-08-26 at 23:56 -0400, YunQiang Su wrote:
> > > gcc/ChangeLog:
> > > 
> > >  PR target/102089
> > >  * config.gcc: MIPS: use N64 ABI by default if the triple
> > > end
> > >    with -gnuabi64, which is used by Debian since 2013.
> > > ---
> > >   gcc/config.gcc | 14 ++
> > >   1 file changed, 14 insertions(+)
> > > 
> > > diff --git a/gcc/config.gcc b/gcc/config.gcc
> > > index 0ff5cac15..0c91be6f3 100644
> > > --- a/gcc/config.gcc
> > > +++ b/gcc/config.gcc
> > > @@ -2553,16 +2553,30 @@ mips*-*-linux*) #
> > > Linux MIPS, either endian.
> > >  target_cpu_default=MASK_SOFT_FLOAT_ABI
> > >  enable_mips_multilibs="yes"
> > >  ;;
> > > +   mipsisa64r6*-*-linux-gnuabi64)
> > > +   default_mips_abi=64
> > > +   default_mips_arch=mips64r6
> > > +   enable_mips_multilibs="yes"
> > > +   ;;
> > >  mipsisa64r6*-*-linux*)
> > >  default_mips_abi=n32
> > >  default_mips_arch=mips64r6
> > >  enable_mips_multilibs="yes"
> > >  ;;
> > > +   mipsisa64r2*-*-linux-gnuabi64)
> > > +   default_mips_abi=64
> > > +   default_mips_arch=mips64r2
> > > +   enable_mips_multilibs="yes"
> > > +   ;;
> > >  mipsisa64r2*-*-linux*)
> > >  default_mips_abi=n32
> > >  default_mips_arch=mips64r2
> > >  enable_mips_multilibs="yes"
> > >  ;;
> > > +   mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-
> > > gnuabi64)
> > > +   default_mips_abi=64
> > > +   enable_mips_multilibs="yes"
> > > +   ;;
> > >  mips64*-*-linux* | mipsisa64*-*-linux*)
> > >  default_mips_abi=n32
> > >  enable_mips_multilibs="yes"
> > LGTM, but I don't have the privilege to approve any change so you'll
> > still need to wait for approval :)
> Yea, but having a second pair of eyes chime in is definitely helpful.
> 
> > 
> > And I think the behavior change should be announced in
> > https://gcc.gnu.org/gcc-12/changes.html, if it's approved.
> Agreed.
> 
> The configure change is approved.

Pushed to trunk as 91f78b67.

Jeff: YunQiang is working on compilers for CIP United, a company
producing MIPS IPs, chips, and toolchains.  Is it possible to grant him
a write-after-approval?

> And a change to the gcc-12 changes.html is pre-approved.

Re: [PATCH v2] [MIPS]: add .module mipsREV to all output asm file

[Xi Ruoyao via Gcc-patches]

On Fri, 2021-08-27 at 15:36 -0600, Jeff Law wrote:

> It's easier when someone has to debug the code later.  
> enums show up in debug output by default, while #defines do not.

> > 
> > switch (mips_isa)
> >    {
> >  case MIPS_ISA_MIPS1: return "mips1";
> >  // ...
> >    }
> > 
> > It looks better, and (maybe) generates better code.  Just my 2 cents
> > though.

> Coding standards would have that as
> 
> switch (mips_isa)
>    {
>    case MIPS_ISA_MIPS_1:
>  return "mips1";
>    ...
>    }

There is some existing code using "case ... : return ..." in one line in
mips.c, so I thought it was standard :(.

> Presumably .module is supported by all reasonably modern versions of
> GAS?

It's added by the commit in binutils-gdb:

> commit 919731affbef19fcad8dddb0a595bb05755cb345
> Author: mfortune 
> Date:   Tue May 20 13:28:20 2014 +0100
> 
> Add MIPS .module directive
> 

So it should be supported since binutils-2.25.

If we want to support old binutils we'll need something like "-fno-mips-
module-directive" and "--without-mips-module-directive".  My suggestion
is just bumping the binutils requirement for mips*-*-*.