Re: [committed] d: Support deprecated, @disable, and user-defined attributes on enum members

[Andreas Schwab]

../../gcc/d/dmd/parse.c: In member function 'Dsymbols* 
Parser::parseDeclDefs(int, Dsymbol**, PrefixAttributes*)':
../../gcc/d/dmd/parse.c:647:29: error: unused variable 'e' 
[-Werror=unused-variable]
  647 | Expression *e = NULL;
  | ^

Andreas.

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

Re: [patch] fix -Wformat-diag warnings in rs6000-call.c

[Matthias Klose]

On 1/9/21 11:22 PM, Jakub Jelinek wrote:
> On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote:
>> These warnings, including the suggested fixes are seen on power*-linux 
>> builds.
>>
>> warning: misspelled term 'builtin function' in format; use 'bult-in function'
> 
> Are you sure it printed bult-in ?
> 
>>  fatal_error (input_location,
>> - "internal error: builtin function %qs already processed",
>> + "internal error: builtin-function %qs already processed",
> 
> It meant built-in function instead of builtin-function I'm pretty sure.
> 
>>   name);
>>  
>>rs6000_builtin_decls[(int)code] = t =
>> @@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool 
>> *expandedp)
>>  {
>>size_t uns_fcode = (size_t) fcode;
>>const char *name = rs6000_builtin_info[uns_fcode].name;
>> -  error ("Second argument of %qs must be in the range [0, 3].", name);
>> +  error ("Second argument of %qs must be in the range [0, 3]", name);
> 
> Diagnostics shouldn't start with capital letter either, so it should be
> "second ..."
>> - "internal error: builtin function %qs had an unexpected "
>> + "internal error: builtin-function %qs had an unexpected "
>>   "return type %qs", name, GET_MODE_NAME (h.mode[0]));
>> - "internal error: builtin function %qs, argument %d "
>> + "internal error: builtin-function %qs, argument %d "
> 
> See above.

ahh, my bad. verschlimmbessert ...

fixed version attached. While looking at all -Wformat-diag warnings ...

../../src/gcc/emit-rtl.c: In function 'rtx_insn* make_insn_raw(rtx)':
../../src/gcc/emit-rtl.c:4038:25: warning: unquoted identifier or keyword
'emit_insn' in format [-Wformat-diag]
 4038 |   warning (0, "ICE: emit_insn used where emit_jump_insn needed:\n");
  | ^
../../src/gcc/emit-rtl.c:4038:46: warning: unquoted identifier or keyword
'emit_jump_insn' in format [-Wformat-diag]
 4038 |   warning (0, "ICE: emit_insn used where emit_jump_insn needed:\n");
  |  ^~
../../src/gcc/emit-rtl.c:4038:68: warning: unquoted whitespace character '\x0a'
in format [-Wformat-diag]
 4038 |   warning (0, "ICE: emit_insn used where emit_jump_insn needed:\n");
  |

genautomata has `%s' hardcoded, while other places have %q+F. What is the
preferred way?

is the newline intended? It's followed by a debug_rtx call.

../../src/gcc/rtl.c:860:42: warning: unquoted sequence of 2 consecutive
punctuation characters '',' in format [-Wformat-diag]
  860 | ("RTL check: expected elt %d type '%c', have '%c' (rtx %s) in %s, at
%s:%d",

`%c', or some %q quoting?

../../src/gcc/config/rs6000/rs6000.c: In function 'void rs6000_emit_move(rtx,
rtx, machine_mode)':
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: contraction 'can't' in
format; use 'cannot' instead [-Wformat-diag]
10330 | error ("%qs is an opaque type, and you can't set it to other
values.",
  |
^~
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: spurious trailing
punctuation sequence '.' in format [-Wformat-diag]
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_handle_altivec_attribute(tree_node**, tree, tree, int, bool*)':
../../src/gcc/config/rs6000/rs6000.c:19811:12: warning: misspelled term
'floating point' in format; use 'floating-point' instead [-Wformat-diag]
19811 | error ("use of decimal floating point types in AltiVec types is
invalid");
  |
^
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_get_function_versions_dispatcher(void*)':
../../src/gcc/config/rs6000/rs6000.c:24597:17: warning: unquoted keyword 'ifunc'
in format [-Wformat-diag]
24597 | "multiversioning needs ifunc which is not supported "
  | ^
24598 | "on this target");


again, `' quotes, or some %q option?
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 2308cc8b4a2..18e85ee6f9c 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -8741,7 +8741,7 @@ def_builtin (const char *name, tree type, enum rs6000_builtins code)
 
   if (rs6000_builtin_decls[(int)code])
 fatal_error (input_location,
-		 "internal error: builtin function %qs already processed",
+		 "internal error: built-in function %qs already processed",
 		 name);
 
   rs6000_builtin_decls[(int)code] = t =
@@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool *expandedp)
 	{
 	  size_t uns_fcode = (size_t) fcode;
 	  const char *name = rs6000_builtin_info[uns_fcode].name;
-	  error ("Second argument of %qs must be in the range [0, 3].", name);
+	  er

[PATCH v2] fix Ada bootstrap on Cygwin64 (PR bootstrap/94918)

[Mikael Pettersson via Gcc-patches]

This fixes a compilation error preventing bootstrap with Ada on
x86_64-pc-cygwin. See PR bootstrap/94918 for details.

Compared to the initial patch sent in May 2020, this v2 patch places
the fix in Ada's raise-gcc.c instead of the shared unwind-generic.h,
which should hopefully simplify getting it applied.

Tested by bootstrapping this and the preliminary workaround for
PR98590 on x86_64-pc-cygwin.

Ok for master and branches?

(Patch also attached to protect it against gmail formatting.)

gcc/ada/

2021-01-10  Mikael Pettersson  

PR bootstrap/94918
* raise-gcc.c: (__SEH__): Prevent windows.h from including
x86intrin.h or emmintrin.h on Cygwin64.

--- gcc-11-20210103/gcc/ada/raise-gcc.c.~1~ 2021-01-03
23:32:14.0 +0100
+++ gcc-11-20210103/gcc/ada/raise-gcc.c 2021-01-10 11:13:07.878685936 +0100
@@ -79,6 +79,15 @@ typedef char bool;
(SJLJ or DWARF). We need a consistently named interface to import from
a-except, so wrappers are defined here.  */

+#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) && \
+defined (__CYGWIN__) && !defined (__CYGWIN32__) && !defined (IN_RTS)
+/* Note: windows.h (via unwind-generic.h) on cygwin-64 includes x86intrin.h
+   which uses malloc. That fails to compile if malloc is poisoned, i.e. if
+   !IN_RTS.  */
+#define _X86INTRIN_H_INCLUDED
+#define _EMMINTRIN_H_INCLUDED
+#endif
+
 #ifndef IN_RTS
   /* For gnat1/gnatbind compilation: cannot use unwind.h, as it is for the
  target. So mimic configure...
gcc/ada/

2021-01-10  Mikael Pettersson  

	PR bootstrap/94918
	* raise-gcc.c: (__SEH__): Prevent windows.h from including
	x86intrin.h or emmintrin.h on Cygwin64.

--- gcc-11-20210103/gcc/ada/raise-gcc.c.~1~	2021-01-03 23:32:14.0 +0100
+++ gcc-11-20210103/gcc/ada/raise-gcc.c	2021-01-10 11:13:07.878685936 +0100
@@ -79,6 +79,15 @@ typedef char bool;
(SJLJ or DWARF). We need a consistently named interface to import from
a-except, so wrappers are defined here.  */
 
+#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) && \
+defined (__CYGWIN__) && !defined (__CYGWIN32__) && !defined (IN_RTS)
+/* Note: windows.h (via unwind-generic.h) on cygwin-64 includes x86intrin.h
+   which uses malloc. That fails to compile if malloc is poisoned, i.e. if
+   !IN_RTS.  */
+#define _X86INTRIN_H_INCLUDED
+#define _EMMINTRIN_H_INCLUDED
+#endif
+
 #ifndef IN_RTS
   /* For gnat1/gnatbind compilation: cannot use unwind.h, as it is for the
  target. So mimic configure...

Re: [PATCH v2] fix Ada bootstrap on Cygwin64 (PR bootstrap/94918)

[Arnaud Charlet]

> This fixes a compilation error preventing bootstrap with Ada on
> x86_64-pc-cygwin. See PR bootstrap/94918 for details.
> 
> Compared to the initial patch sent in May 2020, this v2 patch places
> the fix in Ada's raise-gcc.c instead of the shared unwind-generic.h,
> which should hopefully simplify getting it applied.

Not sure why. Applying it there looks incomplete and kludgy, don't you
agree?

Arno

> gcc/ada/
> 
> 2021-01-10  Mikael Pettersson  
> 
> PR bootstrap/94918
> * raise-gcc.c: (__SEH__): Prevent windows.h from including
> x86intrin.h or emmintrin.h on Cygwin64.
> 
> --- gcc-11-20210103/gcc/ada/raise-gcc.c.~1~ 2021-01-03
> 23:32:14.0 +0100
> +++ gcc-11-20210103/gcc/ada/raise-gcc.c 2021-01-10 11:13:07.878685936 +0100
> @@ -79,6 +79,15 @@ typedef char bool;
> (SJLJ or DWARF). We need a consistently named interface to import from
> a-except, so wrappers are defined here.  */
> 
> +#if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__) && \
> +defined (__CYGWIN__) && !defined (__CYGWIN32__) && !defined (IN_RTS)
> +/* Note: windows.h (via unwind-generic.h) on cygwin-64 includes x86intrin.h
> +   which uses malloc. That fails to compile if malloc is poisoned, i.e. if
> +   !IN_RTS.  */
> +#define _X86INTRIN_H_INCLUDED
> +#define _EMMINTRIN_H_INCLUDED
> +#endif
> +
>  #ifndef IN_RTS
>/* For gnat1/gnatbind compilation: cannot use unwind.h, as it is for the
>   target. So mimic configure...

[patch, fortran shared coarrays, committed]

[Thomas Koenig via Gcc-patches]

Hello world,

after the discussions about PTHREAD_PROCESS_SHARED and after
observing that on Cygwin the program simply hangs because
this flag is not implemented there, the best way is to check
for errors and exit with a clear error message instead of
some mysterious hang.

Committed after OK from Nicolas.

Best regards

Thomas

libgfortran/ChangeLog:

* caf_shared/util.c (ERRCHECK): New macro.
(initialize_shared_mutex): Use it to check return codes.
(initialize_shared_condition): Likewise.
diff --git a/libgfortran/caf_shared/util.c b/libgfortran/caf_shared/util.c
index 683e2f36d63..65b347e7a8c 100644
--- a/libgfortran/caf_shared/util.c
+++ b/libgfortran/caf_shared/util.c
@@ -48,24 +48,33 @@ next_power_of_two (size_t size)
   return 1 << (PTR_BITS - __builtin_clzl (size - 1));
 }
 
+#define ERRCHECK(a) do {   \
+int rc = a;\
+if (rc) {  \
+  errno = rc;  \
+  perror (#a " failed");   \
+  exit (1);\
+}  \
+} while(0)
+
 void
 initialize_shared_mutex (pthread_mutex_t *mutex)
 {
   pthread_mutexattr_t mattr;
-  pthread_mutexattr_init (&mattr);
-  pthread_mutexattr_setpshared (&mattr, PTHREAD_PROCESS_SHARED);
-  pthread_mutex_init (mutex, &mattr);
-  pthread_mutexattr_destroy (&mattr);
+  ERRCHECK (pthread_mutexattr_init (&mattr));
+  ERRCHECK (pthread_mutexattr_setpshared (&mattr, PTHREAD_PROCESS_SHARED));
+  ERRCHECK (pthread_mutex_init (mutex, &mattr));
+  ERRCHECK (pthread_mutexattr_destroy (&mattr));
 }
 
 void
 initialize_shared_condition (pthread_cond_t *cond)
 {
   pthread_condattr_t cattr;
-  pthread_condattr_init (&cattr);
-  pthread_condattr_setpshared (&cattr, PTHREAD_PROCESS_SHARED);
-  pthread_cond_init (cond, &cattr);
-  pthread_condattr_destroy (&cattr);
+  ERRCHECK (pthread_condattr_init (&cattr));
+  ERRCHECK (pthread_condattr_setpshared (&cattr, PTHREAD_PROCESS_SHARED));
+  ERRCHECK (pthread_cond_init (cond, &cattr));
+  ERRCHECK (pthread_condattr_destroy (&cattr));
 }
 
 int

Re: [PATCH v2] fix Ada bootstrap on Cygwin64 (PR bootstrap/94918)

[Mikael Pettersson via Gcc-patches]

On Sun, Jan 10, 2021 at 11:57 AM Arnaud Charlet  wrote:
>
> > This fixes a compilation error preventing bootstrap with Ada on
> > x86_64-pc-cygwin. See PR bootstrap/94918 for details.
> >
> > Compared to the initial patch sent in May 2020, this v2 patch places
> > the fix in Ada's raise-gcc.c instead of the shared unwind-generic.h,
> > which should hopefully simplify getting it applied.
>
> Not sure why. Applying it there looks incomplete and kludgy, don't you
> agree?

Ok, then here's v3 which places the fix in unwind-generic.h. The fix
matches what Ada's mingw32.h does.

Tested by bootstrapping this and the preliminary workaround for
PR98590 on x86_64-pc-cygwin.

Ok for master and branches?

libgcc/

2021-01-10  Mikael Pettersson  

PR bootstrap/94918
* unwind-generic.h (__SEH__): Prevent windows.h from including
x86intrin.h or emmintrin.h on Cygwin64.

--- gcc-11-20210103/libgcc/unwind-generic.h.~1~ 2021-01-03
23:32:20.0 +0100
+++ gcc-11-20210103/libgcc/unwind-generic.h 2021-01-09
14:51:16.262378715 +0100
@@ -30,6 +30,12 @@

 #if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
 /* Only for _GCC_specific_handler.  */
+#if defined (__CYGWIN__) && !defined (__CYGWIN32__) && !defined (IN_RTS)
+/* Note: windows.h on cygwin-64 includes x86intrin.h which uses malloc.
+   That fails to compile, if malloc is poisoned, i.e. if !IN_RTS.  */
+#define _X86INTRIN_H_INCLUDED
+#define _EMMINTRIN_H_INCLUDED
+#endif
 #include 
 #endif
libgcc/

2021-01-10  Mikael Pettersson  

	PR bootstrap/94918
	* unwind-generic.h (__SEH__): Prevent windows.h from including
	x86intrin.h or emmintrin.h on Cygwin64.

--- gcc-11-20210103/libgcc/unwind-generic.h.~1~	2021-01-03 23:32:20.0 +0100
+++ gcc-11-20210103/libgcc/unwind-generic.h	2021-01-09 14:51:16.262378715 +0100
@@ -30,6 +30,12 @@
 
 #if defined (__SEH__) && !defined (__USING_SJLJ_EXCEPTIONS__)
 /* Only for _GCC_specific_handler.  */
+#if defined (__CYGWIN__) && !defined (__CYGWIN32__) && !defined (IN_RTS)
+/* Note: windows.h on cygwin-64 includes x86intrin.h which uses malloc.
+   That fails to compile, if malloc is poisoned, i.e. if !IN_RTS.  */
+#define _X86INTRIN_H_INCLUDED
+#define _EMMINTRIN_H_INCLUDED
+#endif
 #include 
 #endif
 

Re: [PATCH 2/4] PDP11: Use a mode with `const_double_zero' expressions

[Maciej W. Rozycki]

On Fri, 8 Jan 2021, Paul Koning wrote:

> Ok.  Thanks Maciej.

 Thank you for your review.  I have applied this change now (and the 
remaining from the series, approved by Jeff).

  Maciej

Re: [PATCH] VAX/testsuite: Remove notsi comparison elimination regressions

[Maciej W. Rozycki]

On Fri, 8 Jan 2021, Jeff Law wrote:

> > gcc/testsuite/
> > * gcc.target/vax/cmpelim-eq-notsi.c: Use subtraction from a 
> > constant then rather than addition.
> > * gcc.target/vax/cmpelim-le-notsi.c: Likewise.
> > * gcc.target/vax/cmpelim-lt-notsi.c: Likewise.
> OK

 Thank you for your review.  I have applied this change now and the 
remaining ones you have approved.  I'll be watching out for any further 
concerns, but otherwise I consider VAX backend development complete for 
this release cycle.

 Also I have now scheduled full regression testing of the `vax-netbsdelf' 
target with the timeout extended to 7200 seconds.  Hopefully this will let 
all cases complete that do not infinitely loop.  I can post results to 
gcc-testresults if that would be desired (is there a dedicated format for 
that mailing list?), and overall they need to be triaged before anything 
can be decided about what to do next.

 I have seen some failures coming from individual test cases' assumption 
of the floating-point format being IEEE 754, so at least these can be 
easily excluded, or variants for the alternative format provided, as 
applicable.

  Maciej

[PATCH] reassoc: Reassociate integral multiplies [PR95867[

[Jakub Jelinek via Gcc-patches]

Hi!

For floating point multiply, we have nice code in reassoc to reassociate
multiplications to almost optimal sequence of as few multiplications as
possible (or library call), but for integral types we just give up
because there is no __builtin_powi* for those types.

As there is no library routine we could use, instead of adding new internal
call just to hold it temporarily and then lower to multiplications again,
this patch for the integral types calls into the sincos pass routine that
expands it into multiplications right away.

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

2021-01-09  Jakub Jelinek  

PR tree-optimization/95867
* tree-ssa-math-opts.h: New header.
* tree-ssa-math-opts.c: Include tree-ssa-math-opts.h.
(powi_as_mults): No longer static.  Use build_one_cst instead of
build_real.  Formatting fix.
* tree-ssa-reassoc.c: Include tree-ssa-math-opts.h.
(attempt_builtin_powi): Handle multiplication reassociation without
powi_fndecl using powi_as_mults.
(reassociate_bb): For integral types don't require
-funsafe-math-optimizations to call attempt_builtin_powi.

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

--- gcc/tree-ssa-math-opts.h.jj 2021-01-09 16:54:58.301092357 +0100
+++ gcc/tree-ssa-math-opts.h2021-01-09 16:56:32.098024806 +0100
@@ -0,0 +1,26 @@
+/* Global, SSA-based optimizations using mathematical identities.
+   Copyright (C) 2021 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef GCC_TREE_SSA_MATH_OPTS_H
+#define GCC_TREE_SSA_MATH_OPTS_H
+
+extern tree powi_as_mults (gimple_stmt_iterator *, location_t,
+  tree, HOST_WIDE_INT);
+
+#endif  /* GCC_TREE_SSA_MATH_OPTS_H  */
--- gcc/tree-ssa-math-opts.c.jj 2021-01-09 10:47:18.0 +0100
+++ gcc/tree-ssa-math-opts.c2021-01-09 16:58:59.442347773 +0100
@@ -115,6 +115,7 @@ along with GCC; see the file COPYING3.
 #include "tree-eh.h"
 #include "targhooks.h"
 #include "domwalk.h"
+#include "tree-ssa-math-opts.h"
 
 /* This structure represents one basic block that either computes a
division, or is a common dominator for basic block that compute a
@@ -1527,7 +1528,7 @@ powi_as_mults_1 (gimple_stmt_iterator *g
 /* Convert ARG0**N to a tree of multiplications of ARG0 with itself.
This function needs to be kept in sync with powi_cost above.  */
 
-static tree
+tree
 powi_as_mults (gimple_stmt_iterator *gsi, location_t loc,
   tree arg0, HOST_WIDE_INT n)
 {
@@ -1536,9 +1537,9 @@ powi_as_mults (gimple_stmt_iterator *gsi
   tree target;
 
   if (n == 0)
-return build_real (type, dconst1);
+return build_one_cst (type);
 
-  memset (cache, 0,  sizeof (cache));
+  memset (cache, 0, sizeof (cache));
   cache[1] = arg0;
 
   result = powi_as_mults_1 (gsi, loc, type, (n < 0) ? -n : n, cache);
--- gcc/tree-ssa-reassoc.c.jj   2021-01-05 16:37:36.254185194 +0100
+++ gcc/tree-ssa-reassoc.c  2021-01-09 17:20:48.205462550 +0100
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3.
 #include "gimplify.h"
 #include "case-cfn-macros.h"
 #include "tree-ssa-reassoc.h"
+#include "tree-ssa-math-opts.h"
 
 /*  This is a simple global reassociation pass.  It is, in part, based
 on the LLVM pass of the same name (They do some things more/less
@@ -5976,8 +5977,8 @@ attempt_builtin_powi (gimple *stmt, vec<
   gimple *mul_stmt, *pow_stmt;
 
   /* Nothing to do if BUILT_IN_POWI doesn't exist for this type and
- target.  */
-  if (!powi_fndecl)
+ target, unless type is integral.  */
+  if (!powi_fndecl && !INTEGRAL_TYPE_P (type))
 return NULL_TREE;
 
   /* Allocate the repeated factor vector.  */
@@ -6086,14 +6087,33 @@ attempt_builtin_powi (gimple *stmt, vec<
}
  else
{
- iter_result = make_temp_ssa_name (type, NULL, "reassocpow");
- pow_stmt = gimple_build_call (powi_fndecl, 2, rf1->repr, 
-   build_int_cst (integer_type_node,
-  power));
- gimple_call_set_lhs (pow_stmt, iter_result);
- gimple_set_location (pow_stmt, gimple_location (stmt));
- gimple_set_uid (pow_stmt, gimple_uid (stmt));
- gsi_insert_before (&gsi, pow_stmt, GSI_SAME_STMT);
+ if (INTEGRAL_TYPE_

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

[Xi Ruoyao via Gcc-patches]

Hi Jeff and Jakub,

On 2021-01-04 14:19 -0700, Jeff Law wrote:
> On 1/4/21 2:00 PM, Jakub Jelinek wrote:
> > On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote:
> > > > Sorry, I forgot to include the ChangeLog:
> > > > 
> > > >     gcc/ChangeLog:
> > > >     
> > > >     2020-12-31  Xi Ruoyao 
> > > >     
> > > >     PR target/98491
> > > >     * config/mips/mips.c (mips_symbol_insns): Do not use
> > > >   MSA_SUPPORTED_MODE_P if mode is MAX_MACHINE_MODE.
> > > So I absolutely agree the current code is wrong as it does an out of
> > > bounds array access.
> > > 
> > > 
> > > Would it be better to instead to change MSA_SUPPORTED_MODE_P to evaluate
> > > to zero if MODE is MAX_MACHINE_MODE?  That would protect all the uses of
> > > MSA_SUPPORTED_MODE_P.    Something like this perhaps?
> > But MAX_MACHINE_MODE is the one past last valid mode, I'm not aware of
> > any target that would protect all macros that deal with modes that way.
> > 
> > So, perhaps best would be stop using the MAX_MACHINE_MODE as magic value
> > for that function and instead use say VOIDmode that shouldn't normally
> > appear either?
> I think we have to allow VOIDmode because constants don't necessarily
> have modes.   And I certainly agree that using MAX_MACHINE_MODE like
> this is ugly and error prone (as we can see from the BZ).
> 
> I also couldn't convince myself that the code and comments were actually
> consistent, particularly for MSA targets which the comment claims can
> never handle constants for ld/st (and thus should be returning 0 for
> MAX_MACHINE_MODE).  Though maybe mips_symbol_insns_1 ultimately handles
> that correctly.
> 
> 
> > 
> > But I don't really see anything wrong on the mips_symbol_insns above
> > change either.
> Me neither.  I'm just questioning if bullet-proofing in the
> MSA_SUPPORTED_MODE_P would be a better option.  While I've worked in the
> MIPS port in the past, I don't really have any significannt experience
> with the MSA support.

I can't understand the comment either.  To me it looks like it's possible to
remove this "if (MSA_SUPPORTED_P (mode)) return 0;"

CC Robert to get some help.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog)

[Xi Ruoyao via Gcc-patches]

On 2021-01-11 01:01 +0800, Xi Ruoyao wrote:
> CC Robert to get some help.

Unfortunately Robert's mail in MAINTAINER file seems no longer valid :(.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [patch] fix -Wformat-diag warnings in rs6000-call.c

[Martin Sebor via Gcc-patches]

On 1/10/21 3:29 AM, Matthias Klose wrote:

On 1/9/21 11:22 PM, Jakub Jelinek wrote:

On Sat, Jan 09, 2021 at 07:44:31PM +0100, Matthias Klose wrote:

These warnings, including the suggested fixes are seen on power*-linux builds.

warning: misspelled term 'builtin function' in format; use 'bult-in function'


Are you sure it printed bult-in ?


  fatal_error (input_location,
-"internal error: builtin function %qs already processed",
+"internal error: builtin-function %qs already processed",


It meant built-in function instead of builtin-function I'm pretty sure.


 name);
  
rs6000_builtin_decls[(int)code] = t =

@@ -11219,7 +11219,7 @@ altivec_expand_builtin (tree exp, rtx target, bool 
*expandedp)
{
  size_t uns_fcode = (size_t) fcode;
  const char *name = rs6000_builtin_info[uns_fcode].name;
- error ("Second argument of %qs must be in the range [0, 3].", name);
+ error ("Second argument of %qs must be in the range [0, 3]", name);


Diagnostics shouldn't start with capital letter either, so it should be
"second ..."

-"internal error: builtin function %qs had an unexpected "
+"internal error: builtin-function %qs had an unexpected "
 "return type %qs", name, GET_MODE_NAME (h.mode[0]));
-"internal error: builtin function %qs, argument %d "
+"internal error: builtin-function %qs, argument %d "


See above.


ahh, my bad. verschlimmbessert ...

fixed version attached. While looking at all -Wformat-diag warnings ...

../../src/gcc/emit-rtl.c: In function 'rtx_insn* make_insn_raw(rtx)':
../../src/gcc/emit-rtl.c:4038:25: warning: unquoted identifier or keyword
'emit_insn' in format [-Wformat-diag]
  4038 |   warning (0, "ICE: emit_insn used where emit_jump_insn 
needed:\n");
   | ^
../../src/gcc/emit-rtl.c:4038:46: warning: unquoted identifier or keyword
'emit_jump_insn' in format [-Wformat-diag]
  4038 |   warning (0, "ICE: emit_insn used where emit_jump_insn 
needed:\n");
   |  ^~
../../src/gcc/emit-rtl.c:4038:68: warning: unquoted whitespace character '\x0a'
in format [-Wformat-diag]
  4038 |   warning (0, "ICE: emit_insn used where emit_jump_insn 
needed:\n");
   |

genautomata has `%s' hardcoded, while other places have %q+F. What is the
preferred way?

is the newline intended? It's followed by a debug_rtx call.


To avoid the warning there shouldn't be any trailing punctuation
or whitespace in the message.  The GCC quoting directives should
be preferred over the literal characters (as per GCC Coding
Conventions).  %qc and %qs are preferable to %<%c%>.

Symbols/identifiers should be formatted using the appropriate
directives or quoted in %< %>.  Underscores in words like
emit_insn are taken as indicators that the word is an identifier
and to trigger warnings.




../../src/gcc/rtl.c:860:42: warning: unquoted sequence of 2 consecutive
punctuation characters '',' in format [-Wformat-diag]
   860 | ("RTL check: expected elt %d type '%c', have '%c' (rtx %s) in %s, 
at
%s:%d",

`%c', or some %q quoting?


The purpose of the -Wformat-diag warnings is to improve the consistency
of user-visible messages and make them easier to translate.  There was
a discussion some time back about whether internal errors should fall
into this category.  I'm not sure if it reached a conclusion one way
or the other but in similar situations elsewhere in GCC we have
suppressed the warning via #pragma GCC diagnostic.  If it takes too
much effort to clean them up it might make sense to do the same here
(the downside is that it doesn't help translators).  Otherwise,
the messages are not really phrased in a way that's comprehensible
either to users or to tranlators (acronyms like elt or rtx aren't 
universally understood).




../../src/gcc/config/rs6000/rs6000.c: In function 'void rs6000_emit_move(rtx,
rtx, machine_mode)':
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: contraction 'can't' in
format; use 'cannot' instead [-Wformat-diag]
10330 | error ("%qs is an opaque type, and you can't set it to other
values.",
   |
^~
../../src/gcc/config/rs6000/rs6000.c:10330:16: warning: spurious trailing
punctuation sequence '.' in format [-Wformat-diag]
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_handle_altivec_attribute(tree_node**, tree, tree, int, bool*)':
../../src/gcc/config/rs6000/rs6000.c:19811:12: warning: misspelled term
'floating point' in format; use 'floating-point' instead [-Wformat-diag]
19811 | error ("use of decimal floating point types in AltiVec types is
invalid");
   |
^
../../src/gcc/config/rs6000/rs6000.c: In function 'tree_node*
rs6000_get_f

Re: [PATCH] Hurd: Enable ifunc by default

[Samuel Thibault via Gcc-patches]

Ping?

Samuel Thibault, le dim. 08 nov. 2020 23:52:51 +0100, a ecrit:
> The binutils bugs seem to have been fixed.
> 
> 2020-11-08  Samuel Thibault  
> 
>   gcc/
>   * config.gcc: Enable default_gnu_indirect_function in *-*-gnu*
>   target (but not *-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu).
> ---
>  gcc/config.gcc | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index b42ebc4e5be..a347c2cec7c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3538,7 +3538,9 @@ esac
>  case ${target} in
>  *-*-linux*android*|*-*-linux*uclibc*|*-*-linux*musl*)
>  ;;
> -*-*-linux*)
> +*-*-kfreebsd*-gnu | *-*-kopensolaris*-gnu)
> +;;
> +*-*-linux* | *-*-gnu*)
>   case ${target} in
>   aarch64*-* | arm*-* | i[34567]86-* | powerpc*-* | s390*-* | sparc*-* | 
> x86_64-*)
>   default_gnu_indirect_function=yes
> -- 
> 2.20.1
> 

Re: [PATCHv2] hurd: libgcc unwinding over signal trampolines with SIGINFO

[Samuel Thibault via Gcc-patches]

Ping?

Samuel Thibault, le lun. 21 déc. 2020 15:36:30 +0100, a ecrit:

When the application sets SA_SIGINFO, the signal trampoline parameters
are different to follow POSIX.

libgcc/
* config/i386/gnu-unwind.h (x86_gnu_fallback_frame_state): Add the posix
siginfo case to struct handler_args. Detect between legacy and siginfo from
the second parameter, which is a small sigcode in the legacy case, and a
pointer in the siginfo case.

diff --git a/libgcc/config/i386/gnu-unwind.h b/libgcc/config/i386/gnu-unwind.h
index db47f0ac1d4..f83411e3de4 100644
--- a/libgcc/config/i386/gnu-unwind.h
+++ b/libgcc/config/i386/gnu-unwind.h
@@ -38,10 +38,21 @@ x86_gnu_fallback_frame_state
 {
   struct handler_args {
 int signo;
-int sigcode;
-struct sigcontext *scp;
+union
+  {
+   struct
+ {
+   long int sigcode;
+   struct sigcontext *scp;
+ } legacy;
+   struct
+ {
+   siginfo_t *siginfop;
+   ucontext_t *uctxp;
+ } posix;
+  };
   } *handler_args;
-  struct sigcontext *scp;
+  long int sigcode;
   unsigned long usp;
 
 /*
@@ -75,29 +86,52 @@ x86_gnu_fallback_frame_state
 return _URC_END_OF_STACK;
 
   handler_args = context->cfa;
-  scp = handler_args->scp;
-  usp = scp->sc_uesp;
+  sigcode = handler_args->legacy.sigcode;
+  if (sigcode >= -16 && sigcode < 4096)
+{
+  /* This cannot be a SIGINFO pointer, assume legacy.  */
+  struct sigcontext *scp = handler_args->legacy.scp;
+  usp = scp->sc_uesp;
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+}
+  else
+{
+  /* This is not a valid sigcode, assume SIGINFO.  */
+  ucontext_t *uctxp = handler_args->posix.uctxp;
+  gregset_t *gregset = &uctxp->uc_mcontext.gregs;
+  usp = (*gregset)[REG_UESP];
+
+  fs->regs.reg[0].loc.offset = (unsigned long)&(*gregset)[REG_EAX] - usp;
+  fs->regs.reg[1].loc.offset = (unsigned long)&(*gregset)[REG_ECX] - usp;
+  fs->regs.reg[2].loc.offset = (unsigned long)&(*gregset)[REG_EDX] - usp;
+  fs->regs.reg[3].loc.offset = (unsigned long)&(*gregset)[REG_EBX] - usp;
+  fs->regs.reg[5].loc.offset = (unsigned long)&(*gregset)[REG_EBP] - usp;
+  fs->regs.reg[6].loc.offset = (unsigned long)&(*gregset)[REG_ESI] - usp;
+  fs->regs.reg[7].loc.offset = (unsigned long)&(*gregset)[REG_EDI] - usp;
+  fs->regs.reg[8].loc.offset = (unsigned long)&(*gregset)[REG_EIP] - usp;
+}
 
   fs->regs.cfa_how = CFA_REG_OFFSET;
   fs->regs.cfa_reg = 4;
   fs->regs.cfa_offset = usp - (unsigned long) context->cfa;
 
   fs->regs.reg[0].how = REG_SAVED_OFFSET;
-  fs->regs.reg[0].loc.offset = (unsigned long)&scp->sc_eax - usp;
   fs->regs.reg[1].how = REG_SAVED_OFFSET;
-  fs->regs.reg[1].loc.offset = (unsigned long)&scp->sc_ecx - usp;
   fs->regs.reg[2].how = REG_SAVED_OFFSET;
-  fs->regs.reg[2].loc.offset = (unsigned long)&scp->sc_edx - usp;
   fs->regs.reg[3].how = REG_SAVED_OFFSET;
-  fs->regs.reg[3].loc.offset = (unsigned long)&scp->sc_ebx - usp;
   fs->regs.reg[5].how = REG_SAVED_OFFSET;
-  fs->regs.reg[5].loc.offset = (unsigned long)&scp->sc_ebp - usp;
   fs->regs.reg[6].how = REG_SAVED_OFFSET;
-  fs->regs.reg[6].loc.offset = (unsigned long)&scp->sc_esi - usp;
   fs->regs.reg[7].how = REG_SAVED_OFFSET;
-  fs->regs.reg[7].loc.offset = (unsigned long)&scp->sc_edi - usp;
   fs->regs.reg[8].how = REG_SAVED_OFFSET;
-  fs->regs.reg[8].loc.offset = (unsigned long)&scp->sc_eip - usp;
+
   fs->retaddr_column = 8;
   fs->signal_frame = 1;
 

[PATCH v2] c++: Add support for -std=c++2b

[Paul Fee via Gcc-patches]

[PATCH v2] c++: Add support for -std=c++2b

Derived from the changes that added C++2a support in 2017.
https://gcc.gnu.org/g:026a79f70cf33f836ea5275eda72d4870a3041e5

No C++2b features are added here.
Use of -std=c++2b sets __cplusplus to 202100L.

$ g++ -std=c++2b -dM -E -x c++ - < /dev/null | grep cplusplus
#define __cplusplus 202100L

Changes since v1 (8th Jan 2021):
* As suggested by Jonathan Wakely:
  __cplusplus set to 202100L rather than 202101L.  Use of a non-existent date
  helps indicate this is not a true standard, yet is a value greater
than 202002L.
* As suggested by Jakub Jelinek:
  Fixed typos and formatting.
  Added C++23 support to dwarf2out.c, including missing C++20 support
in highest_c_language.
* Regarding suggestion by Marek Polacek to refer to C++23 rather than C++2b.
  Left the option as -std=c++2b for now.  It may be premature to assume the next
  version of the standard will be named C++23.  Use of c++2b also reinforces
  the experimental nature of GCC's C++23 implementation.


gcc/

Add support for -std=c++2b
* doc/cpp.texi (__cplusplus): Document value for -std=c++2b
or -std=gnu++2b.
* doc/invoke.texi: Document -std=c++2b and -std=gnu++2b.

gcc/c-family

Add support for -std=c++2b
* c-common.h (cxx_dialect): Add cxx2b as a dialect.
* c.opt: Add options for -std=c++2b and -std=gnu++2b.
* c-opts.c (set_std_cxx2b): New.
(c_common_handle_option): Set options when -std=c++2b is enabled.
(c_common_post_options): Adjust comments.
(set_std_cxx20): Likewise.
* dwarf2out.c (highest_c_language): Recognise C++20 and C++23.
(gen_compile_unit_die): Recognise C++23.

gcc/testsuite

Add support for -std=c++2b
* lib/target-supports.exp (check_effective_target_c++2a_only):
rename to check_effective_target_c++20_only.
(check_effective_target_c++2a): rename to check_effective_target_c++20.
(check_effective_target_c++20): Return 1
if check_effective_target_c++20_only or
if check_effective_target_c++2b.
(check_effective_target_c++20_down): New.
(check_effective_target_c++2a_only): New.
(check_effective_target_c++2a): New.
* g++.dg/cpp2b/cplusplus.C: New.

libcpp
Add support for -std=c++2b
* include/cpplib.h (c_lang): Add CXX2B and GNUCXX2B.
* init.c (lang_defaults): Add rows for CXX2B and GNUCXX2B.
(cpp_init_builtins): Set __cplusplus to 202100L for C++2b.
---
 gcc/c-family/c-common.h|4 ++-
 gcc/c-family/c-opts.c  |   29 ++--
 gcc/c-family/c.opt |8 ++
 gcc/doc/cpp.texi   |7 +++--
 gcc/doc/invoke.texi|   10 
 gcc/dwarf2out.c|7 +
 gcc/testsuite/g++.dg/cpp2b/cplusplus.C |4 +++
 gcc/testsuite/lib/target-supports.exp  |   39 +++--
 libcpp/include/cpplib.h|3 +-
 libcpp/init.c  |7 +
 10 files changed, 98 insertions(+), 20 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index a65c78f7240..f562cdebf4c 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -738,7 +738,9 @@ enum cxx_dialect {
   /* C++17 */
   cxx17,
   /* C++20 */
-  cxx20
+  cxx20,
+  /* C++2b (C++23?) */
+  cxx2b
 };

 /* The C++ dialect being used. C++98 is the default.  */
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 3cdf41bc6e2..15f120d475d 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -113,6 +113,7 @@ static void set_std_cxx11 (int);
 static void set_std_cxx14 (int);
 static void set_std_cxx17 (int);
 static void set_std_cxx20 (int);
+static void set_std_cxx2b (int);
 static void set_std_c89 (int, int);
 static void set_std_c99 (int);
 static void set_std_c11 (int);
@@ -649,6 +650,12 @@ c_common_handle_option (size_t scode, const char
*arg, HOST_WIDE_INT value,
 set_std_cxx20 (code == OPT_std_c__20 /* ISO */);
   break;

+case OPT_std_c__2b:
+case OPT_std_gnu__2b:
+  if (!preprocessing_asm_p)
+set_std_cxx2b (code == OPT_std_c__2b /* ISO */);
+  break;
+
 case OPT_std_c90:
 case OPT_std_iso9899_199409:
   if (!preprocessing_asm_p)
@@ -1019,7 +1026,7 @@ c_common_post_options (const char **pfilename)
 warn_narrowing = 1;

   /* Unless -f{,no-}ext-numeric-literals has been used explicitly,
- for -std=c++{11,14,17,2a} default to -fno-ext-numeric-literals.  */
+ for -std=c++{11,14,17,20,2b} default to -fno-ext-numeric-literals.  */
   if (flag_iso && !global_options_set.x_flag_ext_numeric_literals)
 cpp_opts->ext_numeric_literals = 0;
 }
@@ -1763,7 +1770,7 @@ set_std_cxx20 (int iso)
   flag_no_gnu_keywords = iso;
   flag_no_nonansi_builtin = iso;
   flag_iso = iso;
-  /* C++17 includes the C11 standard library.  */
+  /* C++20 includes the C11 standard library.  */
   flag_isoc94 = 1;
   flag_isoc99 = 1;
   flag_isoc11 = 1;
@@ -1773,6 +1

Re: [PATCH] c++: Add support for -std=c++2b

[Paul Fee via Gcc-patches]

See "[PATCH v2] c++: Add support for -std=c++2b" for fixes.

On Fri, Jan 8, 2021 at 3:16 PM Marek Polacek  wrote:
>
> I think we should consider making this -std=c++23 right away this time,
> since we're on a three-year release schedule.  Up to Jason though.
>
> Marek
>

gcc

[Peter Liu via Gcc-patches]

(It's very urgent, therefore we kindly ask you to forward this email to your 
CEO. If you believe this has been sent to you in error, please ignore it. 
Thanks)Dear CEO,We are a Network Service Company which is the domain name 
registration center in Shanghai, China. On January 11, 2021, we received an 
application from Hongsheng Ltd requested "gcc" as their internet keyword and 
China (CN) domain names (gcc.cn, gcc.com.cn, gcc.net.cn, gcc.org.cn). But after 
checking it, we find this name conflict with your company name or trademark. In 
order to deal with this matter better, it's necessary to send email to you and 
confirm whether this company is your distributor or business partner in China?  
Best Regards
Peter Liu   Service & Operations Manager

China Registry (Head Office)



Tel: +86-02161918696

Fax: +86-02161918697

Mob: +86-13816428671

6012, Xingdi Building, No. 1698 Yishan Road, Shanghai 201103, China

*

This email contains privileged and confidential information intended for the 
addressee only. If you are not the intended recipient, please destroy this 
email and inform the sender immediately. We appreciate you respecting the 
confidentiality of this information by not disclosing or using the information 
in this email.

RE: [PATCH v2] aarch64: Add cpu cost tables for A64FX

[Qian, Jianhua]

Hi Richard

> -Original Message-
> From: Richard Sandiford 
> Sent: Friday, January 8, 2021 7:04 PM
> To: Qian, Jianhua/钱 建华 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH v2] aarch64: Add cpu cost tables for A64FX
> 
> Qian Jianhua  writes:
> > This patch add cost tables for A64FX.
> >
> > ChangeLog:
> > 2021-01-08 Qian jianhua 
> >
> > gcc/
> > * config/aarch64/aarch64-cost-tables.h (a64fx_extra_costs): New.
> > * config/aarch64/aarch64.c (a64fx_addrcost_table): New.
> > (a64fx_regmove_cost, a64fx_vector_cost): New.
> > (a64fx_tunings): Use the new added cost tables.
> 
> OK for trunk, thanks.  The v1 patch is OK for branches that support
> -mcpu=a64fx.
> 
> Would you like commit access, so that you can commit it yourself?
> If so, please fill out the form mentioned at the beginning of
> https://gcc.gnu.org/gitwrite.html listing me as sponsor.
> 
It‘s my pleasure. I've applied it.
Thank you so much.

I don't quite know the process of gcc source committing.
If I have the commit access, how will process be different?
And which branch, which range(aarch64?) could I commit patches to?

Regards,
Qian

> Alternatively, if you'd rather not for any reason, I'm happy to apply it for 
> you.
> 
> Thanks,
> Richard
>