Re: [PATCH] [i386] Extend splitter pattern to reversed condition by swapping then and else rtx. [PR target/104982]

2022-03-22 Thread Uros Bizjak via Gcc-patches
On Mon, Mar 21, 2022 at 2:08 PM liuhongt via Gcc-patches
 wrote:
>
> Failed to match this instruction:
> (set (reg/v:SI 88 [ z ])
> (if_then_else:SI (eq (zero_extract:SI (reg:SI 92)
> (const_int 1 [0x1])
> (zero_extend:SI (subreg:QI (reg:SI 93) 0)))
> (const_int 0 [0]))
> (reg:SI 95)
> (reg:SI 94)))
>
> but it's equal to
>
> (set (reg/v:SI 88 [ z ])
> (if_then_else:SI (ne (zero_extract:SI (reg:SI 92)
> (const_int 1 [0x1])
> (zero_extend:SI (subreg:QI (reg:SI 93) 0)))
> (const_int 0 [0]))
> (reg:SI 94)
> (reg:SI 95)))
>
> which is the exact existing splitter.
>
> The patch will fix below regressions:
>
> On x86-64, r12-7687 caused:
>
> FAIL: gcc.target/i386/bt-5.c scan-assembler-not sar[lq][ \t]
> FAIL: gcc.target/i386/bt-5.c scan-assembler-times bt[lq][ \t] 7
>
> Bootstrap and regtested on x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/104982
> * config/i386/i386.md (*jcc_bt_mask): Extend the
> following splitter to reversed condition.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/i386.md | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 02f298c2846..c74edd1aaef 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -14182,12 +14182,12 @@ (define_insn_and_split "*jcc_bt_mask"
>  (define_split
>[(set (match_operand:SWI248 0 "register_operand")
> (if_then_else:SWI248
> -(ne
> - (zero_extract:SWI48
> -  (match_operand:SWI48 1 "register_operand")
> -  (const_int 1)
> -  (zero_extend:SI (match_operand:QI 2 "register_operand")))
> - (const_int 0))
> +(match_operator 5 "bt_comparison_operator"
> + [(zero_extract:SWI48
> +   (match_operand:SWI48 1 "register_operand")
> +   (const_int 1)
> +   (zero_extend:SI (match_operand:QI 2 "register_operand")))
> +  (const_int 0)])
>  (match_operand:SWI248 3 "nonimmediate_operand")
>  (match_operand:SWI248 4 "nonimmediate_operand")))]
>"TARGET_USE_BT && TARGET_CMOVE
> @@ -14202,6 +14202,8 @@ (define_split
>  (match_dup 3)
>  (match_dup 4)))]
>  {
> +  if (GET_CODE (operands[5]) == EQ)
> +std::swap (operands[3], operands[4]);
>operands[2] = lowpart_subreg (SImode, operands[2], QImode);
>  })
>
> --
> 2.18.1
>


[PATCH] calls: Fix error recovery after sorry differently [PR104989]

2022-03-22 Thread Jakub Jelinek via Gcc-patches
Hi!

On Mon, Feb 28, 2022 at 07:52:56AM -, Roger Sayle wrote:
> This patch resolves PR c++/84964 which is an ICE in the middle-end after
> emitting a "sorry, unimplemented" message, and is a regression from
> earlier releases of GCC.  This issue is that after encountering a
> function call requiring an unreasonable amount of stack space, the
> code continues and falls foul of an assert checking that stack pointer
> has been correctly updated.  The fix is to (locally) consider aborted
> function calls as "no return", which skips this downstream sanity check.

As can be seen on PR104989, just setting ECF_NORETURN after sorry is quite
risky and leads to other ICEs.  The problem is that ECF_NORETURN calls
better should be at the end of basic blocks that don't have any fallthru
successor edges, otherwise we can ICE later.

This patch instead sets sibcall_failure if in pass == 0 (sibcall_failure
means that the tail call sequence is not useful/not desirable and throws
it away) and otherwise sets a new bool variable that will let us pass
the assertion and also throws away the whole call sequence, I think that is
best for error recovery.

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

2022-03-22  Jakub Jelinek  

PR rtl-optimization/104989
* calls.cc (expand_call): Don't set ECF_NORETURN in flags after
sorry for passing too large argument, instead set sibcall_failure
for pass == 0, or a new normal_failure flag otherwise.  If
normal_failure is set, don't assert all stack has been deallocated
at the end and throw away the whole insn sequence.

* g++.dg/other/pr104989.C: New test.

--- gcc/calls.cc.jj 2022-03-11 13:11:53.613095003 +0100
+++ gcc/calls.cc2022-03-21 11:21:52.997671148 +0100
@@ -3068,6 +3068,7 @@ expand_call (tree exp, rtx target, int i
   for (pass = try_tail_call ? 0 : 1; pass < 2; pass++)
 {
   int sibcall_failure = 0;
+  bool normal_failure = false;
   /* We want to emit any pending stack adjustments before the tail
 recursion "call".  That way we know any adjustment after the tail
 recursion call can be ignored if we indeed use the tail
@@ -3448,7 +3449,10 @@ expand_call (tree exp, rtx target, int i
{
  sorry ("passing too large argument on stack");
  /* Don't worry about stack clean-up.  */
- flags |= ECF_NORETURN;
+ if (pass == 0)
+   sibcall_failure = 1;
+ else
+   normal_failure = true;
  continue;
}
 
@@ -3905,9 +3909,12 @@ expand_call (tree exp, rtx target, int i
 
  /* Verify that we've deallocated all the stack we used.  */
  gcc_assert ((flags & ECF_NORETURN)
+ || normal_failure
  || known_eq (old_stack_allocated,
   stack_pointer_delta
   - pending_stack_adjust));
+ if (normal_failure)
+   normal_call_insns = NULL;
}
 
   /* If something prevents making this a sibling call,
--- gcc/testsuite/g++.dg/other/pr104989.C.jj2022-03-21 11:19:41.633496189 
+0100
+++ gcc/testsuite/g++.dg/other/pr104989.C   2022-03-21 11:20:08.248126431 
+0100
@@ -0,0 +1,9 @@
+// PR rtl-optimization/104989
+// { dg-do compile }
+// { dg-options "-fnon-call-exceptions" }
+
+struct a {
+  short b : -1ULL;
+};
+void c(...) { c(a()); }
+// { dg-excess-errors "" }


Jakub



Re: [PATCH] calls: Fix error recovery after sorry differently [PR104989]

2022-03-22 Thread Richard Biener via Gcc-patches
On Tue, 22 Mar 2022, Jakub Jelinek wrote:

> Hi!
> 
> On Mon, Feb 28, 2022 at 07:52:56AM -, Roger Sayle wrote:
> > This patch resolves PR c++/84964 which is an ICE in the middle-end after
> > emitting a "sorry, unimplemented" message, and is a regression from
> > earlier releases of GCC.  This issue is that after encountering a
> > function call requiring an unreasonable amount of stack space, the
> > code continues and falls foul of an assert checking that stack pointer
> > has been correctly updated.  The fix is to (locally) consider aborted
> > function calls as "no return", which skips this downstream sanity check.
> 
> As can be seen on PR104989, just setting ECF_NORETURN after sorry is quite
> risky and leads to other ICEs.  The problem is that ECF_NORETURN calls
> better should be at the end of basic blocks that don't have any fallthru
> successor edges, otherwise we can ICE later.
> 
> This patch instead sets sibcall_failure if in pass == 0 (sibcall_failure
> means that the tail call sequence is not useful/not desirable and throws
> it away) and otherwise sets a new bool variable that will let us pass
> the assertion and also throws away the whole call sequence, I think that is
> best for error recovery.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2022-03-22  Jakub Jelinek  
> 
>   PR rtl-optimization/104989
>   * calls.cc (expand_call): Don't set ECF_NORETURN in flags after
>   sorry for passing too large argument, instead set sibcall_failure
>   for pass == 0, or a new normal_failure flag otherwise.  If
>   normal_failure is set, don't assert all stack has been deallocated
>   at the end and throw away the whole insn sequence.
> 
>   * g++.dg/other/pr104989.C: New test.
> 
> --- gcc/calls.cc.jj   2022-03-11 13:11:53.613095003 +0100
> +++ gcc/calls.cc  2022-03-21 11:21:52.997671148 +0100
> @@ -3068,6 +3068,7 @@ expand_call (tree exp, rtx target, int i
>for (pass = try_tail_call ? 0 : 1; pass < 2; pass++)
>  {
>int sibcall_failure = 0;
> +  bool normal_failure = false;
>/* We want to emit any pending stack adjustments before the tail
>recursion "call".  That way we know any adjustment after the tail
>recursion call can be ignored if we indeed use the tail
> @@ -3448,7 +3449,10 @@ expand_call (tree exp, rtx target, int i
>   {
> sorry ("passing too large argument on stack");
> /* Don't worry about stack clean-up.  */
> -   flags |= ECF_NORETURN;
> +   if (pass == 0)
> + sibcall_failure = 1;
> +   else
> + normal_failure = true;
> continue;
>   }
>  
> @@ -3905,9 +3909,12 @@ expand_call (tree exp, rtx target, int i
>  
> /* Verify that we've deallocated all the stack we used.  */
> gcc_assert ((flags & ECF_NORETURN)
> +   || normal_failure
> || known_eq (old_stack_allocated,
>  stack_pointer_delta
>  - pending_stack_adjust));
> +   if (normal_failure)
> + normal_call_insns = NULL;
>   }
>  
>/* If something prevents making this a sibling call,
> --- gcc/testsuite/g++.dg/other/pr104989.C.jj  2022-03-21 11:19:41.633496189 
> +0100
> +++ gcc/testsuite/g++.dg/other/pr104989.C 2022-03-21 11:20:08.248126431 
> +0100
> @@ -0,0 +1,9 @@
> +// PR rtl-optimization/104989
> +// { dg-do compile }
> +// { dg-options "-fnon-call-exceptions" }
> +
> +struct a {
> +  short b : -1ULL;
> +};
> +void c(...) { c(a()); }
> +// { dg-excess-errors "" }
> 
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)


[PATCH] c++: extern thread_local declarations in constexpr [PR104994]

2022-03-22 Thread Jakub Jelinek via Gcc-patches
Hi!

C++14 to C++20 apparently should allow extern thread_local declarations in
constexpr functions, however useless they are there (because accessing
such vars is not valid in a constant expression, perhaps sizeof/decltype).
P2242 changed that for C++23 to passing through declaration but
https://cplusplus.github.io/CWG/issues/2552.html
has been filed for it yesterday.

The following patch implements the proposed wording of CWG 2552 in addition
to fixing the C++14 - C++20 handling bug.
If you'd like instead to keep the current pedantic C++23 wording for now,
that would mean taking out the first hunk (cxx_eval_constant_expression) and
g++.dg/cpp23/constexpr-nonlit2.C hunk.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk
(or ok without those 2 hunks for now)?

2022-03-22  Jakub Jelinek  

PR c++/104994
* constexpr.cc (cxx_eval_constant_expression): Don't diagnose passing
through extern thread_local declarations.  Change wording from
declaration to definition.
(potential_constant_expression_1): Don't diagnose extern thread_local
declarations.  Change wording from declared to defined.
* decl.cc (start_decl): Likewise.

* g++.dg/diagnostic/constexpr1.C: Change expected diagnostic wording
from declared to defined.
* g++.dg/cpp23/constexpr-nonlit1.C: Likewise.
(garply): Change dg-error into dg-bogus.
* g++.dg/cpp23/constexpr-nonlit2.C: Change expected diagnostic wording
from declaration to definition.
* g++.dg/cpp23/constexpr-nonlit6.C: Change expected diagnostic wording
from declared to defined.
* g++.dg/cpp23/constexpr-nonlit7.C: New test.
* g++.dg/cpp2a/constexpr-try5.C: Change expected diagnostic wording
from declared to defined.
* g++.dg/cpp2a/consteval3.C: Likewise.

--- gcc/cp/constexpr.cc.jj  2022-03-18 19:02:18.964688873 +0100
+++ gcc/cp/constexpr.cc 2022-03-21 15:52:09.000602363 +0100
@@ -6723,17 +6723,18 @@ cxx_eval_constant_expression (const cons
  }
 
if (VAR_P (r)
-   && (TREE_STATIC (r) || CP_DECL_THREAD_LOCAL_P (r))
+   && (TREE_STATIC (r)
+   || (CP_DECL_THREAD_LOCAL_P (r) && !DECL_REALLY_EXTERN (r)))
/* Allow __FUNCTION__ etc.  */
&& !DECL_ARTIFICIAL (r))
  {
if (!ctx->quiet)
  {
if (CP_DECL_THREAD_LOCAL_P (r))
- error_at (loc, "control passes through declaration of %qD "
+ error_at (loc, "control passes through definition of %qD "
 "with thread storage duration", r);
else
- error_at (loc, "control passes through declaration of %qD "
+ error_at (loc, "control passes through definition of %qD "
 "with static storage duration", r);
  }
*non_constant_p = true;
@@ -9188,17 +9189,17 @@ potential_constant_expression_1 (tree t,
   tmp = DECL_EXPR_DECL (t);
   if (VAR_P (tmp) && !DECL_ARTIFICIAL (tmp))
{
- if (CP_DECL_THREAD_LOCAL_P (tmp))
+ if (CP_DECL_THREAD_LOCAL_P (tmp) && !DECL_REALLY_EXTERN (tmp))
{
  if (flags & tf_error)
-   error_at (DECL_SOURCE_LOCATION (tmp), "%qD declared "
+   error_at (DECL_SOURCE_LOCATION (tmp), "%qD defined "
  "% in % context", tmp);
  return false;
}
  else if (TREE_STATIC (tmp))
{
  if (flags & tf_error)
-   error_at (DECL_SOURCE_LOCATION (tmp), "%qD declared "
+   error_at (DECL_SOURCE_LOCATION (tmp), "%qD defined "
  "% in % context", tmp);
  return false;
}
--- gcc/cp/decl.cc.jj   2022-03-14 10:34:34.246922669 +0100
+++ gcc/cp/decl.cc  2022-03-21 15:51:17.053317191 +0100
@@ -5774,15 +5774,15 @@ start_decl (const cp_declarator *declara
   && cxx_dialect < cxx23)
 {
   bool ok = false;
-  if (CP_DECL_THREAD_LOCAL_P (decl))
+  if (CP_DECL_THREAD_LOCAL_P (decl) && !DECL_REALLY_EXTERN (decl))
error_at (DECL_SOURCE_LOCATION (decl),
- "%qD declared % in %qs function only "
+ "%qD defined % in %qs function only "
  "available with %<-std=c++2b%> or %<-std=gnu++2b%>", decl,
  DECL_IMMEDIATE_FUNCTION_P (current_function_decl)
  ? "consteval" : "constexpr");
   else if (TREE_STATIC (decl))
error_at (DECL_SOURCE_LOCATION (decl),
- "%qD declared % in %qs function only available "
+ "%qD defined % in %qs function only available "
  "with %<-std=c++2b%> or %<-std=gnu++2b%>", decl,
  DECL_IMMEDIATE_FUNCTION_P (current_function_decl)
  ? "consteval" : "constexpr");
--- gcc/testsuite/g++.dg/diagnostic/c

[committed] testsuite: Add testcase for no longer failing PR [PR102645]

2022-03-22 Thread Jakub Jelinek via Gcc-patches
Hi!

This test started ICEing with r12-3876 but stopped with r12-5264.

Committed to trunk as obvious.

Can we close the PR (are the unroll-and-jam bugs if any are latent) tracked
elsewhere?

2022-03-22  Jakub Jelinek  

PR tree-optimization/102645
* gcc.c-torture/compile/pr102645.c: New test.

--- gcc/testsuite/gcc.c-torture/compile/pr102645.c.jj   2022-03-21 
19:24:05.926091267 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr102645.c  2022-03-21 
19:23:52.536275156 +0100
@@ -0,0 +1,18 @@
+/* PR tree-optimization/102645 */
+
+volatile int a[1], d;
+int b, c;
+
+int
+main ()
+{
+  if (b && c)
+for (c = 0; c < 3; c++)
+  {
+   for (int e = 0; e < 6; e++)
+ for (int f = 0; f < 12; f++)
+   d && a[0];
+   continue;
+  }
+  return 0;
+}

Jakub



Re: [committed] testsuite: Add testcase for no longer failing PR [PR102645]

2022-03-22 Thread Richard Biener via Gcc-patches
On Tue, 22 Mar 2022, Jakub Jelinek wrote:

> Hi!
> 
> This test started ICEing with r12-3876 but stopped with r12-5264.
> 
> Committed to trunk as obvious.
> 
> Can we close the PR (are the unroll-and-jam bugs if any are latent) tracked
> elsewhere?

I think we can close the bug, I don't think there are any known
unroll-and-jam bugs left - I obviously missed this one ...

Richard.

> 2022-03-22  Jakub Jelinek  
> 
>   PR tree-optimization/102645
>   * gcc.c-torture/compile/pr102645.c: New test.
> 
> --- gcc/testsuite/gcc.c-torture/compile/pr102645.c.jj 2022-03-21 
> 19:24:05.926091267 +0100
> +++ gcc/testsuite/gcc.c-torture/compile/pr102645.c2022-03-21 
> 19:23:52.536275156 +0100
> @@ -0,0 +1,18 @@
> +/* PR tree-optimization/102645 */
> +
> +volatile int a[1], d;
> +int b, c;
> +
> +int
> +main ()
> +{
> +  if (b && c)
> +for (c = 0; c < 3; c++)
> +  {
> + for (int e = 0; e < 6; e++)
> +   for (int f = 0; f < 12; f++)
> + d && a[0];
> + continue;
> +  }
> +  return 0;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Ivo Totev; HRB 36809 (AG Nuernberg)


Re: [PATCH v2] Add TARGET_MOVE_WITH_MODE_P

2022-03-22 Thread Richard Biener via Gcc-patches
On Tue, Mar 22, 2022 at 3:51 AM H.J. Lu  wrote:
>
> On Mon, Mar 14, 2022 at 8:44 AM Richard Sandiford
>  wrote:
> >
> > Richard Biener  writes:
> > > On Wed, Mar 9, 2022 at 7:04 PM Richard Sandiford
> > >  wrote:
> > >>
> > >> Richard Biener via Gcc-patches  writes:
> > >> > On Wed, Mar 2, 2022 at 10:18 PM H.J. Lu  wrote:
> > >> >>
> > >> >> On Wed, Mar 02, 2022 at 09:51:26AM +0100, Richard Biener wrote:
> > >> >> > On Tue, Mar 1, 2022 at 11:41 PM H.J. Lu via Gcc-patches
> > >> >> >  wrote:
> > >> >> > >
> > >> >> > > Add TARGET_FOLD_MEMCPY_MAX for the maximum number of bytes to 
> > >> >> > > fold memcpy.
> > >> >> > > The default is
> > >> >> > >
> > >> >> > > MOVE_MAX * MOVE_RATIO (optimize_function_for_size_p (cfun))
> > >> >> > >
> > >> >> > > For x86, it is MOVE_MAX to restore the old behavior before
> > >> >> >
> > >> >> > I know we've discussed this to death in the PR, I just want to 
> > >> >> > repeat here
> > >> >> > that the GIMPLE folding expects to generate a single load and a 
> > >> >> > single
> > >> >> > store (that is what it does on the GIMPLE level) which is why 
> > >> >> > MOVE_MAX
> > >> >> > was chosen originally (it's documented to what a "single 
> > >> >> > instruction" does).
> > >> >> > In practice MOVE_MAX does not seem to cover vector register sizes
> > >> >> > so Richard pulled MOVE_RATIO which is really intended to cover
> > >> >> > the case of using multiple instructions for moving memory (but then 
> > >> >> > I
> > >> >> > don't remember whether for the ARM case the single load/store GIMPLE
> > >> >> > will be expanded to multiple load/store instructions).
> > >> >> >
> > >> >> > TARGET_FOLD_MEMCPY_MAX sounds like a stop-gap solution,
> > >> >> > being very specific for memcpy folding (we also fold memmove btw).
> > >> >> >
> > >> >> > There is also MOVE_MAX_PIECES which _might_ be more appropriate
> > >> >> > than MOVE_MAX here and still honor the idea of single instructions.
> > >> >> > Now neither arm nor aarch64 define this and it defaults to MOVE_MAX,
> > >> >> > not MOVE_MAX * MOVE_RATIO.
> > >> >> >
> > >> >> > So if we need a new hook then that hook should at least get the
> > >> >> > 'speed' argument of MOVE_RATIO and it should get a better name.
> > >> >> >
> > >> >> > I still think that it should be possible to improve the insn check 
> > >> >> > to
> > >> >> > avoid use of "disabled" modes, maybe that's also a point to add
> > >> >> > a new hook like .move_with_mode_p or so?  To quote, we do
> > >> >>
> > >> >> Here is the v2 patch to add TARGET_MOVE_WITH_MODE_P.
> > >> >
> > >> > Again I'd like to shine light on MOVE_MAX_PIECES which explicitely
> > >> > mentions "a load or store used TO COPY MEMORY" (emphasis mine)
> > >> > and whose x86 implementation would already be fine (doing larger moves
> > >> > and also not doing too large moves).  But appearantly the arm folks
> > >> > decided that that's not fit and instead (mis-?)used MOVE_MAX * 
> > >> > MOVE_RATIO.
> > >>
> > >> It seems like there are old comments and old documentation that justify
> > >> both interpretations, so there are good arguments on both sides.  But
> > >> with this kind of thing I think we have to infer the meaning of the
> > >> macro from the way it's currently used, rather than trusting such old
> > >> and possibly out-of-date and contradictory information.
> > >>
> > >> FWIW, I agree that (if we exclude old reload, which we should!) the
> > >> only direct uses of MOVE_MAX before the patch were not specific to
> > >> integer registers and so MOVE_MAX should include vectors if the
> > >> target wants vector modes to be used for general movement.
> > >>
> > >> Even if people disagree that that's the current meaning, I think it's
> > >> at least a sensible meaning.  It provides information that AFAIK isn't
> > >> available otherwise, and it avoids overlap with MAX_FIXED_MODE_SIZE.
> > >>
> > >> So FWIW, I think it'd be reasonable to change non-x86 targets if they
> > >> want vector modes to be used for single-insn copies.
> > >
> > > Note a slight complication in the GIMPLE folding case is that we
> > > do not end up using vector modes but we're using "fake"
> > > integer modes like OImode which x86 has move patterns for.
> > > If we'd use vector modes we could use existing target hooks to
> > > eventually decide whether auto-using those is desired or not.
> >
> > Hmm, yeah.  Certainly we shouldn't require the target to support
> > a scalar integer equivalent of every vector mode.
> >
>
> I'd like to resolve this before GCC 12 is released.

I've come to the conclusion that we should revert r12-3482-g5f6a6c91d7c592,
it abuses MOVE_MAX * MOVE_RATIO to trick GIMPLE into thinking we can
move a larger amount of data with a single instruction while in reality it wants
to use multiple load/store stmts - that's something the GIMPLE folding
doesn't do.
If arm wants to use larger moves with a single instruction it should
adjust MOVE_MAX
instead.  In fact the motivating testcase doesn't use larg

[PATCH] lto-plugin: Use GNU ld or Solaris ld version script in preference to -export-symbols-regex [PR102426]

2022-03-22 Thread Jakub Jelinek via Gcc-patches
Hi!

As reported, libtool -export-symbols-regex doesn't work on Solaris
when using GNU ld instead of Sun ld, libtool just always assumes Sun ld.
As I'm unsure what is the maintainance status of libtool right now,
this patch solves it on the lto-plugin side instead, tests at configure time
similar way how libssp and other target libraries test for symbol versioning
(except omitting the symbol version because we just want one GLOBAL symbol
and rest of them LOCAL), and will use the current way of
-export-symbols-regex onload as fallback when this doesn't work.

Bootstrapped/regtested on x86_64-linux and i686-linux (where it now uses
the GNU versioning instead of -export-symbols-regex onload).
Ok for trunk if it works for Rainer too (both Sun and GNU ld)?

2022-03-22  Jakub Jelinek  

PR lto/102426
* configure.ac (LTO_PLUGIN_USE_SYMVER, LTO_PLUGIN_USE_SYMVER_GNU,
LTO_PLUGIN_USE_SYMVER_SUN): New test for symbol versioning support.
* Makefile.am (version_arg, version_dep): Set conditionally based
on LTO_PLUGIN_USE_SYMVER*.
(liblto_plugin_la_LDFLAGS): Use $(version_arg) instead of
-export-symbols-regex onload.
(liblto_plugin_la_DEPENDENCIES): Depend on $(version_dep).
* lto-plugin.map: New file.
* configure: Regenerated.
* Makefile.in: Regenerated.

--- lto-plugin/configure.ac.jj  2020-04-27 09:11:14.431603556 +0200
+++ lto-plugin/configure.ac 2022-03-21 14:42:05.913555824 +0100
@@ -50,6 +50,43 @@ AC_SUBST(real_target_noncanonical)
 # Determine what GCC version number to use in filesystem paths.
 GCC_BASE_VER
 
+AC_MSG_CHECKING([whether symbol versioning is supported])
+lto_plugin_use_symver=no
+if test x$gcc_no_link = xyes; then
+  # If we cannot link, we cannot build shared libraries, so do not use
+  # symbol versioning.
+  lto_plugin_use_symver=no
+else
+  save_LDFLAGS="$LDFLAGS"
+  LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
+  cat > conftest.map < conftest.map <&5
+$as_echo_n "checking whether symbol versioning is supported... " >&6; }
+lto_plugin_use_symver=no
+if test x$gcc_no_link = xyes; then
+  # If we cannot link, we cannot build shared libraries, so do not use
+  # symbol versioning.
+  lto_plugin_use_symver=no
+else
+  save_LDFLAGS="$LDFLAGS"
+  LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
+  cat > conftest.map  conftest.map &5
+$as_echo "$lto_plugin_use_symver" >&6; }
+ if test "x$lto_plugin_use_symver" != xno; then
+  LTO_PLUGIN_USE_SYMVER_TRUE=
+  LTO_PLUGIN_USE_SYMVER_FALSE='#'
+else
+  LTO_PLUGIN_USE_SYMVER_TRUE='#'
+  LTO_PLUGIN_USE_SYMVER_FALSE=
+fi
+
+ if test "x$lto_plugin_use_symver" = xgnu; then
+  LTO_PLUGIN_USE_SYMVER_GNU_TRUE=
+  LTO_PLUGIN_USE_SYMVER_GNU_FALSE='#'
+else
+  LTO_PLUGIN_USE_SYMVER_GNU_TRUE='#'
+  LTO_PLUGIN_USE_SYMVER_GNU_FALSE=
+fi
+
+ if test "x$lto_plugin_use_symver" = xsun; then
+  LTO_PLUGIN_USE_SYMVER_SUN_TRUE=
+  LTO_PLUGIN_USE_SYMVER_SUN_FALSE='#'
+else
+  LTO_PLUGIN_USE_SYMVER_SUN_TRUE='#'
+  LTO_PLUGIN_USE_SYMVER_SUN_FALSE=
+fi
+
+
 case `pwd` in
   *\ * | *\*)
 { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: Libtool does not cope 
well with whitespace in \`pwd\`" >&5
@@ -11981,7 +12081,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11984 "configure"
+#line 12084 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12087,7 +12187,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12090 "configure"
+#line 12190 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12558,6 +12658,18 @@ if test -z "${am__fastdepCC_TRUE}" && te
   as_fn_error $? "conditional \"am__fastdepCC\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
+if test -z "${LTO_PLUGIN_USE_SYMVER_TRUE}" && test -z 
"${LTO_PLUGIN_USE_SYMVER_FAL

Re: [PATCH] lto-plugin: Use GNU ld or Solaris ld version script in preference to -export-symbols-regex [PR102426]

2022-03-22 Thread Rainer Orth
Hi Jakub,

> As reported, libtool -export-symbols-regex doesn't work on Solaris
> when using GNU ld instead of Sun ld, libtool just always assumes Sun ld.
> As I'm unsure what is the maintainance status of libtool right now,

as it happens, libtool 2.4.7 has just been released on 2022-03-16 after
a hiatus of more than 5 years.  Whatever that means for future
maintenance...

> this patch solves it on the lto-plugin side instead, tests at configure time
> similar way how libssp and other target libraries test for symbol versioning
> (except omitting the symbol version because we just want one GLOBAL symbol
> and rest of them LOCAL), and will use the current way of
> -export-symbols-regex onload as fallback when this doesn't work.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (where it now uses
> the GNU versioning instead of -export-symbols-regex onload).
> Ok for trunk if it works for Rainer too (both Sun and GNU ld)?

It did without any issues: tested on i386-pc-solaris2.11 (gas/ld and
gas/gld) and sparc-sun-solaris2.11 (gas/ld).

Rainer

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


Re: [PATCH] lto-plugin: Use GNU ld or Solaris ld version script in preference to -export-symbols-regex [PR102426]

2022-03-22 Thread Richard Biener via Gcc-patches



> Am 22.03.2022 um 10:28 schrieb Rainer Orth :
> 
> Hi Jakub,
> 
>> As reported, libtool -export-symbols-regex doesn't work on Solaris
>> when using GNU ld instead of Sun ld, libtool just always assumes Sun ld.
>> As I'm unsure what is the maintainance status of libtool right now,
> 
> as it happens, libtool 2.4.7 has just been released on 2022-03-16 after
> a hiatus of more than 5 years.  Whatever that means for future
> maintenance...
> 
>> this patch solves it on the lto-plugin side instead, tests at configure time
>> similar way how libssp and other target libraries test for symbol versioning
>> (except omitting the symbol version because we just want one GLOBAL symbol
>> and rest of them LOCAL), and will use the current way of
>> -export-symbols-regex onload as fallback when this doesn't work.
>> 
>> Bootstrapped/regtested on x86_64-linux and i686-linux (where it now uses
>> the GNU versioning instead of -export-symbols-regex onload).
>> Ok for trunk if it works for Rainer too (both Sun and GNU ld)?
> 
> It did without any issues: tested on i386-pc-solaris2.11 (gas/ld and
> gas/gld) and sparc-sun-solaris2.11 (gas/ld).

Ok.

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


Re: [PATCH v9 06/12] LoongArch Port: Builtin functions.

2022-03-22 Thread Richard Sandiford via Gcc-patches
Hi,

Thanks for the update.  It looks like there are some unaddressed
comments from the v8 review:

chenglulu  writes:
> gcc/
>
>   * config/loongarch/larchintrin.h: New file.
>   * config/loongarch/loongarch-builtins.cc: New file.
> ---
>  gcc/config/loongarch/larchintrin.h | 409 +
>  gcc/config/loongarch/loongarch-builtins.cc | 511 +
>  2 files changed, 920 insertions(+)
>  create mode 100644 gcc/config/loongarch/larchintrin.h
>  create mode 100644 gcc/config/loongarch/loongarch-builtins.cc
>
> diff --git a/gcc/config/loongarch/larchintrin.h 
> b/gcc/config/loongarch/larchintrin.h
> new file mode 100644
> index 000..fa63c6606bc
> --- /dev/null
> +++ b/gcc/config/loongarch/larchintrin.h
> @@ -0,0 +1,409 @@
> +/* Intrinsics for LoongArch BASE operations.
> +   Copyright (C) 2021-2022 Free Software Foundation, Inc.
> +   Contributed by Loongson Ltd.
> +
> +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.
> +
> +Under Section 7 of GPL version 3, you are granted additional
> +permissions described in the GCC Runtime Library Exception, version
> +3.1, as published by the Free Software Foundation.
> +
> +You should have received a copy of the GNU General Public License and
> +a copy of the GCC Runtime Library Exception along with this program;
> +see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> +.  */
> +
> +#ifndef _GCC_LOONGARCH_BASE_INTRIN_H
> +#define _GCC_LOONGARCH_BASE_INTRIN_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +typedef struct drdtime
> +{
> +  unsigned long dvalue;
> +  unsigned long dtimeid;
> +} __drdtime_t;
> +
> +typedef struct rdtime
> +{
> +  unsigned int value;
> +  unsigned int timeid;
> +} __rdtime_t;
> +
> +#ifdef __loongarch64
> +extern __inline __drdtime_t
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +__builtin_loongarch_rdtime_d (void)
> +{
> +  __drdtime_t drdtime;
> +  __asm__ volatile (
> +"rdtime.d\t%[val],%[tid]\n\t"
> +: [val]"=&r"(drdtime.dvalue),[tid]"=&r"(drdtime.dtimeid)
> +:);
> +  return drdtime;

It's usually better to use __foo names for local variables and
parameters, in case the user defines a macro called (in this case)
drdtime.

> +}
> +#define __rdtime_d __builtin_loongarch_rdtime_d
> +#endif

Are both of these names “public”?  In other words, can users use
__builtin_longarch_rdtime_d directly, instead of using __rdtime_d?

If only __rdtime_d is public then it might be better to define
the function directly, since that will give better error messages.

Putting the previous two comments together, I was thinking of
something like this:

__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
__rdtime_d (void)
{
  __drdtime_t __drdtime;
  __asm__ volatile (
"rdtime.d\t%[val],%[tid]\n\t"
: [val]"=&r"(__drdtime.dvalue),[tid]"=&r"(__drdtime.dtimeid)
:);
  return __drdtime;
}

Same idea for…

> +
> +extern __inline __rdtime_t
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +__builtin_loongarch_rdtimeh_w (void)
> +{
> +  __rdtime_t rdtime;
> +  __asm__ volatile (
> +"rdtimeh.w\t%[val],%[tid]\n\t"
> +: [val]"=&r"(rdtime.value),[tid]"=&r"(rdtime.timeid)
> +:);
> +  return rdtime;
> +}
> +#define __rdtimeh_w __builtin_loongarch_rdtimeh_w
> +
> +extern __inline __rdtime_t
> +__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
> +__builtin_loongarch_rdtimel_w (void)
> +{
> +  __rdtime_t rdtime;
> +  __asm__ volatile (
> +"rdtimel.w\t%[val],%[tid]\n\t"
> +: [val]"=&r"(rdtime.value),[tid]"=&r"(rdtime.timeid)
> +:);
> +  return rdtime;
> +}
> +#define __rdtimel_w __builtin_loongarch_rdtimel_w

…these two functions, and for the later functions where you have
a __builtin_* function defined directly in the header file.

> […]
> +/* Invoke MACRO (COND) for each fcmp.cond.{s/d} condition.  */
> +#define LARCH_FP_CONDITIONS(MACRO) \
> +  MACRO (f), \
> +  MACRO (un),\
> +  MACRO (eq),\
> +  MACRO (ueq),   \
> +  MACRO (olt),   \
> +  MACRO (ult),   \
> +  MACRO (ole),   \
> +  MACRO (ule),   \
> +  MACRO (sf),\
> +  MACRO (ngle),  \
> +  MACRO (seq),   \
> +  MACRO (ngl),   \
> +  MACRO (lt),\
> +  MACRO (nge),   \
> +  MACRO (le),\
> +  MACRO (ngt)
> +
> +/* Enumerates the codes above as LARCH_FP_COND_.  */
> +#define DECLARE_LARCH_COND(X) LARCH_FP_COND_##X
> +enum loongarch_fp_condition
> +{
> +  LARCH_FP_CONDITIONS

Re: [PATCH v9 11/12] LoongArch Port: gcc/testsuite

2022-03-22 Thread Richard Sandiford via Gcc-patches
chenglulu  writes:
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 737e1a8913b..843b508b010 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -286,6 +286,10 @@ proc check_configured_with { pattern } {
>  proc check_weak_available { } {
>  global target_cpu
>  
> +if { [ string first "loongarch" $target_cpu ] >= 0 } {
> +return 1
> +}
> +
>  # All mips targets should support it
>  
>  if { [ string first "mips" $target_cpu ] >= 0 } {

Please drop this part, it shouldn't be necessary.

LGTM otherwise, thanks.

Richard


Re: [PATCH v9 12/12] LoongArch Port: Add doc.

2022-03-22 Thread Richard Sandiford via Gcc-patches
chenglulu  writes:
> +@item -msmall-data-limit=@var{number}
> +@opindex -msmall-data-limit
> +Put global and static data smaller than @code{number} bytes into a special
> +section (on some targets).  The default value is 0.

One minor left-over from v8: this should be @var{number}
rather than @code{number}, since it's placeholder for something
that the user fills in.

LGTM otherwise, thanks.

Richard


Re: [PATCH v9 00/12] Add LoongArch support.

2022-03-22 Thread Richard Sandiford via Gcc-patches
chenglulu  writes:
> Hi, all:
>
> This is the v9 version of LoongArch Port based on 
> 9fc8f278ebebc57537dc0cb9d33e36d932be0bc3.
> Please review.

Thanks for the update.  I've sent follows-up for parts 4, 6, 11 and 12,
but otherwise v9 addresses all the comments I had.  The series LGTM
with those issues fixed.

Richard

> We know it is stage4, I think it is ok for a new prot.
> The kernel side upstream waiting for a approval by gcc side,
> if it is blocked by stage4, a approval for GCC13 will be appreciation.
>
> The LoongArch architecture (LoongArch) is an Instruction Set
> Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
> style.
> The documents are on
> https://loongson.github.io/LoongArch-Documentation/README-EN.html
>
> The ELF ABI Documents are on:
> https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
>
> The binutils has been merged into trunk:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=560b3fe208255ae909b4b1c88ba9c28b09043307
>
> Note: We split -mabi= into -mabi=lp64d/f/s, the new options not support by 
> upstream binutils yet,
> this GCC port requires the following patch applied to binutils to build.
> https://github.com/loongson/binutils-gdb/commit/aacb0bf860f02aa5a7dcb76dd0e392bf871c7586
> (will be submitted to upstream after gcc side comfirmed)
>
> We have compiled more than 300 CLFS packages with this compiler.
> The CLFS are currently used on Cfarm machines gcc400 and gcc401.
>
> changelog:
>
> v1 -> v2
> 1. Split patch set.
> 2. Change some code style.
> 3. Add -mabi=lp64d/f/s options.
> 4. Change GLIBC_DYNAMIC_LINKER_LP64 name.
>
> v2 -> v3
> 1. Change some code style.
> 2. Bug fix.
>
> v3 -> v4
> 1. Change some code style.
> 2. Bug fix.
> 3. Delete some builtin macros.
>
> v4 -> v5
> 1. delete wrong insn zero_extendsidi2_internal.
> 2. Adjust some build options.
> 3. Change some .c files to .cc.
>
> v5 -> v6
> 1. Fix compilation issues. The generated files *.opt and *.h
>are generated to $(objdir).
>
> v6 -> v7
> 1. Bug fix.
> 2. Change some code style.
>
> v7 -> v8
> 1. Add new addressing type ADDRESS_REG_REG support.
> 2. Modify documentation.
> 3. Eliminate compile-time warnings.
>
> v8 -> v9
> 1. Undefine the hook TARGET_TRULY_NOOP_TRUNCATION under the architecture.
> 2. Delete some unsed hooks.
> 3. Change some code style.
> 4. Modify documentation.
>
> *** BLURB HERE ***
>
> chenglulu (12):
>   LoongArch Port: Regenerate configure
>   LoongArch Port: gcc build
>   LoongArch Port: Regenerate gcc/configure.
>   LoongArch Port: Machine description files.
>   LoongArch Port: Machine description C files and .h files.
>   LoongArch Port: Builtin functions.
>   LoongArch Port: Builtin macros.
>   LoongArch Port: libgcc
>   LoongArch Port: Regenerate libgcc/configure.
>   LoongArch Port: libgomp
>   LoongArch Port: gcc/testsuite
>   LoongArch Port: Add doc.
>
>  config/picflag.m4 |3 +
>  configure |   10 +-
>  configure.ac  |   10 +-
>  contrib/config-list.mk|4 +-
>  contrib/gcc_update|2 +
>  .../config/loongarch/loongarch-common.cc  |   43 +
>  gcc/config.gcc|  435 +-
>  gcc/config/host-linux.cc  |2 +
>  gcc/config/loongarch/constraints.md   |  203 +
>  gcc/config/loongarch/generic.md   |  118 +
>  gcc/config/loongarch/genopts/genstr.sh|  104 +
>  .../loongarch/genopts/loongarch-strings   |   58 +
>  gcc/config/loongarch/genopts/loongarch.opt.in |  179 +
>  gcc/config/loongarch/gnu-user.h   |   80 +
>  gcc/config/loongarch/la464.md |  132 +
>  gcc/config/loongarch/larchintrin.h|  409 ++
>  gcc/config/loongarch/linux.h  |   50 +
>  gcc/config/loongarch/loongarch-builtins.cc|  511 ++
>  gcc/config/loongarch/loongarch-c.cc   |  109 +
>  gcc/config/loongarch/loongarch-cpu.cc |  206 +
>  gcc/config/loongarch/loongarch-cpu.h  |   30 +
>  gcc/config/loongarch/loongarch-def.c  |  179 +
>  gcc/config/loongarch/loongarch-def.h  |  151 +
>  gcc/config/loongarch/loongarch-driver.cc  |  187 +
>  gcc/config/loongarch/loongarch-driver.h   |   69 +
>  gcc/config/loongarch/loongarch-ftypes.def |  106 +
>  gcc/config/loongarch/loongarch-modes.def  |   25 +
>  gcc/config/loongarch/loongarch-opts.cc|  578 ++
>  gcc/config/loongarch/loongarch-opts.h |   90 +
>  gcc/config/loongarch/loongarch-protos.h   |  174 +
>  gcc/config/loongarch/loongarch-str.h  |   59 +
>  gcc/config/loongarch/loongarch-tune.h |   50 +
>  gcc/config/loongarch/loongarch.cc | 5912 +
>  gcc/config/loongarch/loongarch.h  | 1147 
>  gcc/config/loongarch/loongarch.md | 3412 ++
>  gcc/config/loongarch/loongarch.opt

[PATCH] aarch64: update error message format.

2022-03-22 Thread Martin Liška

Pushed to master.

Martin

Use 'qs' and remove usage '(%qs)'.

PR target/104898

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_handle_attr_arch):
Use 'qs' and remove usage '(%qs)'.
(aarch64_handle_attr_cpu): Likewise.
(aarch64_handle_attr_tune): Likewise.
(aarch64_handle_attr_isa_flags): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/branch-protection-attr.c:
Use 'qs' and remove usage '(%qs)'.
* gcc.target/aarch64/spellcheck_1.c: Likewise.
* gcc.target/aarch64/spellcheck_2.c: Likewise.
* gcc.target/aarch64/spellcheck_3.c: Likewise.
---
 gcc/config/aarch64/aarch64.cc  | 14 +++---
 .../gcc.target/aarch64/branch-protection-attr.c|  2 +-
 gcc/testsuite/gcc.target/aarch64/spellcheck_1.c|  2 +-
 gcc/testsuite/gcc.target/aarch64/spellcheck_2.c|  2 +-
 gcc/testsuite/gcc.target/aarch64/spellcheck_3.c|  2 +-
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 903c842d65a..2f559600cff 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -18423,11 +18423,11 @@ aarch64_handle_attr_arch (const char *str)
error ("missing name in % pragma or attribute");
break;
   case AARCH64_PARSE_INVALID_ARG:
-   error ("invalid name (%qs) in % pragma or 
attribute", str);
+   error ("invalid name %qs in % pragma or attribute", 
str);
aarch64_print_hint_for_arch (str);
break;
   case AARCH64_PARSE_INVALID_FEATURE:
-   error ("invalid feature modifier %s of value (%qs) in "
+   error ("invalid feature modifier %s of value %qs in "
   "% pragma or attribute", invalid_extension.c_str (), 
str);
aarch64_print_hint_for_extensions (invalid_extension);
break;
@@ -18465,11 +18465,11 @@ aarch64_handle_attr_cpu (const char *str)
error ("missing name in % pragma or attribute");
break;
   case AARCH64_PARSE_INVALID_ARG:
-   error ("invalid name (%qs) in % pragma or 
attribute", str);
+   error ("invalid name %qs in % pragma or attribute", 
str);
aarch64_print_hint_for_core (str);
break;
   case AARCH64_PARSE_INVALID_FEATURE:
-   error ("invalid feature modifier %s of value (%qs) in "
+   error ("invalid feature modifier %qs of value %qs in "
   "% pragma or attribute", invalid_extension.c_str (), 
str);
aarch64_print_hint_for_extensions (invalid_extension);
break;
@@ -18496,7 +18496,7 @@ aarch64_handle_attr_cpu (const char *str)
  " attribute");
break;
  case AARCH64_PARSE_INVALID_ARG:
-   error ("invalid protection type (%qs) in % pragma or attribute", err_str);
break;
  case AARCH64_PARSE_OK:
@@ -18531,7 +18531,7 @@ aarch64_handle_attr_tune (const char *str)
   switch (parse_res)
 {
   case AARCH64_PARSE_INVALID_ARG:
-   error ("invalid name (%qs) in % pragma or 
attribute", str);
+   error ("invalid name %qs in % pragma or attribute", 
str);
aarch64_print_hint_for_core (str);
break;
   default:
@@ -18576,7 +18576,7 @@ aarch64_handle_attr_isa_flags (char *str)
break;
 
   case AARCH64_PARSE_INVALID_FEATURE:

-   error ("invalid feature modifier %s of value (%qs) in "
+   error ("invalid feature modifier %qs of value %qs in "
   "% pragma or attribute", invalid_extension.c_str (), 
str);
break;
 
diff --git a/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c b/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c

index 1d6e55f3907..272000c2747 100644
--- a/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c
+++ b/gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c
@@ -4,7 +4,7 @@ void __attribute__ ((target("branch-protection=leaf")))
 foo1 ()
 {
 }
-/* { dg-error {invalid protection type \('leaf'\) in 'target\("branch-protection="\)' 
pragma or attribute} "" { target *-*-* } 5 } */
+/* { dg-error {invalid protection type 'leaf' in 'target\("branch-protection="\)' pragma 
or attribute} "" { target *-*-* } 5 } */
 /* { dg-error {pragma or attribute 'target\("branch-protection=leaf"\)' is not valid} 
"" { target *-*-* } 5 } */
 
 void __attribute__ ((target("branch-protection=none+pac-ret")))

diff --git a/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c 
b/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
index 8654674fc67..7f58be04bb1 100644
--- a/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/spellcheck_1.c
@@ -4,6 +4,6 @@ __attribute__((target ("arch=armv8-a-typo"))) void
 foo ()
 {
   /* { dg-message "valid arguments are: \[^\n\r]*(; did you mean 'armv*'?)?"  
"" { target *-*-* } .-1 } */
-  /* { dg-error "invalid name \\('armv8-a-typo'\\) in 'target\\(\"arch=\"\\)' pragma or 
attribute"  "" { target *-*-* } .-2 } */
+  /* { dg-error "invalid name

[PATCH] rs6000: update error message format.

2022-03-22 Thread Martin Liška

Pushed to master as obvious.

PR target/104898

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_option_override_internal):
Use %qs instead of (%qs).
---
 gcc/config/rs6000/rs6000.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 283e8306ff7..a7645820b1e 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -4345,7 +4345,7 @@ rs6000_option_override_internal (bool global_init_p)
rs6000_veclib_handler = rs6000_builtin_vectorized_libmass;
  else
{
- error ("unknown vectorization library ABI type (%qs) for "
+ error ("unknown vectorization library ABI type %qs for "
 "%qs switch", rs6000_veclibabi_name, "-mveclibabi=");
  ret = false;
}
--
2.35.1



[PATCH] i386: update error message format.

2022-03-22 Thread Martin Liška

Pushed to master as obvious.

Use '%qs' instead of '(%qs)'.

gcc/ChangeLog:

* config/i386/i386-options.cc (ix86_option_override_internal):
  Use '%qs' instead of '(%qs)'.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr99753.c: Update test.
* gcc.target/i386/spellcheck-options-1.c: Likewise.
* gcc.target/i386/spellcheck-options-2.c: Likewise.
* gcc.target/i386/spellcheck-options-4.c: Likewise.
---
 gcc/config/i386/i386-options.cc  | 8 
 gcc/testsuite/gcc.target/i386/pr99753.c  | 2 +-
 gcc/testsuite/gcc.target/i386/spellcheck-options-1.c | 2 +-
 gcc/testsuite/gcc.target/i386/spellcheck-options-2.c | 2 +-
 gcc/testsuite/gcc.target/i386/spellcheck-options-4.c | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 80553936410..32cc58a764b 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -2212,8 +2212,8 @@ ix86_option_override_internal (bool main_args_p,
   if (i == pta_size)
 {
   error (main_args_p
-? G_("bad value (%qs) for %<-march=%> switch")
-: G_("bad value (%qs) for % attribute"),
+? G_("bad value %qs for %<-march=%> switch")
+: G_("bad value %qs for % attribute"),
 opts->x_ix86_arch_string);
 
   auto_vec  candidates;

@@ -2292,8 +2292,8 @@ ix86_option_override_internal (bool main_args_p,
   if (ix86_tune_specified && i == pta_size)
 {
   error (main_args_p
-? G_("bad value (%qs) for %<-mtune=%> switch")
-: G_("bad value (%qs) for % attribute"),
+? G_("bad value %qs for %<-mtune=%> switch")
+: G_("bad value %qs for % attribute"),
 opts->x_ix86_tune_string);
 
   auto_vec  candidates;

diff --git a/gcc/testsuite/gcc.target/i386/pr99753.c 
b/gcc/testsuite/gcc.target/i386/pr99753.c
index 3def1fd7481..1b000bd56b6 100644
--- a/gcc/testsuite/gcc.target/i386/pr99753.c
+++ b/gcc/testsuite/gcc.target/i386/pr99753.c
@@ -2,4 +2,4 @@
 
 /* { dg-do compile } */

 /* { dg-options "-march=amd -m32" } */
-/* { dg-error "bad value .'amd'. for '-march=' switch"  "" { target *-*-* } 0 
} */
+/* { dg-error "bad value 'amd' for '-march=' switch"  "" { target *-*-* } 0 } 
*/
diff --git a/gcc/testsuite/gcc.target/i386/spellcheck-options-1.c 
b/gcc/testsuite/gcc.target/i386/spellcheck-options-1.c
index 275f86c178d..a775545887e 100644
--- a/gcc/testsuite/gcc.target/i386/spellcheck-options-1.c
+++ b/gcc/testsuite/gcc.target/i386/spellcheck-options-1.c
@@ -3,5 +3,5 @@
 
 /* { dg-do compile } */

 /* { dg-options "-march=hasvel" } */
-/* { dg-error "bad value .'hasvel'. for '-march=' switch"  "" { target *-*-* } 
0 } */
+/* { dg-error "bad value 'hasvel' for '-march=' switch"  "" { target *-*-* } 0 
} */
 /* { dg-message "valid arguments to '-march=' switch are: \[^\n\r]*; did you mean 
'haswell'?"  "" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/i386/spellcheck-options-2.c 
b/gcc/testsuite/gcc.target/i386/spellcheck-options-2.c
index 848906245af..91ddfe2cad2 100644
--- a/gcc/testsuite/gcc.target/i386/spellcheck-options-2.c
+++ b/gcc/testsuite/gcc.target/i386/spellcheck-options-2.c
@@ -3,5 +3,5 @@
 
 /* { dg-do compile } */

 /* { dg-options "-mtune=hasvel" } */
-/* { dg-error "bad value .'hasvel'. for '-mtune=' switch"  "" { target *-*-* } 
0 } */
+/* { dg-error "bad value 'hasvel' for '-mtune=' switch"  "" { target *-*-* } 0 
} */
 /* { dg-message "valid arguments to '-mtune=' switch are: \[^\n\r]*; did you mean 
'haswell'?"  "" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.target/i386/spellcheck-options-4.c 
b/gcc/testsuite/gcc.target/i386/spellcheck-options-4.c
index 7eba4127513..71804a3d9b8 100644
--- a/gcc/testsuite/gcc.target/i386/spellcheck-options-4.c
+++ b/gcc/testsuite/gcc.target/i386/spellcheck-options-4.c
@@ -3,5 +3,5 @@
 
 /* { dg-do compile } */
 
-__attribute__((target ("arch=hasvel"))) void foo (void) {} /* { dg-error "bad value .'hasvel'. for 'target..arch=..' attribute" } */

+__attribute__((target ("arch=hasvel"))) void foo (void) {} /* { dg-error "bad value 
'hasvel' for 'target..arch=..' attribute" } */
 /* { dg-message "valid arguments to 'target..arch=..' attribute are: \[^\n\r]*; did you mean 
'haswell'?"  "" { target *-*-* } .-1 } */
--
2.35.1



[PATCH] v850: fix typo in pragma name

2022-03-22 Thread Martin Liška

Pushed as obvious.

Martin

  PR target/104904

gcc/ChangeLog:

* config/v850/v850-c.cc (pop_data_area): Fix typo in pragma
name.
---
 gcc/config/v850/v850-c.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/v850/v850-c.cc b/gcc/config/v850/v850-c.cc
index 45a3a0d811f..09ec540ad7c 100644
--- a/gcc/config/v850/v850-c.cc
+++ b/gcc/config/v850/v850-c.cc
@@ -64,7 +64,7 @@ static int
 pop_data_area (v850_data_area data_area)
 {
   if (data_area_stack == NULL)
-warning (OPT_Wpragmas, "%<#pragma%> GHS end found without "
+warning (OPT_Wpragmas, "%<#pragma%> GHS endXXX found without "
 "previous startXXX");
   else if (data_area != data_area_stack->data_area)
 warning (OPT_Wpragmas, "%<#pragma%> GHS endXXX does not match "
--
2.35.1



[PATCH] rs6000: wrap const in an error message.

2022-03-22 Thread Martin Liška

Pushed as obvious.

Martin

PR target/104903

gcc/ChangeLog:

* config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin):
Wrap const keyword.
---
 gcc/config/rs6000/rs6000-c.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc
index 3b62b499df2..f73b98f8051 100644
--- a/gcc/config/rs6000/rs6000-c.cc
+++ b/gcc/config/rs6000/rs6000-c.cc
@@ -1788,8 +1788,8 @@ altivec_resolve_overloaded_builtin (location_t loc, tree 
fndecl,
{
  if (TYPE_READONLY (TREE_TYPE (type))
  && !TYPE_READONLY (TREE_TYPE (decl_type)))
-   warning (0, "passing argument %d of %qE discards const qualifier "
-"from pointer target type", n + 1, fndecl);
+   warning (0, "passing argument %d of %qE discards %  "
+"qualifier from pointer target type", n + 1, fndecl);
  type = build_qualified_type (TREE_TYPE (type), 0);
  type = build_pointer_type (type);
  arg = fold_convert (type, arg);
--
2.35.1



Re: [PATCH] rs6000: wrap const in an error message.

2022-03-22 Thread Martin Liška

On 3/22/22 13:50, Martin Liška wrote:

+warning (0, "passing argument %d of %qE discards %  "


I've just installed version only with one space. Sorry for noise.

Martin


[PATCH] nvptx: fix wrapping in an error message.

2022-03-22 Thread Martin Liška

Pushed to master as obvious.

Martin

PR target/104902

gcc/ChangeLog:

* config/nvptx/nvptx.cc (handle_ptx_version_option):
Fix option wrapping in an error message.
---
 gcc/config/nvptx/nvptx.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index 3a7be63c290..f83f98c3ab5 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -300,8 +300,8 @@ handle_ptx_version_option (void)
 = first_ptx_version_supporting_sm ((enum ptx_isa) ptx_isa_option);
 
   if (ptx_version_option < first)

-error ("PTX version (-mptx) needs to be at least %s to support selected"
-  " -misa (sm_%s)", ptx_version_to_string (first),
+error ("PTX version (%<-mptx%>) needs to be at least %s to support 
selected"
+  " %<-misa%> (sm_%s)", ptx_version_to_string (first),
   sm_version_to_string ((enum ptx_isa)ptx_isa_option));
 }
 
--

2.35.1



[Patch] LTO: Fixes for renaming issues with offload/OpenMP [PR104285]

2022-03-22 Thread Tobias Burnus

This patch fixes some same-local-name issues with offloading.

The first issue can also occur with -flto with -foffload=disable (I think).
Otherwise, all three issues apply to the non-host lto1 run
(defined ACCEL_COMPILER).


First, for  omp declare link(var),  a variable is declared
based on DECL_NAME (var) by appending "$linkptr"
(→ offload_handle_link_vars) – and saved as VALUE_EXPR.

The problem is that this call happens before the static
variables are renamed in lto_promote_statics_nonwpa
or lto_promote_cross_file_statics.

Solution: Call offload_handle_link_vars right after those
static-name handlings. (Plus move offload_handle_link_vars
before the first caller.)

* * *

Secondly, maybe_rewrite_identifier: If the ACCEL_COMPILER
is more restricted than the host compiler, . (dot) or '$'
have to be replaced. Thus, this function is only active for

 #if defined ACCEL_COMPILER && (defined NO_DOT_IN_LABEL || defined 
NO_DOLLAR_IN_LABEL)

This function created a new string (xstrdup) and returned it as it.

That works kind of okay, but not for duplicated names:

   unsigned &clone_number = lto_clone_numbers->get_or_insert (name);

The underlying hash function uses the pointer address and not the
string value to return the clone_number – resulting in '0' for
xstrdup strings.

Solution: maybe_rewrite_identifier now uses IDENTIFIER_POINTER (get_identifier 
(...))
to get a unique pointer.


* * *

Last issue: When a function name was changed because of $. issues (e.g. 
'func._omp_fn.0'
to 'func$_omp_fn$0') and then the function name was changed because of 
static-name
collisions< ('func$_omp_fn$0' → 'func$_omp_fn$0$ltrans_0').

In this case, we need to go back to the original name to obtain the function 
body.
The second renaming has been properly tracked already - but the first one 
hasn't.

This patch now also tracks the first renaming + calls lto_get_decl_name_mapping 
a
second time. Instead of using

+#if defined ACCEL_COMPILER && (defined NO_DOT_IN_LABEL || defined 
NO_DOLLAR_IN_LABEL)
+  name = lto_get_decl_name_mapping (file_data, name);
+#endif

the code could have also used the call unconditionally as it returns the passed
argument when no mapping could be found. The condition mirrors the one for
maybe_rewrite_identifier.

The idea was to have an optimization + annotate the code a bit. An alternative 
would
be to remove the '#' lines, possibly replacing the first line
by '/* Handle maybe_rewrite_identifier renames. */'.


OK for current trunk (GCC12)? Alternatively, OK for GCC 13 Stage 1?


Tobias

PS: After having finished this patch for the PR, I did encounter an issue with
the omptests testsuite and linkptr (see 'first' in this email); with this patch
the omptests test case passes. But while writing a testcase for linkptr, I did
run into https://gcc.gnu.org/PR105015 (see PR or #if 0 code in one of the 
testcase
files in the attached patch).
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
LTO: Fixes for renaming issues with offload/OpenMP [PR104285]LTO: Fixes for renaming issues with offload/OpenMP [PR104285]

gcc/ChangeLog:

	PR middle-end/104285
	* cgraph.cc (cgraph_node::get_untransformed_body): Call
	lto_get_decl_name_mapping again to handle NO_DOT/NO_DOLLAR renames
	for ACCEL_COMPILER.
	* varpool.cc (varpool_node::get_constructor): Likewise.

gcc/lto/ChangeLog:

	PR middle-end/104285
	* lto-partition.cc (maybe_rewrite_identifier): Use get_identifier
	for the returned string to be usable as hash key.
	(validize_symbol_for_target): Hence, use return value directly.
	(privatize_symbol_name_1): Track maybe_rewrite_identifier renames.
	* lto.cc (offload_handle_link_vars): Move function up before ...
	(do_whole_program_analysis): Call it after static renamings.
	(lto_main): Move call after static renamings.

libgomp/ChangeLog:

	PR middle-end/104285
	* testsuite/libgomp.c++/target-same-name-2-a.C: New test.
	* testsuite/libgomp.c++/target-same-name-2-b.C: New test.
	* testsuite/libgomp.c++/target-same-name-2.C: New test.
	* testsuite/libgomp.c-c++-common/target-same-name-1-a.c: New test.
	* testsuite/libgomp.c-c++-common/target-same-name-1-b.c: New test.
	* testsuite/libgomp.c-c++-common/target-same-name-1.c: New test.

 gcc/cgraph.cc  |  3 ++
 gcc/lto/lto-partition.cc   | 18 ---
 gcc/lto/lto.cc | 58 +++--
 gcc/varpool.cc |  3 ++
 .../testsuite/libgomp.c++/target-same-name-2-a.C   | 50 ++
 .../testsuite/libgomp.c++/target-same-name-2-b.C   | 50 ++
 libgomp/testsuite/libgomp.c++/target-same-name-2.C | 24 +
 .../libgomp.c-c++-common/target-same-name-1-a.c| 60 ++
 .../libgomp.c-c++

[PATCH] tree-optimization/105012 - fix ICE from local DSE of if-conversion

2022-03-22 Thread Richard Biener via Gcc-patches
The following guards dse_classify_store with the same condition as
the DSE pass does - availability of a virtual definition.  For
the PR we run into the fortran frontend generating a clobber for
a FUNCTION_DECL lhs which is ignored by the operand scanner and has
no virtual operands assigned.  Apart from fixing the frontend the
following fixes the ICE by adjusting if-conversion.

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

2022-03-22  Richard Biener  

PR tree-optimization/105012
* tree-if-conv.cc (ifcvt_local_dce): Only call
dse_classify_store when we have a VDEF.
---
 gcc/tree-if-conv.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-if-conv.cc b/gcc/tree-if-conv.cc
index 375628e6e9e..7495ed653c0 100644
--- a/gcc/tree-if-conv.cc
+++ b/gcc/tree-if-conv.cc
@@ -3145,7 +3145,7 @@ ifcvt_local_dce (class loop *loop)
   gimple_stmt_iterator gsiprev = gsi;
   gsi_prev (&gsiprev);
   stmt = gsi_stmt (gsi);
-  if (gimple_store_p (stmt))
+  if (gimple_store_p (stmt) && gimple_vdef (stmt))
{
  tree lhs = gimple_get_lhs (stmt);
  ao_ref write;
-- 
2.34.1


[committed][nvptx] Add warp sync at simt exit

2022-03-22 Thread Tom de Vries via Gcc-patches
Hi,

Consider this code (with N defined to 1024):
...
  float v = 0.0;
  #pragma omp target map(tofrom: v)
  #pragma omp parallel for simd
  for (int i = 0 ; i < N; i++)
{
  #pragma omp atomic update
  v = v + 1.0;
}
...

It hangs when executing on target board unix/-foffload=-misa=sm_75, using
drivers 470.103.01 and 510.54 on a T400 board (sm_75).

I'm tentatively identifying the problem as a bug in -muniform-simt for
architectures that support Independent Thread Scheduling (sm_70 and later).

The problem -muniform-simt is trying to address is to make sure that a
register produced outside an openmp simd region is available when used in any
lane inside an simd region.

The solution is to, outside an simd region, execute in all warp lanes, thus
producing consistent values in result registers in each warp thread.

This approach doesn't work when executing in all warp lanes multiplies the
side effects from 1 to 32 separate side effects, which is the case for atomic
insns.  So atomic insns are rewritten to execute only in lane 0, and if
there are any results, those are propagated to the other threads in the warp.
[ And likewise for system calls malloc, free, vprintf. ]

Now, consider a non-atomic update: ld, add, store.  The store has side
effects, are those multiplied or not?

Pre-sm_70 we can assume that at the end of an SIMT region, any divergent
control flow has reconverged, and we have a uniform warp, executing in lock
step.  So:
- the load will load the same value into the result register across the warp,
- the add will write the same value into the result register across the warp,
- the store will write the same value to the same memory location, 32 times,
  at once, having the result of a single store.
So, no side-effect multiplication (well, at least that's the observation).

Starting sm_70, the threads in a warp are no longer guaranteed to reconverge
after divergence.  There's a "Convergence Optimizer" that can can identify
that it is safe for a warp to reconverge, but that works only as long as the
code does not contain "synchronizing operations".

Consequently, the ld, add, store sequence can be executed by a non-uniform
warp, which means the side effects can have multiplied, and the registers are
no longer guarantueed to be in sync.

The atomic update in the example above is translated using an atom.cas loop,
which means that we have divergence (because only one thread is allowed to
succeed at a time) and the "Convergence Optimizer" doesn't reconverge probably
because the atom.cas counts as a "synchronizing operation".  So, it seems
plausible that the root cause for the mentioned hang is the problem described
above.

Fix this by adding an explicit warp sync at simt exit.

Note that we're assuming here that the warp will stay uniform until the next
SIMT region entry.

Tested on x86_64 with nvptx accelerator.

Committed to trunk.

Thanks,
- Tom

[nvptx] Add warp sync at simt exit

gcc/ChangeLog:

2022-03-09  Tom de Vries  

PR target/104916
PR target/104783
* config/nvptx/nvptx.md (define_expand "omp_simt_exit"): Emit warp
sync (or uniform warp check for mptx < 6.0).

libgomp/ChangeLog:

2022-03-15  Tom de Vries  

PR target/104916
PR target/104783
* testsuite/libgomp.c/pr104783-2.c: New test.

---
 gcc/config/nvptx/nvptx.md|  4 
 libgomp/testsuite/libgomp.c/pr104783-2.c | 25 +
 2 files changed, 29 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 1dec7caa0d1..5550ce25513 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -1881,6 +1881,10 @@ (define_expand "omp_simt_exit"
   ""
 {
   emit_insn (gen_omp_simt_exit (Pmode, operands[0]));
+  if (TARGET_PTX_6_0)
+emit_insn (gen_nvptx_warpsync ());
+  else
+emit_insn (gen_nvptx_uniform_warp_check ());
   DONE;
 })
 
diff --git a/libgomp/testsuite/libgomp.c/pr104783-2.c 
b/libgomp/testsuite/libgomp.c/pr104783-2.c
new file mode 100644
index 000..8750d915d01
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/pr104783-2.c
@@ -0,0 +1,25 @@
+#define N (32 * 32)
+
+#define TYPE float
+#define VAR v
+#define INIT 0.0
+#define UPDATE + 1.0
+#define EXPECTED N
+
+int
+main (void)
+{
+  TYPE VAR = INIT;
+  #pragma omp target map(tofrom: VAR)
+  #pragma omp parallel for simd
+  for (int i = 0 ; i < N; i++)
+{
+  #pragma omp atomic update
+  VAR = VAR UPDATE;
+}
+
+  if (VAR != EXPECTED)
+__builtin_abort ();
+
+  return 0;
+}


[committed][nvptx] Use .alias directive for mptx >= 6.3

2022-03-22 Thread Tom de Vries via Gcc-patches
Hi,

Starting with ptx isa version 6.3, a ptx directive .alias is available.
Use this directive to support symbol aliases, as far as possible.

The alias support is off by default.  It can be turned on using a switch
-malias.

Furthermore, for pre-sm_75, it's not effective unless the ptx version is
bumped to 6.3 or higher using -mptx (given that the default for pre-sm_75 is
6.0).

The alias support has the following limitations.

Only function aliases are supported.

Weak aliases are not supported.  That is, if I disable the check in
nvptx_asm_output_def_from_decls that disallows this, a weak alias is emitted
and parsed by the driver.  But the test gcc.dg/globalalias.c starts failing,
with the behaviour matching the comment about "weird behavior of AIX's .set
pseudo-op": a weak alias may resolve to different functions in different
files.

Aliases to weak symbols are not supported (see gcc.dg/localalias.c).  This is
currently not prohibited by the compiler, but with the driver link we run
into: "error: Function test with .weak scope cannot be aliased".

Aliases to aliases are not supported (see libgomp.c-c++-common/pr96390.c).
This is currently not prohibited by the compiler, but with the driver link we
run into:  "Internal error: alias to unknown symbol" .

Unreferenced aliases are not emitted (these can occur f.i. when inlining a
call to an alias).  This avoids driver link error "Internal error: reference
to deleted section".

When enabling malias by default, libgomp detects alias support and
consequently libgomp.a will contains a few uses of .alias.  This however
results in aforementioned "Internal error: reference to deleted section" in
many test-cases.  Either there's some error with how .alias is used, or
there's a driver bug.  While this issue is not resolved, we keep malias
off-by-default.

At some point we may add support in the nvptx-tools linker for symbol
aliases, and define f.i. malias=ptx and malias=ld to choose between the two in
the compiler.

An example of where this support is useful, is the OvO (OpenMP vs Offload)
testsuite.  The testsuite passes already at -O2.  But at -O0, there are errors
in some c++ test-cases due to missing symbol alias support.  By compiling with
-malias, the whole testsuite passes also at -O0.

This patch causes a regression:
...
-PASS: gcc.dg/pr60797.c  (test for errors, line 4)
+FAIL: gcc.dg/pr60797.c  (test for errors, line 4)
...
The test-case is skipped for effective target alias, and both without and with
this patch the nvptx target is considered to not support it, so the test-case is
executed.  The test-case expects an error message along the lines of "alias
definitions not supported in this configuration", but instead we run into:
...
gcc.dg/pr60797.c:4:12: error: foo aliased to undefined symbol
...
This is probably due to the fact that the nvptx backend now defines macros
ASM_OUTPUT_DEF and ASM_OUTPUT_DEF_FROM_DECLS, so from the point of view of the
common part of the compiler, aliases are supported.

Committed to trunk.

Thanks,
- Tom

[nvptx] Use .alias directive for mptx >= 6.3

gcc/ChangeLog:

2022-03-18  Tom de Vries  

PR target/104957
* config/nvptx/nvptx-protos.h (nvptx_asm_output_def_from_decls): 
Declare.
* config/nvptx/nvptx.cc (write_fn_proto_1): Don't add function marker
for alias.
(SET_ASM_OP, NVPTX_ASM_OUTPUT_DEF): New macro def.
(nvptx_asm_output_def_from_decls): New function.
* config/nvptx/nvptx.h (ASM_OUTPUT_DEF): New macro def, define to
gcc_unreachable ().
(ASM_OUTPUT_DEF_FROM_DECLS): New macro def, define to
nvptx_asm_output_def_from_decls.
* config/nvptx/nvptx.opt (malias): New opt.

gcc/testsuite/ChangeLog:

2022-03-18  Tom de Vries  

PR target/104957
* gcc.target/nvptx/alias-1.c: New test.
* gcc.target/nvptx/alias-2.c: New test.
* gcc.target/nvptx/alias-3.c: New test.
* gcc.target/nvptx/alias-4.c: New test.
* gcc.target/nvptx/nvptx.exp
(check_effective_target_runtime_ptx_isa_version_6_3): New proc.

---
 gcc/config/nvptx/nvptx-protos.h  |  1 +
 gcc/config/nvptx/nvptx.cc| 74 +++-
 gcc/config/nvptx/nvptx.h | 17 
 gcc/config/nvptx/nvptx.opt   |  3 ++
 gcc/testsuite/gcc.target/nvptx/alias-1.c | 27 
 gcc/testsuite/gcc.target/nvptx/alias-2.c | 13 ++
 gcc/testsuite/gcc.target/nvptx/alias-3.c | 29 +
 gcc/testsuite/gcc.target/nvptx/alias-4.c | 12 ++
 gcc/testsuite/gcc.target/nvptx/nvptx.exp |  7 +++
 9 files changed, 182 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nvptx/nvptx-protos.h b/gcc/config/nvptx/nvptx-protos.h
index 0bf9af406a2..ca0a87ee4bd 100644
--- a/gcc/config/nvptx/nvptx-protos.h
+++ b/gcc/config/nvptx/nvptx-protos.h
@@ -43,6 +43,7 @@ extern void nvptx_output_ascii (FILE *, const char *, 
unsigned HOST_WIDE_INT);
 extern void nvptx_cpu_cpp_builtins (void);
 

[committed][nvptx] Add mexperimental

2022-03-22 Thread Tom de Vries via Gcc-patches
Hi,

Add new option -mexperimental.

This allows, rather than developing a new feature to completion in a
development branch, to develop a new feature on trunk, without disturbing
trunk.

The equivalent of the feature branch merge then becomes making the
functionality available for -mno-experimental.

If more features at the same time will be developed, we can do something like
-mexperimental=feature1,feature2 but for now that's not necessary.

For now, has no effect.

Committed to trunk.

Thanks,
- Tom

[nvptx] Add mexperimental

gcc/ChangeLog:

2022-03-19  Tom de Vries  

* config/nvptx/nvptx.opt (mexperimental): New option.

---
 gcc/config/nvptx/nvptx.opt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
index 980428b58cc..11288d1a8ee 100644
--- a/gcc/config/nvptx/nvptx.opt
+++ b/gcc/config/nvptx/nvptx.opt
@@ -88,3 +88,6 @@ Target Var(nvptx_comment) Init(1) Undocumented
 
 malias
 Target Var(nvptx_alias) Init(0) Undocumented
+
+mexperimental
+Target Var(nvptx_experimental) Init(0) Undocumented


[committed][nvptx] Limit HFmode support to mexperimental

2022-03-22 Thread Tom de Vries via Gcc-patches
Hi,

With PR104489 still open and end-of-stage-4 approaching, classify HFmode
support as experimental, which is not enabled by default but can be enabled
using -mexperimental.

This fixes the nvptx build when the default sm_xx is set to sm_53 or higher.

Note that we're not using -mfp16 or some such, because that might create
expectations about being able to switch support on or off in the future, and
at this point it's not clear why, once reaching non-experimental status, it
shouldn't always be enabled.

Committed to trunk.

Thanks,
- Tom

[nvptx] Limit HFmode support to mexperimental

gcc/ChangeLog:

2022-03-19  Tom de Vries  

* config/nvptx/nvptx.cc (nvptx_scalar_mode_supported_p)
(nvptx_libgcc_floating_mode_supported_p): Only enable HFmode for
mexperimental.

gcc/testsuite/ChangeLog:

2022-03-19  Tom de Vries  

* gcc.target/nvptx/float16-1.c: Add additional-options -mexperimental.
* gcc.target/nvptx/float16-2.c: Same.
* gcc.target/nvptx/float16-3.c: Same.
* gcc.target/nvptx/float16-4.c: Same.
* gcc.target/nvptx/float16-5.c: Same.
* gcc.target/nvptx/float16-6.c: Same.

---
 gcc/config/nvptx/nvptx.cc  | 4 ++--
 gcc/testsuite/gcc.target/nvptx/float16-1.c | 1 +
 gcc/testsuite/gcc.target/nvptx/float16-2.c | 1 +
 gcc/testsuite/gcc.target/nvptx/float16-3.c | 1 +
 gcc/testsuite/gcc.target/nvptx/float16-4.c | 1 +
 gcc/testsuite/gcc.target/nvptx/float16-5.c | 1 +
 gcc/testsuite/gcc.target/nvptx/float16-6.c | 1 +
 7 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index b2f7b4af392..87efc23bd96 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -7156,7 +7156,7 @@ nvptx_cannot_force_const_mem (machine_mode mode 
ATTRIBUTE_UNUSED,
 static bool
 nvptx_scalar_mode_supported_p (scalar_mode mode)
 {
-  if (mode == HFmode && TARGET_SM53)
+  if (nvptx_experimental && mode == HFmode && TARGET_SM53)
 return true;
 
   return default_scalar_mode_supported_p (mode);
@@ -7165,7 +7165,7 @@ nvptx_scalar_mode_supported_p (scalar_mode mode)
 static bool
 nvptx_libgcc_floating_mode_supported_p (scalar_float_mode mode)
 {
-  if (mode == HFmode && TARGET_SM53)
+  if (nvptx_experimental && mode == HFmode && TARGET_SM53)
 return true;
 
   return default_libgcc_floating_mode_supported_p (mode);
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-1.c 
b/gcc/testsuite/gcc.target/nvptx/float16-1.c
index 873a0543535..017774c2941 100644
--- a/gcc/testsuite/gcc.target/nvptx/float16-1.c
+++ b/gcc/testsuite/gcc.target/nvptx/float16-1.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -ffast-math -misa=sm_53 -mptx=_" } */
+/* { dg-additional-options "-mexperimental" } */
 
 _Float16 var;
 
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-2.c 
b/gcc/testsuite/gcc.target/nvptx/float16-2.c
index 30a3092bc29..e15b685253b 100644
--- a/gcc/testsuite/gcc.target/nvptx/float16-2.c
+++ b/gcc/testsuite/gcc.target/nvptx/float16-2.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -ffast-math -misa=sm_80 -mptx=_" } */
+/* { dg-additional-options "-mexperimental" } */
 
 _Float16 x;
 _Float16 y;
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-3.c 
b/gcc/testsuite/gcc.target/nvptx/float16-3.c
index edd6514a976..1c646902055 100644
--- a/gcc/testsuite/gcc.target/nvptx/float16-3.c
+++ b/gcc/testsuite/gcc.target/nvptx/float16-3.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -misa=sm_53 -mptx=_" } */
+/* { dg-additional-options "-mexperimental" } */
 
 _Float16 var;
 
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-4.c 
b/gcc/testsuite/gcc.target/nvptx/float16-4.c
index 0a823971e75..1c24ec8c3b2 100644
--- a/gcc/testsuite/gcc.target/nvptx/float16-4.c
+++ b/gcc/testsuite/gcc.target/nvptx/float16-4.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -ffast-math -misa=sm_53 -mptx=_" } */
+/* { dg-additional-options "-mexperimental" } */
 
 _Float16 var;
 
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-5.c 
b/gcc/testsuite/gcc.target/nvptx/float16-5.c
index 2261f42baac..9ae3365e1a6 100644
--- a/gcc/testsuite/gcc.target/nvptx/float16-5.c
+++ b/gcc/testsuite/gcc.target/nvptx/float16-5.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -ffast-math -misa=sm_53 -mptx=_" } */
+/* { dg-additional-options "-mexperimental" } */
 
 _Float16 a;
 _Float16 b;
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-6.c 
b/gcc/testsuite/gcc.target/nvptx/float16-6.c
index 9ca714ca76f..37c580429c5 100644
--- a/gcc/testsuite/gcc.target/nvptx/float16-6.c
+++ b/gcc/testsuite/gcc.target/nvptx/float16-6.c
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -misa=sm_53 -mptx=_" } */
+/* { dg-additional-options "-mexperimental" } */
 
 _Float16 x;
 _Float16 y;


[committed][nvptx] Use '%' as register prefix

2022-03-22 Thread Tom de Vries via Gcc-patches
Hi,

The percentage sign as first character of a ptx identifier can be used to
avoid name conflicts, e.g., between user-defined variable names and
compiler-generated names.

The insn nvptx_uniform_warp_check contains register names without '%' prefix,
which potentially could lead to name conflicts with user-defined variable
names.

Fix this by adding a '%' prefix, more specifically a '%r_' prefix to avoid a
name conflict with ptx special registers.

Tested on x86_64 with nvptx accelerator.

Committed to trunk.

Thanks,
- Tom

[nvptx] Use '%' as register prefix

gcc/ChangeLog:

2022-03-20  Tom de Vries  

PR target/104925
* config/nvptx/nvptx.md (define_insn "nvptx_uniform_warp_check"):
Use % as register prefix.

---
 gcc/config/nvptx/nvptx.md | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 5550ce25513..8ed685027b5 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -2280,13 +2280,14 @@ (define_insn "nvptx_uniform_warp_check"
   {
 const char *insns[] = {
   "{",
-  "\\t"  ".reg.b32""\\t" "act;",
-  "%.\\t""vote.ballot.b32" "\\t" "act,1;",
-  "\\t"  ".reg.pred"   "\\t" "do_abort;",
-  "\\t"  "mov.pred""\\t" "do_abort,0;",
-  "%.\\t""setp.ne.b32" "\\t" "do_abort,act,0x;",
-  "@ do_abort\\t" "trap;",
-  "@ do_abort\\t" "exit;",
+  "\\t"  ".reg.b32""\\t" "%%r_act;",
+  "%.\\t""vote.ballot.b32" "\\t" "%%r_act,1;",
+  "\\t"  ".reg.pred"   "\\t" "%%r_do_abort;",
+  "\\t"  "mov.pred""\\t" "%%r_do_abort,0;",
+  "%.\\t""setp.ne.b32" "\\t" "%%r_do_abort,%%r_act,"
+ "0x;",
+  "@ %%r_do_abort\\t" "trap;",
+  "@ %%r_do_abort\\t" "exit;",
   "}",
   NULL
 };


Re: [pushed] c++: designated init and aggregate members [PR102337]

2022-03-22 Thread Patrick Palka via Gcc-patches
On Mon, 21 Mar 2022, Jason Merrill via Gcc-patches wrote:

> Our C++20 designated initializer handling was broken with members of class
> type; we would find the relevant member and then try to find a member of
> the member with the same name.  Or we would sometimes ignore the designator
> entirely.  The former problem is fixed by the change to reshape_init_class,
> the latter by the change to reshape_init_r.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.
> 
>   PR c++/103337
>   PR c++/102740
>   PR c++/103299
>   PR c++/102538
> 
> gcc/cp/ChangeLog:
> 
>   * decl.cc (reshape_init_class): Avoid looking for designator
>   after we found it.
>   (reshape_init_r): Keep looking for designator.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/ext/flexary3.C: Remove one error.
>   * g++.dg/parse/pr43765.C: Likewise.
>   * g++.dg/cpp2a/desig22.C: New test.
>   * g++.dg/cpp2a/desig23.C: New test.
>   * g++.dg/cpp2a/desig24.C: New test.
>   * g++.dg/cpp2a/desig25.C: New test.
> ---
>  gcc/cp/decl.cc   | 47 +---
>  gcc/testsuite/g++.dg/cpp2a/desig22.C | 11 +++
>  gcc/testsuite/g++.dg/cpp2a/desig23.C | 20 
>  gcc/testsuite/g++.dg/cpp2a/desig24.C | 11 +++
>  gcc/testsuite/g++.dg/cpp2a/desig25.C | 13 
>  gcc/testsuite/g++.dg/ext/flexary3.C  |  2 +-
>  gcc/testsuite/g++.dg/parse/pr43765.C |  6 ++--
>  7 files changed, 101 insertions(+), 9 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig22.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig23.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig24.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig25.C
> 
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index 375385e0013..34d9dad9fb0 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -6598,8 +6598,9 @@ reshape_init_class (tree type, reshape_iter *d, bool 
> first_initializer_p,
>  {
>tree field_init;
>constructor_elt *old_cur = d->cur;
> +  bool direct_desig = false;
>  
> -  /* Handle designated initializers, as an extension.  */
> +  /* Handle C++20 designated initializers.  */
>if (d->cur->index)
>   {
> if (d->cur->index == error_mark_node)
> @@ -6617,7 +6618,10 @@ reshape_init_class (tree type, reshape_iter *d, bool 
> first_initializer_p,
>   }
>   }
> else if (TREE_CODE (d->cur->index) == IDENTIFIER_NODE)
> - field = get_class_binding (type, d->cur->index);
> + {
> +   field = get_class_binding (type, d->cur->index);
> +   direct_desig = true;
> + }
> else
>   {
> if (complain & tf_error)
> @@ -6669,6 +6673,7 @@ reshape_init_class (tree type, reshape_iter *d, bool 
> first_initializer_p,
> break;
> gcc_assert (aafield);
> field = aafield;
> +   direct_desig = false;
>   }
>   }
>  
> @@ -6683,9 +6688,32 @@ reshape_init_class (tree type, reshape_iter *d, bool 
> first_initializer_p,
>  assumed to correspond to no elements of the initializer list.  */
>   goto continue_;
>  
> -  field_init = reshape_init_r (TREE_TYPE (field), d,
> -/*first_initializer_p=*/NULL_TREE,
> -complain);
> +  if (direct_desig)
> + {
> +   /* The designated field F is initialized from this one element:
> +  Temporarily clear the designator so a recursive reshape_init_class
> +  doesn't try to find it again in F, and adjust d->end so we don't
> +  try to use the next initializer to initialize another member of F.
> +
> +  Note that we don't want these changes if we found the designator
> +  inside an anon aggr above; we leave them alone to implement:
> +
> +  "If the element is an anonymous union member and the initializer
> +  list is a brace-enclosed designated- initializer-list, the element
> +  is initialized by the designated-initializer-list { D }, where D
> +  is the designated- initializer-clause naming a member of the
> +  anonymous union member."  */
> +   auto end_ = make_temp_override (d->end, d->cur + 1);
> +   auto idx_ = make_temp_override (d->cur->index, NULL_TREE);

IIUC this override of d->cur->index mutates the underlying CONSTRUCTOR, which
is probably fine, but I wonder if it'd be worthwhile to avoid the mutation by
using a temporary reshape_iter for the recursive call, something like:

  constructor_elt elt = { /*index=*/NULL_TREE, d->cur->value };
  reshape_iter iter = { &elt, &elt + 1 };
  field_init = reshape_init_r (TREE_TYPE (field), &iter,
   /*first_initializer_p=*/NULL_TREE,
   complain);
  d->cur++;

> +   field_init = reshape_init_r (TREE_TYPE (field), d,
> +/*first_initial

Re: [PATCH]rs6000: avoid peeking eof after __vector keyword

2022-03-22 Thread Segher Boessenkool
Hi!

On Tue, Mar 22, 2022 at 01:50:39PM +0800, Jiufu Guo wrote:
> Segher Boessenkool  writes:
> > On Mon, Mar 21, 2022 at 02:14:08PM -0400, David Edelsohn wrote:
> >> On Mon, Mar 21, 2022 at 5:13 AM Jiufu Guo  wrote:
> >> > There is a rare corner case: where __vector is followed only with ";"
> >> > and near the end of the file.
> >
> >> This is okay. Maybe a tweak to the comment, see below.
> >
> > This whole function could use some restructuring / rewriting to make
> > clearer what it actually does.  See the function comment:
> >
> > /* Called to decide whether a conditional macro should be expanded.
> >Since we have exactly one such macro (i.e, 'vector'), we do not
> >need to examine the 'tok' parameter.  */
> >
> > ... followed by 17 uses of "tok".  Yes, some of those overwrite the
> > function argument, but that doesn't make it any better!  :-P
> >
> > Some factoring would help, too, perhaps.
> 
> Thanks for your review!
> 
> I am also confused about it when I check this function for the first
> time. In the function, 'tok' is used directly at the beginning, and
> then it is overwritten by cpp_peek_token.
> >From the history of this function, the first version of this function
> contains this 'inconsistency' between comments and implementations. :-P
> 
> With check related code, it seems this function is used to predicate
> if a conditional macro should be expanded by peeking two or more
> tokens.

Yes, and the function comment should say that, that's what it's for :-)

> The context-sensitive macros are vector/bool/pixel.  Correponding
> keywords __vector/__bool/__pixel are unconditional.
> Based on those related codes, the behavior of function
> rs6000_macro_to_expand would be checking if the 'vector' token is
> followed by bool/__bool or pixel/__pixel.  To do this the 'tok' has to
> be 'examined'.
> 
> >From this understanding, we may just update the comment.
> While the patch does not cover this.

Yes, and it doesn't have to, probably it's best not to change the code
much in stage 4 anyway.  It is really hard to fix bugs in it, or to
review the resulting patches, without documentation what it is supposed
to do (especially if the code isn't clear, is inconsistent, and even
contradicts the little documentation that there is).

Oh well.


Segher


Re: [Patch] LTO: Fixes for renaming issues with offload/OpenMP [PR104285]

2022-03-22 Thread Jakub Jelinek via Gcc-patches
On Tue, Mar 22, 2022 at 01:56:27PM +0100, Tobias Burnus wrote:
> --- a/gcc/cgraph.cc
> +++ b/gcc/cgraph.cc
> @@ -3980,6 +3980,9 @@ cgraph_node::get_untransformed_body ()
>  
>/* We may have renamed the declaration, e.g., a static function.  */
>name = lto_get_decl_name_mapping (file_data, name);
> +#if defined ACCEL_COMPILER && (defined NO_DOT_IN_LABEL || defined 
> NO_DOLLAR_IN_LABEL)
> +  name = lto_get_decl_name_mapping (file_data, name);
> +#endif

This looks weird.  IMHO we should make sure that the hash table contains
always the final names, so that we don't need to call it twice or even more
times.

> --- a/gcc/lto/lto.cc
> +++ b/gcc/lto/lto.cc
> @@ -424,6 +424,32 @@ lto_wpa_write_files (void)
>timevar_pop (TV_WHOPR_WPA_IO);
>  }
>  
> +/* Create artificial pointers for "omp declare target link" vars.  */
> +
> +static void
> +offload_handle_link_vars (void)
> +{
> +#ifdef ACCEL_COMPILER
> +  varpool_node *var;
> +  FOR_EACH_VARIABLE (var)
> +if (lookup_attribute ("omp declare target link",
> +   DECL_ATTRIBUTES (var->decl)))
> +  {
> + tree type = build_pointer_type (TREE_TYPE (var->decl));
> + tree link_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> + clone_function_name (var->decl,
> +  "linkptr"), type);
> + TREE_USED (link_ptr_var) = 1;
> + TREE_STATIC (link_ptr_var) = 1;
> + TREE_PUBLIC (link_ptr_var) = TREE_PUBLIC (var->decl);
> + DECL_ARTIFICIAL (link_ptr_var) = 1;
> + SET_DECL_ASSEMBLER_NAME (link_ptr_var, DECL_NAME (link_ptr_var));
> + SET_DECL_VALUE_EXPR (var->decl, build_simple_mem_ref (link_ptr_var));
> + DECL_HAS_VALUE_EXPR_P (var->decl) = 1;
> +  }
> +#endif
> +}
> +
>  /* Perform whole program analysis (WPA) on the callgraph and write out the
> optimization plan.  */
>  
> @@ -516,6 +542,7 @@ do_whole_program_analysis (void)
>   to globals with hidden visibility because they are accessed from 
> multiple
>   partitions.  */
>lto_promote_cross_file_statics ();
> +  offload_handle_link_vars ();
>if (dump_file)
>   dump_end (partition_dump_id, dump_file);
>dump_file = NULL;
> @@ -549,32 +576,6 @@ do_whole_program_analysis (void)
>  dump_memory_report ("Final");
>  }
>  
> -/* Create artificial pointers for "omp declare target link" vars.  */
> -
> -static void
> -offload_handle_link_vars (void)
> -{
> -#ifdef ACCEL_COMPILER
> -  varpool_node *var;
> -  FOR_EACH_VARIABLE (var)
> -if (lookup_attribute ("omp declare target link",
> -   DECL_ATTRIBUTES (var->decl)))
> -  {
> - tree type = build_pointer_type (TREE_TYPE (var->decl));
> - tree link_ptr_var = build_decl (UNKNOWN_LOCATION, VAR_DECL,
> - clone_function_name (var->decl,
> -  "linkptr"), type);
> - TREE_USED (link_ptr_var) = 1;
> - TREE_STATIC (link_ptr_var) = 1;
> - TREE_PUBLIC (link_ptr_var) = TREE_PUBLIC (var->decl);
> - DECL_ARTIFICIAL (link_ptr_var) = 1;
> - SET_DECL_ASSEMBLER_NAME (link_ptr_var, DECL_NAME (link_ptr_var));
> - SET_DECL_VALUE_EXPR (var->decl, build_simple_mem_ref (link_ptr_var));
> - DECL_HAS_VALUE_EXPR_P (var->decl) = 1;
> -  }
> -#endif
> -}
> -
>  unsigned int
>  lto_option_lang_mask (void)
>  {
> @@ -641,7 +642,10 @@ lto_main (void)
>  
> materialize_cgraph ();
> if (!flag_ltrans)
> - lto_promote_statics_nonwpa ();
> + {
> +   lto_promote_statics_nonwpa ();
> +   offload_handle_link_vars ();
> + }
>  
> /* Annotate the CU DIE and mark the early debug phase as finished.  */
> debuginfo_early_start ();

The lto.cc changes LGTM.  The rest I'm unfortunately not too familiar with,
Richi or Honza, could you please have a look?

> --- a/gcc/varpool.cc
> +++ b/gcc/varpool.cc
> @@ -294,6 +294,9 @@ varpool_node::get_constructor (void)
>  
>/* We may have renamed the declaration, e.g., a static function.  */
>name = lto_get_decl_name_mapping (file_data, name);
> +#if defined ACCEL_COMPILER && (defined NO_DOT_IN_LABEL || defined 
> NO_DOLLAR_IN_LABEL)
> +  name = lto_get_decl_name_mapping (file_data, name);
> +#endif
>struct lto_in_decl_state *decl_state
>= lto_get_function_in_decl_state (file_data, decl);

This is the same thing again as above, right?

Jakub



Re: [PATCH v3] x86: Disable SSE in ISA2 for -mgeneral-regs-only

2022-03-22 Thread H.J. Lu via Gcc-patches
On Mon, Mar 21, 2022 at 2:59 PM Uros Bizjak  wrote:
>
> On Mon, Mar 21, 2022 at 10:57 PM H.J. Lu  wrote:
> >
> > On Mon, Mar 21, 2022 at 10:50:11PM +0100, Uros Bizjak wrote:
> > > On Mon, Mar 21, 2022 at 10:47 PM H.J. Lu  wrote:
> > > >
> > > > On Mon, Mar 21, 2022 at 10:23:59PM +0100, Uros Bizjak wrote:
> > > > > On Mon, Mar 21, 2022 at 10:10 PM H.J. Lu  wrote:
> > > > > >
> > > > > > SSE and AVX ISAs in ISA2 should be disabled for -mgeneral-regs-only.
> > > > > >
> > > > > > gcc/
> > > > > >
> > > > > > PR target/105000
> > > > > > * common/config/i386/i386-common.cc
> > > > > > (OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET): Also disable SSE
> > > > > > and AVX.
> > > > > >
> > > > > > gcc/testsuite/
> > > > > >
> > > > > > PR target/105000
> > > > > > * gcc.target/i386/pr105000-1.c: New test.
> > > > > > * gcc.target/i386/pr105000-2.c: Likewise.
> > > > > > * gcc.target/i386/pr105000-3.c: Likewise.
> > > > > > ---
> > > > > >  gcc/common/config/i386/i386-common.cc  |  4 +++-
> > > > > >  gcc/testsuite/gcc.target/i386/pr105000-1.c | 11 +++
> > > > > >  gcc/testsuite/gcc.target/i386/pr105000-2.c | 11 +++
> > > > > >  gcc/testsuite/gcc.target/i386/pr105000-3.c | 11 +++
> > > > > >  4 files changed, 36 insertions(+), 1 deletion(-)
> > > > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr105000-1.c
> > > > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr105000-2.c
> > > > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr105000-3.c
> > > > > >
> > > > > > diff --git a/gcc/common/config/i386/i386-common.cc 
> > > > > > b/gcc/common/config/i386/i386-common.cc
> > > > > > index 449df6351c9..b77d495e9a4 100644
> > > > > > --- a/gcc/common/config/i386/i386-common.cc
> > > > > > +++ b/gcc/common/config/i386/i386-common.cc
> > > > > > @@ -321,7 +321,9 @@ along with GCC; see the file COPYING3.  If not 
> > > > > > see
> > > > > > | OPTION_MASK_ISA2_AVX512VP2INTERSECT_UNSET \
> > > > > > | OPTION_MASK_ISA2_AVX512FP16_UNSET)
> > > > > >  #define OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET \
> > > > > > -  (OPTION_MASK_ISA2_AVX512F_UNSET)
> > > > > > +  (OPTION_MASK_ISA2_SSE_UNSET \
> > > > > > +   | OPTION_MASK_ISA2_AVX_UNSET \
> > > > > > +   | OPTION_MASK_ISA2_AVX512F_UNSET)
> > > > >
> > > > > The above should only need OPTION_MASK_ISA2_SSE_UNSET, other options
> > > > > follow from #define chain.
> > > > >
> > > >
> > > > Here is the v2 patch to use OPTION_MASK_ISA2_SSE_UNSET.  OK for
> > > > master and GCC 11 branches?
> > >
> > > Have you regressiont tested it?
> >
> > I tested with the original patch.   Since OPTION_MASK_ISA2_SSE_UNSET
> > is the same as
> >
> > (OPTION_MASK_ISA2_SSE_UNSET
> >  | OPTION_MASK_ISA2_AVX_UNSET
> >  | OPTION_MASK_ISA2_AVX512F_UNSET)
> >
> > there should be no difference.
>
> I hope so.
>
> OK.

I am backpoting this to GCC 11.

> Thanks,
> Uros.
>
> >
> > >
> > > > Thanks.
> > > >
> > > >
> > > > H.J.
> > > > ---
> > > > Replace OPTION_MASK_ISA2_AVX512F_UNSET with OPTION_MASK_ISA2_SSE_UNSET
> > > > in OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET to disable SSE, AVX and
> > > > AVX512 ISAs.
> > > >
> > > > gcc/
> > > >
> > > > PR target/105000
> > > > * common/config/i386/i386-common.cc
> > > > (OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET): Replace
> > > > OPTION_MASK_ISA2_AVX512F_UNSET with OPTION_MASK_ISA2_SSE_UNSET.
> > > >
> > > > gcc/testsuite/
> > > >
> > > > PR target/105000
> > > > * gcc.target/i386/pr105000-1.c: New test.
> > > > * gcc.target/i386/pr105000-2.c: Likewise.
> > > > * gcc.target/i386/pr105000-3.c: Likewise.
> > > > * gcc.target/i386/pr105000-4.c: Likewise.
> > > > ---
> > > >  gcc/common/config/i386/i386-common.cc  |  2 +-
> > > >  gcc/testsuite/gcc.target/i386/pr105000-1.c | 11 +++
> > > >  gcc/testsuite/gcc.target/i386/pr105000-2.c | 11 +++
> > > >  gcc/testsuite/gcc.target/i386/pr105000-3.c | 11 +++
> > > >  gcc/testsuite/gcc.target/i386/pr105000-4.c | 11 +++
> > > >  5 files changed, 45 insertions(+), 1 deletion(-)
> > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr105000-1.c
> > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr105000-2.c
> > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr105000-3.c
> > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr105000-4.c
> > > >
> > > > diff --git a/gcc/common/config/i386/i386-common.cc 
> > > > b/gcc/common/config/i386/i386-common.cc
> > > > index 449df6351c9..c64d7b01126 100644
> > > > --- a/gcc/common/config/i386/i386-common.cc
> > > > +++ b/gcc/common/config/i386/i386-common.cc
> > > > @@ -321,7 +321,7 @@ along with GCC; see the file COPYING3.  If not see
> > > > | OPTION_MASK_ISA2_AVX512VP2INTERSECT_UNSET \
> > > > | OPTION_MASK_ISA2_AVX512FP16_UNSET)
> > > >  #define OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET \
> > > > -  (OPTION_MASK_ISA2_AVX512F_UNSET)
> > > > 

Re: [PATCH v2] x86: Also check _SOFT_FLOAT in

2022-03-22 Thread H.J. Lu via Gcc-patches
On Thu, Mar 17, 2022 at 8:05 AM H.J. Lu  wrote:
>
> On Mon, Mar 14, 2022 at 7:31 AM H.J. Lu  wrote:
> >
> > Push target("general-regs-only") in  if x87 is enabled.
> >
> > gcc/
> >
> > PR target/104890
> > * config/i386/x86gprintrin.h: Also check _SOFT_FLOAT before
> > pushing target("general-regs-only").
> >
> > gcc/testsuite/
> >
> > PR target/104890
> > * gcc.target/i386/pr104890.c: New test.
> > ---
> >  gcc/config/i386/x86gprintrin.h   |  2 +-
> >  gcc/testsuite/gcc.target/i386/pr104890.c | 11 +++
> >  2 files changed, 12 insertions(+), 1 deletion(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr104890.c
> >
> > diff --git a/gcc/config/i386/x86gprintrin.h b/gcc/config/i386/x86gprintrin.h
> > index 017ec299793..e0be01d5e78 100644
> > --- a/gcc/config/i386/x86gprintrin.h
> > +++ b/gcc/config/i386/x86gprintrin.h
> > @@ -24,7 +24,7 @@
> >  #ifndef _X86GPRINTRIN_H_INCLUDED
> >  #define _X86GPRINTRIN_H_INCLUDED
> >
> > -#if defined __MMX__ || defined __SSE__
> > +#if !defined _SOFT_FLOAT || defined __MMX__ || defined __SSE__
> >  #pragma GCC push_options
> >  #pragma GCC target("general-regs-only")
> >  #define __DISABLE_GENERAL_REGS_ONLY__
> > diff --git a/gcc/testsuite/gcc.target/i386/pr104890.c 
> > b/gcc/testsuite/gcc.target/i386/pr104890.c
> > new file mode 100644
> > index 000..cb430eef688
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr104890.c
> > @@ -0,0 +1,11 @@
> > +/* { dg-do compile { target ia32 } } */
> > +/* { dg-options "-O2 -mshstk -march=i686" } */
> > +
> > +#include 
> > +
> > +__attribute__((target ("general-regs-only")))
> > +int
> > +foo ()
> > +{
> > +  return _get_ssp ();
> > +}
> > --
> > 2.35.1
> >
>
> OK to backport to GCC 11?
>

I am backporting this to GCC 11.

-- 
H.J.


[PATCH] arm: Revert Auto-vectorization for MVE: add pack/unpack patterns PR target/104882

2022-03-22 Thread Christophe Lyon via Gcc-patches
This reverts commit r12-1434-g046a3beb1673bf to fix PR target/104882.

As discussed in the PR, it turns out that the MVE ISA has no natural
mapping with GCC's vec_pack_trunc / vec_unpack standard patterns, unlike
Neon or SVE for instance.

This patch also adds the executable testcase provided in the PR.
This test passes at -O3 because the generated code does not need
to use the pack/unpack patterns, hence the use of -O2 which now
triggers vectorization since a few months ago.

2022-03-18  Christophe Lyon  

PR target/104882
Revert
2021-06-11  Christophe Lyon  

gcc/
* config/arm/mve.md (mve_vec_unpack_lo_): Delete.
(mve_vec_unpack_hi_): Delete.
(@mve_vec_pack_trunc_lo_): Delete.
(mve_vmovntq_): Remove '@' prefix.
* config/arm/neon.md (vec_unpack_hi_): Move back
from vec-common.md.
(vec_unpack_lo_): Likewise.
(vec_pack_trunc_): Rename from
neon_quad_vec_pack_trunc_.
* config/arm/vec-common.md (vec_unpack_hi_): Delete.
(vec_unpack_lo_): Delete.
(vec_pack_trunc_): Delete.

PR target/104882
gcc/testsuite/
* gcc.target/arm/simd/mve-vclz.c: Update expected results.
* gcc.target/arm/simd/mve-vshl.c: Likewise.
* gcc.target/arm/simd/mve-vec-pack.c: Delete.
* gcc.target/arm/simd/mve-vec-unpack.c: Delete.
* gcc.target/arm/simd/pr104882.c: New test.
---
 gcc/config/arm/mve.md | 35 +
 gcc/config/arm/neon.md| 39 +-
 gcc/config/arm/vec-common.md  | 71 ---
 gcc/testsuite/gcc.target/arm/simd/mve-vclz.c  |  7 +-
 .../gcc.target/arm/simd/mve-vec-pack.c| 26 ---
 .../gcc.target/arm/simd/mve-vec-unpack.c  | 29 
 gcc/testsuite/gcc.target/arm/simd/mve-vshl.c  |  5 +-
 gcc/testsuite/gcc.target/arm/simd/pr104882.c  | 16 +
 8 files changed, 59 insertions(+), 169 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vec-pack.c
 delete mode 100644 gcc/testsuite/gcc.target/arm/simd/mve-vec-unpack.c
 create mode 100644 gcc/testsuite/gcc.target/arm/simd/pr104882.c

diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 908bedc9254..369d7a79f6c 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -535,26 +535,6 @@ (define_insn "mve_vmovlbq_"
   [(set_attr "type" "mve_move")
 ])
 
-(define_insn "mve_vec_unpack_lo_"
-  [(set (match_operand: 0 "register_operand" "=w")
-   (SE: (vec_select:
- (match_operand:MVE_3 1 "register_operand" "w")
- (match_operand:MVE_3 2 "vect_par_constant_low" ""]
-  "TARGET_HAVE_MVE"
-  "vmovlb.%# %q0, %q1"
-  [(set_attr "type" "mve_move")]
-)
-
-(define_insn "mve_vec_unpack_hi_"
-  [(set (match_operand: 0 "register_operand" "=w")
-   (SE: (vec_select:
- (match_operand:MVE_3 1 "register_operand" "w")
- (match_operand:MVE_3 2 "vect_par_constant_high" 
""]
-  "TARGET_HAVE_MVE"
-  "vmovlt.%# %q0, %q1"
-  [(set_attr "type" "mve_move")]
-)
-
 ;;
 ;; [vcvtpq_s, vcvtpq_u])
 ;;
@@ -2219,23 +2199,10 @@ (define_insn "mve_vmovnbq_"
   [(set_attr "type" "mve_move")
 ])
 
-;; vmovnb pattern used by the vec_pack_trunc expander to avoid the
-;; need for an uninitialized input operand.
-(define_insn "@mve_vec_pack_trunc_lo_"
-  [
-   (set (match_operand: 0 "s_register_operand" "=w")
-   (unspec: [(match_operand:MVE_5 1 "s_register_operand" 
"w")]
-VMOVNBQ_S))
-  ]
-  "TARGET_HAVE_MVE"
-  "vmovnb.i%#   %q0, %q1"
-  [(set_attr "type" "mve_move")
-])
-
 ;;
 ;; [vmovntq_s, vmovntq_u])
 ;;
-(define_insn "@mve_vmovntq_"
+(define_insn "mve_vmovntq_"
   [
(set (match_operand: 0 "s_register_operand" "=w")
(unspec: [(match_operand: 1 
"s_register_operand" "0")
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index f270ded4978..275bcc1435e 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -6005,6 +6005,43 @@ (define_insn "neon_vec_unpack_hi_"
   [(set_attr "type" "neon_shift_imm_long")]
 )
 
+(define_expand "vec_unpack_hi_"
+  [(match_operand: 0 "register_operand")
+   (SE: (match_operand:VU 1 "register_operand"))]
+ "TARGET_NEON && !BYTES_BIG_ENDIAN"
+  {
+   rtvec v = rtvec_alloc (/2)  ;
+   rtx t1;
+   int i;
+   for (i = 0; i < (/2); i++)
+ RTVEC_ELT (v, i) = GEN_INT ((/2) + i);
+  
+   t1 = gen_rtx_PARALLEL (mode, v);
+   emit_insn (gen_neon_vec_unpack_hi_ (operands[0], 
+ operands[1], 
+t1));
+   DONE;
+  }
+)
+
+(define_expand "vec_unpack_lo_"
+  [(match_operand: 0 "register_operand")
+   (SE: (match_operand:VU 1 "register_operand"))]
+ "TARGET_NEON && !BYTES_BIG_ENDIAN"
+  {
+   rtvec v = rtvec_alloc (/2)  ;
+   rtx t1;
+   int i;
+   for (i = 0; i < (/2) ; i++)
+ RTVEC_ELT (v, i) = GEN_INT (i);
+   t1 = gen_rtx_PARALLEL (m

[committed] testsuite: Add testcase for already fixed PR [PR102489]

2022-03-22 Thread Jakub Jelinek via Gcc-patches
Hi!

This got broken with r12-3529 and fixed with r12-5255.

Tested on x86_64-linux, committed to trunk as obvious.

2022-03-22  Jakub Jelinek  

PR c++/102489
* g++.dg/coroutines/pr102489.C: New test.

--- gcc/testsuite/g++.dg/coroutines/pr102489.C.jj   2022-03-22 
15:34:00.372804315 +0100
+++ gcc/testsuite/g++.dg/coroutines/pr102489.C  2022-03-22 15:35:06.205900644 
+0100
@@ -0,0 +1,16 @@
+// PR c++/102489
+// { dg-do compile }
+// { dg-additional-options "-O" }
+
+#include 
+
+struct footask {
+  struct promise_type {
+std::suspend_never initial_suspend();
+std::suspend_never final_suspend() noexcept;
+void unhandled_exception();
+void get_return_object();
+  };
+  std::suspend_always foo;
+  footask taskfun() { co_await foo; }
+};

Jakub



Re: [PATCH] rs6000: wrap const in an error message.

2022-03-22 Thread Segher Boessenkool
On Tue, Mar 22, 2022 at 01:50:09PM +0100, Martin Liška wrote:
> Pushed as obvious.

> - warning (0, "passing argument %d of %qE discards const qualifier 
> "
> -  "from pointer target type", n + 1, fndecl);
> + warning (0, "passing argument %d of %qE discards %  "
> +  "qualifier from pointer target type", n + 1, fndecl);

Please use %qs instead?


Segher


Re: [PATCH] rs6000: update error message format.

2022-03-22 Thread Segher Boessenkool
On Tue, Mar 22, 2022 at 01:39:12PM +0100, Martin Liška wrote:
> Pushed to master as obvious.

An obvious what?  It is not an improvement, just a change.

> -   error ("unknown vectorization library ABI type (%qs) for "
> +   error ("unknown vectorization library ABI type %qs for "
>"%qs switch", rs6000_veclibabi_name, "-mveclibabi=");

Can you make it print -mveclibabi=something instead?  With some
wordsmithing of course...  "unknown vectorization library type in
-mveclibabi=blubber" or something?


Segher


[PATCH] libstdc++-v3 testsuite: Call fesetround(FE_DOWNWARD) only if defined

2022-03-22 Thread Hans-Peter Nilsson via Gcc-patches
Ok to commit?

- 8< -

Without this, for a typical soft-float target such as cris-elf, after
commit r12-7676-g5a4e208022e704 you'll see, in libstdc++.log:
...
FAIL: 20_util/from_chars/6.cc (test for excess errors)
Excess errors:
/home/hp/tmp/auto0321/gcc/libstdc++-v3/testsuite/20_util/from_chars/6.cc:33: 
error: 'FE_DOWNWARD' was not declared in this scope

UNRESOLVED: 20_util/from_chars/6.cc compilation failed to produce executable
...

It appears to be a side-effect of that commit changing the
way __cpp_lib_to_chars is defined.  (On the bright side,
./7.cc now passes since that commit.)

TFM, specifically fenv(3), says that "Each of the macros
FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW,
FE_UNDERFLOW is defined when the implementation supports
handling of the corresponding exception".

A git-grep shows that this was the only place using a FE_ macro
unconditionally.

libstdc++-v3:
* testsuite/20_util/from_chars/6.cc (test01) [FE_DOWNWARD]:
Conditionalize call to fesetround.

diff --git a/libstdc++-v3/testsuite/20_util/from_chars/6.cc 
b/libstdc++-v3/testsuite/20_util/from_chars/6.cc
index d33484cebfee..fff3450b56c9 100644
--- a/libstdc++-v3/testsuite/20_util/from_chars/6.cc
+++ b/libstdc++-v3/testsuite/20_util/from_chars/6.cc
@@ -30,7 +30,9 @@ test01()
 #if __cpp_lib_to_chars >= 201611L
 #if _GLIBCXX_USE_C99_FENV_TR1
   double d;
+#ifdef FE_DOWNWARD
   std::fesetround(FE_DOWNWARD);
+#endif
   const std::string s = "0.099";
   auto res = std::from_chars(s.data(), s.data() + s.length(), d);
   VERIFY( res.ec == std::errc{} );
-- 
2.30.2



Re: [Patch] LTO: Fixes for renaming issues with offload/OpenMP [PR104285]

2022-03-22 Thread Tobias Burnus

Hi Jakub, hi Richi,

On 22.03.22 15:27, Jakub Jelinek wrote:

On Tue, Mar 22, 2022 at 01:56:27PM +0100, Tobias Burnus wrote:

name = lto_get_decl_name_mapping (file_data, name);
[...]
+  name = lto_get_decl_name_mapping (file_data, name);

This looks weird.  IMHO we should make sure that the hash table contains
always the final names, so that we don't need to call it twice or even more
times.


I concur – and I have changed it (see attached patch). And it still passes the 
testsuite.

(It came about because I started reverse – and in 
'cgraph_node::get_untransformed_body',
it happened that the second map was already present + I added the second lookup.
Extending the tests, I found that I also had to change privatize_symbol_name_1. 
Thus,
I added the additional mapping there.  However, it seems to be enough to only 
change
privatize_symbol_name_1 to track the double renaming in one step.
That's what the updated patch does (+ unchanged changes for linkptr + the 
hash-key part).


The lto.cc changes LGTM.  The rest I'm unfortunately not too familiar with,
Richi or Honza, could you please have a look?


(^ to be done by Honza or Richi)


This is the same thing again as above, right?


Yes. (Now also removed.)

Thanks for the first review and for nagging about the rename tracking.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
LTO: Fixes for renaming issues with offload/OpenMP [PR104285]LTO: Fixes for renaming issues with offload/OpenMP [PR104285]

gcc/lto/ChangeLog:

	PR middle-end/104285
	* lto-partition.cc (maybe_rewrite_identifier): Use get_identifier
	for the returned string to be usable as hash key.
	(validize_symbol_for_target): Hence, use return value directly.
	(privatize_symbol_name_1): Track maybe_rewrite_identifier renames.
	* lto.cc (offload_handle_link_vars): Move function up before ...
	(do_whole_program_analysis): Call it after static renamings.
	(lto_main): Move call after static renamings.

libgomp/ChangeLog:

	PR middle-end/104285
	* testsuite/libgomp.c++/target-same-name-2-a.C: New test.
	* testsuite/libgomp.c++/target-same-name-2-b.C: New test.
	* testsuite/libgomp.c++/target-same-name-2.C: New test.
	* testsuite/libgomp.c-c++-common/target-same-name-1-a.c: New test.
	* testsuite/libgomp.c-c++-common/target-same-name-1-b.c: New test.
	* testsuite/libgomp.c-c++-common/target-same-name-1.c: New test.

 gcc/lto/lto-partition.cc   | 17 +++---
 gcc/lto/lto.cc | 58 +++--
 .../testsuite/libgomp.c++/target-same-name-2-a.C   | 50 ++
 .../testsuite/libgomp.c++/target-same-name-2-b.C   | 50 ++
 libgomp/testsuite/libgomp.c++/target-same-name-2.C | 24 +
 .../libgomp.c-c++-common/target-same-name-1-a.c| 60 ++
 .../libgomp.c-c++-common/target-same-name-1-b.c| 60 ++
 .../libgomp.c-c++-common/target-same-name-1.c  | 46 +
 8 files changed, 331 insertions(+), 34 deletions(-)

diff --git a/gcc/lto/lto-partition.cc b/gcc/lto/lto-partition.cc
index 062fd033ecb..ebb9c3abe12 100644
--- a/gcc/lto/lto-partition.cc
+++ b/gcc/lto/lto-partition.cc
@@ -898,6 +898,11 @@ maybe_rewrite_identifier (const char *ptr)
 	}
   copy[off] = valid;
 }
+  if (copy)
+{
+  match = IDENTIFIER_POINTER (get_identifier (copy));
+  free (copy);
+}
   return match;
 #else
   return ptr;
@@ -921,9 +926,7 @@ validize_symbol_for_target (symtab_node *node)
 {
   symtab->change_decl_assembler_name (decl, get_identifier (name2));
   if (node->lto_file_data)
-	lto_record_renamed_decl (node->lto_file_data, name,
- IDENTIFIER_POINTER
- (DECL_ASSEMBLER_NAME (decl)));
+	lto_record_renamed_decl (node->lto_file_data, name, name2);
 }
 }
 
@@ -936,12 +939,12 @@ static hash_map *lto_clone_numbers;
 static bool
 privatize_symbol_name_1 (symtab_node *node, tree decl)
 {
-  const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
+  const char *name0 = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl));
 
-  if (must_not_rename (node, name))
+  if (must_not_rename (node, name0))
 return false;
 
-  name = maybe_rewrite_identifier (name);
+  const char *name = maybe_rewrite_identifier (name0);
   unsigned &clone_number = lto_clone_numbers->get_or_insert (name);
   symtab->change_decl_assembler_name (decl,
   clone_function_name (
@@ -949,7 +952,7 @@ privatize_symbol_name_1 (symtab_node *node, tree decl)
   clone_number++;
 
   if (node->lto_file_data)
-lto_record_renamed_decl (node->lto_file_data, name,
+lto_record_renamed_decl (node->lto_file_data, name0,
 			 IDENTIFIER_POINTER
 			 (DECL_ASSEMBLER_NAME (decl)));
 
diff --git a/gcc/lto/lto.cc b/gcc/lto/lto.cc
index 98c3

Re: [PATCH] libstdc++-v3 testsuite: Call fesetround(FE_DOWNWARD) only if defined

2022-03-22 Thread Jonathan Wakely via Gcc-patches
On Tue, 22 Mar 2022 at 15:48, Hans-Peter Nilsson via Libstdc++
 wrote:
>
> Ok to commit?

OK, thanks.


>
> - 8< -
>
> Without this, for a typical soft-float target such as cris-elf, after
> commit r12-7676-g5a4e208022e704 you'll see, in libstdc++.log:
> ...
> FAIL: 20_util/from_chars/6.cc (test for excess errors)
> Excess errors:
> /home/hp/tmp/auto0321/gcc/libstdc++-v3/testsuite/20_util/from_chars/6.cc:33: 
> error: 'FE_DOWNWARD' was not declared in this scope
>
> UNRESOLVED: 20_util/from_chars/6.cc compilation failed to produce executable
> ...
>
> It appears to be a side-effect of that commit changing the
> way __cpp_lib_to_chars is defined.  (On the bright side,
> ./7.cc now passes since that commit.)
>
> TFM, specifically fenv(3), says that "Each of the macros
> FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW,
> FE_UNDERFLOW is defined when the implementation supports
> handling of the corresponding exception".
>
> A git-grep shows that this was the only place using a FE_ macro
> unconditionally.
>
> libstdc++-v3:
> * testsuite/20_util/from_chars/6.cc (test01) [FE_DOWNWARD]:
> Conditionalize call to fesetround.
>
> diff --git a/libstdc++-v3/testsuite/20_util/from_chars/6.cc 
> b/libstdc++-v3/testsuite/20_util/from_chars/6.cc
> index d33484cebfee..fff3450b56c9 100644
> --- a/libstdc++-v3/testsuite/20_util/from_chars/6.cc
> +++ b/libstdc++-v3/testsuite/20_util/from_chars/6.cc
> @@ -30,7 +30,9 @@ test01()
>  #if __cpp_lib_to_chars >= 201611L
>  #if _GLIBCXX_USE_C99_FENV_TR1
>double d;
> +#ifdef FE_DOWNWARD
>std::fesetround(FE_DOWNWARD);
> +#endif
>const std::string s = "0.099";
>auto res = std::from_chars(s.data(), s.data() + s.length(), d);
>VERIFY( res.ec == std::errc{} );
> --
> 2.30.2
>



[PATCH] c++: alias template arguments are evaluated [PR101906]

2022-03-22 Thread Patrick Palka via Gcc-patches
Here we're neglecting to clear cp_unevaluated_operand when substituting
into the arguments of the alias template-id skip<(T(), 0), T> with T=A,
which means cp_unevaluated_operand remains set during mark_used for
A::A() and so we never synthesize it.  Later constant evaluation for
the substituted template argument (A(), 0) (during coerce_template_parms)
fails with "'constexpr A::A()' used before its definition" since it was
never synthesized.

This minimal patch makes us clear cp_unevaluated_operand when
substituting into the template arguments of an alias template-id, as in
tsubst_aggr_type.

(A few lines below we also substitute into the template arguments of a
class-scope typedef, during which we arguably also should clear
cp_unevaluated_operand, but I wasn't able to come up with a testcase for
which this mattered, because if we've named a class-scope typedef, then
at some point tsubst_aggr_type must have already substituted the class
scope, which performs the same substitution with cp_unevaluated_operand
cleared.)

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/101906

gcc/cp/ChangeLog:

* pt.cc (tsubst): Clear cp_unevaluated_operand when substituting
the template arguments of an alias template specialization.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-75.C: New test.
* g++.dg/cpp0x/alias-decl-75a.C: New test.
---
 gcc/cp/pt.cc|  6 +-
 gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C  | 15 +++
 gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C | 16 
 3 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 7697615ac64..c7116849551 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -15545,7 +15545,11 @@ tsubst (tree t, tree args, tsubst_flags_t complain, 
tree in_decl)
  /* DECL represents an alias template and we want to
 instantiate it.  */
  tree tmpl = most_general_template (DECL_TI_TEMPLATE (decl));
- tree gen_args = tsubst (DECL_TI_ARGS (decl), args, complain, in_decl);
+ tree gen_args;
+   {
+ cp_evaluated ev;
+ gen_args = tsubst (DECL_TI_ARGS (decl), args, complain, in_decl);
+   }
  r = instantiate_alias_template (tmpl, gen_args, complain);
}
   else if (DECL_CLASS_SCOPE_P (decl)
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C
new file mode 100644
index 000..c6176751283
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C
@@ -0,0 +1,15 @@
+// PR c++/101906
+// { dg-do compile { target c++11 } }
+
+template using skip = T;
+
+template
+constexpr unsigned sizeof_() {
+  return sizeof(skip<(T(), 0), T>);
+}
+
+struct A {
+  int m = -1;
+};
+
+static_assert(sizeof_() == sizeof(A), "");
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C
new file mode 100644
index 000..ce08a84f6d9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C
@@ -0,0 +1,16 @@
+// PR c++/101906
+// Similar to alias-decl-75.C, but where the unevaluated context is a
+// constraint instead of sizeof.
+// { dg-do compile { target c++20 } }
+
+template using voidify = void;
+
+template
+concept constant_value_initializable
+  = requires { typename voidify<(T(), 0)>; };
+
+struct A {
+  int m = -1;
+};
+
+static_assert(constant_value_initializable);
-- 
2.35.1.607.gf01e51a7cf



[PATCH] Docs: Document that taint analyzer checker stops other checkers

2022-03-22 Thread Avinash Sonawane via Gcc-patches
Hello!

$ man gcc says that "Some checkers are disabled by default (even with
-fanalyzer), such as the "taint" checker that implements
-Wanalyzer-tainted-array-index, and this option is required to enable
them." but still lists the -Wanalyzer-tainted-* checkers under
-fanalyzer saying "Enabling this option effectively enables the
following warnings:"

This patch comments out the tainted-* checkers so that when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533 gets fixed we can
remove the comment and list them under -fanalyzer

Also, the above wording suggests that `-fanalyzer
-fanalyzer-checker=taint` enables the taint checkers in addition to
the default checkers but currently, enabling -fanalyzer-checker=taint
stops other checkers. This patch documents that too.

Please find the attached patch.

Thanks!

Regards,
Avinash Sonawane (rootKea)
https://www.rootkea.me
>From 764baac8ffed188d50293f0991ab43c97b63cc8a Mon Sep 17 00:00:00 2001
From: Avinash Sonawane 
Date: Tue, 22 Mar 2022 07:32:44 +0530
Subject: [PATCH] Docs: Document that taint analyzer checker stops other
 checkers

---
 gcc/doc/invoke.texi | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4da4a1170f5..1996b54cf28 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9666,11 +9666,13 @@ Enabling this option effectively enables the following warnings:
 -Wanalyzer-shift-count-negative @gol
 -Wanalyzer-shift-count-overflow @gol
 -Wanalyzer-stale-setjmp-buffer @gol
+@ignore
 -Wanalyzer-tainted-allocation-size @gol
 -Wanalyzer-tainted-array-index @gol
 -Wanalyzer-tainted-divisor @gol
 -Wanalyzer-tainted-offset @gol
 -Wanalyzer-tainted-size @gol
+@end ignore
 -Wanalyzer-unsafe-call-within-signal-handler @gol
 -Wanalyzer-use-after-free @gol
 -Wanalyzer-use-of-uninitialized-value @gol
@@ -10015,6 +10017,8 @@ such as the @code{taint} checker that implements
 @option{-Wanalyzer-tainted-array-index}, and this option is required
 to enable them.
 
+@emph{Note:} currently, @option{-fanalyzer-checker=taint} stops all other checkers.
+
 @item -fno-analyzer-feasibility
 @opindex fanalyzer-feasibility
 @opindex fno-analyzer-feasibility
-- 
2.32.0



Re: [PATCH] c++: alias template arguments are evaluated [PR101906]

2022-03-22 Thread Patrick Palka via Gcc-patches
On Tue, 22 Mar 2022, Patrick Palka wrote:

> Here we're neglecting to clear cp_unevaluated_operand when substituting
> into the arguments of the alias template-id skip<(T(), 0), T> with T=A,
> which means cp_unevaluated_operand remains set during mark_used for
> A::A() and so we never synthesize it.  Later constant evaluation for
> the substituted template argument (A(), 0) (during coerce_template_parms)
> fails with "'constexpr A::A()' used before its definition" since it was
> never synthesized.

It occurred to me to check the case where 'skip' is a function/variable
template instead of an alias template, and unfortunately seems we run
into the same issue:

  template T skip();  // Function template
  // template T skip; // Variable template

  template
  constexpr unsigned sizeof_() {
return sizeof(skip<(T(), 0), T>());
// return sizeof(skip<(T(), 0), T>);
  }

  struct A {
int m = -1;
  };

  static_assert(sizeof_() == sizeof(A), "");

: In instantiation of ‘constexpr unsigned int sizeof_() [with T = A]’:
:14:25:   required from here
:6:34: error: ‘constexpr A::A()’ used before its definition

We can fix this similarly by clearing cp_unevaluated_operand when
substituting into the arguments of a TEMPLATE_ID_EXPR, but now I'm
worried this cp_unevaluated_operand business might not be the best
approach (despite it being consistent with what tsubst_aggr_type does).

Maybe instantiate_cx_fn_r should be responsible for making sure A::A()
gets synthesized?

> 
> This minimal patch makes us clear cp_unevaluated_operand when
> substituting into the template arguments of an alias template-id, as in
> tsubst_aggr_type.
> 
> (A few lines below we also substitute into the template arguments of a
> class-scope typedef, during which we arguably also should clear
> cp_unevaluated_operand, but I wasn't able to come up with a testcase for
> which this mattered, because if we've named a class-scope typedef, then
> at some point tsubst_aggr_type must have already substituted the class
> scope, which performs the same substitution with cp_unevaluated_operand
> cleared.)
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
> 
>   PR c++/101906
> 
> gcc/cp/ChangeLog:
> 
>   * pt.cc (tsubst): Clear cp_unevaluated_operand when substituting
>   the template arguments of an alias template specialization.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp0x/alias-decl-75.C: New test.
>   * g++.dg/cpp0x/alias-decl-75a.C: New test.
> ---
>  gcc/cp/pt.cc|  6 +-
>  gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C  | 15 +++
>  gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C | 16 
>  3 files changed, 36 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C
> 
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 7697615ac64..c7116849551 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -15545,7 +15545,11 @@ tsubst (tree t, tree args, tsubst_flags_t complain, 
> tree in_decl)
> /* DECL represents an alias template and we want to
>instantiate it.  */
> tree tmpl = most_general_template (DECL_TI_TEMPLATE (decl));
> -   tree gen_args = tsubst (DECL_TI_ARGS (decl), args, complain, in_decl);
> +   tree gen_args;
> + {
> +   cp_evaluated ev;
> +   gen_args = tsubst (DECL_TI_ARGS (decl), args, complain, in_decl);
> + }
> r = instantiate_alias_template (tmpl, gen_args, complain);
>   }
>else if (DECL_CLASS_SCOPE_P (decl)
> diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C 
> b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C
> new file mode 100644
> index 000..c6176751283
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75.C
> @@ -0,0 +1,15 @@
> +// PR c++/101906
> +// { dg-do compile { target c++11 } }
> +
> +template using skip = T;
> +
> +template
> +constexpr unsigned sizeof_() {
> +  return sizeof(skip<(T(), 0), T>);
> +}
> +
> +struct A {
> +  int m = -1;
> +};
> +
> +static_assert(sizeof_() == sizeof(A), "");
> diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C 
> b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C
> new file mode 100644
> index 000..ce08a84f6d9
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-75a.C
> @@ -0,0 +1,16 @@
> +// PR c++/101906
> +// Similar to alias-decl-75.C, but where the unevaluated context is a
> +// constraint instead of sizeof.
> +// { dg-do compile { target c++20 } }
> +
> +template using voidify = void;
> +
> +template
> +concept constant_value_initializable
> +  = requires { typename voidify<(T(), 0)>; };
> +
> +struct A {
> +  int m = -1;
> +};
> +
> +static_assert(constant_value_initializable);
> -- 
> 2.35.1.607.gf01e51a7cf
> 
> 


[wwwdocs] [PATCH 0/4] Fix various typos

2022-03-22 Thread Pokechu22 via Gcc-patches
While working on a separate patch, I found several typos on the website.
I have only looked within the htdocs directory, not its subdirectories.

These are individual patches per file, since that seemed reasonable to me.

I believe this is a small enough change that I do not need to go through
copyright assignment or DCO certification (if I had supplied a list of
files and line numbers, I suspect anyone else would have made the same
patches).  I would rather remain pseudonymous.

I've sent these patches using gmail's web interface since I have had
bad experiences setting up command-line mailing.  Hopefully they have
not been mangled by it.

--Poke


[wwwdocs] [PATCH 1/4] branch-closing: Fix various typos

2022-03-22 Thread Pokechu22 via Gcc-patches
---
 htdocs/branch-closing.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/branch-closing.html b/htdocs/branch-closing.html
index c36ad1ab..15fb90e3 100644
--- a/htdocs/branch-closing.html
+++ b/htdocs/branch-closing.html
@@ -54,7 +54,7 @@ is listed in "Known to work" or "Known to fail" as
applicable.
 If the bug is a regression that is not fixed on all subsequent
 release branches and on trunk then it needs to remain open.  Remove
 the version number of the branch being closed from the summary (for
-example, change "[7/8 Regression]" to "[8 Regression]".  If the
+example, change "[7/8 Regression]" to "[8 Regression]").  If the
 milestone is not set, or is set to a version from the branch being
 closed, set it to the version number of the next release from the next
 oldest release branch.
-- 
2.25.1


[wwwdocs] [PATCH 2/4] codingconventions: Fix various typos

2022-03-22 Thread Pokechu22 via Gcc-patches
---
 htdocs/codingconventions.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index e4d30510..86b63b89 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -141,7 +141,7 @@ a large batch of changes.
 supported formats: a/b/c/ChangeLog,
a/b/c/ChangeLog:, a/b/c/ (where ChangeLog
file lives in the folder), \ta/b/c/ and
a/b/c
 pr_entry - bug report reference 
 example: \tPR component/12345
-changelog_file - a modified file mentined in a ChangeLog:
+changelog_file - a modified file mentioned in a ChangeLog:
 supported formats: \t* a/b/c/file.c:, \t*
a/b/c/file.c (function):, \t* a/b/c/file1.c,
a/b/c/file2.c:
 changelog_file_comment - line that follows a
changelog_file with description of changes in the file;
 must start with \t
@@ -153,7 +153,7 @@ a large batch of changes.
 Format rules

 
-git_description - optional; ends right before
one of the other compoments is found
+git_description - optional; ends right before
one of the other components is found
 committer_timestamp - optional; when found
before a changelog_file, then it is added
 to each changelog entry
 additional_author - optional
@@ -1022,7 +1022,7 @@ intended to last a long time.
 
 Complex hierarchies are to be avoided.
 Take special care with multiple inheritance.
-On the rare occasion that using mulitple inheritance is indeed useful,
+On the rare occasion that using multiple inheritance is indeed useful,
 prepare design rationales in advance,
 and take special care to make documentation of the entire hierarchy clear.
 (In particular, multiple inheritance can be an acceptable way of combining
-- 
2.25.1


[wwwdocs] [PATCH 3/4] codingrationale: Fix various typos

2022-03-22 Thread Pokechu22 via Gcc-patches
---
 htdocs/codingrationale.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..f523f3e2 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -18,7 +18,7 @@

 
 Inlining functions has a potential cost in object size,
-working set size, compile time, and debuggablity.
+working set size, compile time, and debuggability.
 These costs should not be borne without some evidence
 that the inlining pays for itself.
 
@@ -155,7 +155,7 @@ Wide use of implicit conversion can cause some
very surprising results.

 
 C++03 has no explicit conversion operators,
-and hence using them cannot avoid suprises.
+and hence using them cannot avoid surprises.
 Wait for C++11.
 

-- 
2.25.1


[wwwdocs] [PATCH 4/4] contribute: Fix various typos

2022-03-22 Thread Pokechu22 via Gcc-patches
---
 htdocs/contribute.html | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index c0223738..2d04b1f0 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -267,7 +267,7 @@ characters.

 The classifier identifies the type of contribution, for example a
 patch, an RFC (request for comments) or a committed patch (where
-approval is not necessary.  The classifier should be written in upper
+approval is not necessary).  The classifier should be written in upper
 case and surrounded with square brackets.  This is the only component
 of the e-mail subject line that will not appear in the commit itself.
 The classifier may optionally contain a version number (vN) and
@@ -297,7 +297,7 @@ followed by a colon.  For example,
 

 Some large components may be subdivided into sub-components.  If
-the subcomponent name is not disctinct in its own right, you can use the
+the subcomponent name is not distinct in its own right, you can use the
 form component/sub-component:.

 Series identifier
@@ -327,7 +327,7 @@ the commit message so that Bugzilla will correctly
notice the
 commit.  If your patch relates to two bugs, then write
 [PRn, PRm].  For multiple
 bugs, just cite the most relevant one in the summary and use an
-elipsis instead of the second, or subsequent PR numbers; list all the
+ellipsis instead of the second, or subsequent PR numbers; list all the
 related PRs in the body of the commit message in the normal way.

 It is not necessary to cite bugs that are closed as duplicates of
@@ -352,7 +352,7 @@ together.
 If you submit a new version of a patch series, then you should
 start a new email thread (don't reply to the original patch series).
 This avoids email threads becoming confused between discussions of the
-first and subsequent revisions of the patch set.  Your cover leter
+first and subsequent revisions of the patch set.  Your cover letter
 (0/nnn) should explain clearly what has been changed between
 the two patch series.  Also state if some of the patches are unchanged
 between revisions; this saves maintainers having to re-review the
-- 
2.25.1


[Committed] PR fortran/104999 - [12 Regression] runtime error: pointer index expression with base 0x00000cf67720 overflowed to 0xffffffffea627728

2022-03-22 Thread Harald Anlauf via Gcc-patches
Dear all,

as reported by Martin Liška, a sanitized compiler hits an uninitialized stride
value when simplifying CSHIFT in testcase gfortran.dg/simplify_cshift_1.f90.
Committed as obvious after confirmation in the PR by Martin that the attached
patch fixes the issue.

commit r12-7771-g774ab2edcb5f3a24ed3a5cffd1143bd49a69f1ee

Thanks,
Harald

From 774ab2edcb5f3a24ed3a5cffd1143bd49a69f1ee Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 22 Mar 2022 20:54:18 +0100
Subject: [PATCH] Fortran: ensure intialization of stride array

gcc/fortran/ChangeLog:

	PR fortran/104999
	* simplify.cc (gfc_simplify_cshift): Ensure temporary holding
	source array stride is initialized.
---
 gcc/fortran/simplify.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 0c15bcb2b0a..233cc42137f 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -2134,6 +2134,7 @@ gfc_simplify_cshift (gfc_expr *array, gfc_expr *shift, gfc_expr *dim)

   resultvec = XCNEWVEC (gfc_expr *, arraysize);

+  sstride[0] = 0;
   extent[0] = 1;
   count[0] = 0;

--
2.34.1



[PATCH] c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

2022-03-22 Thread Marek Polacek via Gcc-patches
This patch fixes two kinds of wrong -Wmissing-field-initializers
warnings.  Our docs say that this warning "does not warn about designated
initializers", but we give a warning for

1) the array case:

  struct S {
struct N {
  int a;
  int b;
} c[1];
  } d = {
.c[0].a = 1,
.c[0].b = 1, // missing initializer for field 'b' of 'struct N'
  };

we warn because push_init_level, when constructing an array, clears
constructor_designated (which the warning relies on), and we forget
that we were in a designated initializer context.  Fixed by the
push_init_level hunk; and

2) the compound literal case:

  struct T {
int a;
int *b;
int c;
  };

  struct T t = { .b = (int[]){1} }; // missing initializer for field 'c' of 
'struct T'

where set_designator properly sets constructor_designated to 1, but the
compound literal causes us to create a whole new initializer_stack in
start_init, which clears constructor_designated.  Then, after we've parsed
the compound literal, finish_init flushes the initializer_stack entry,
but doesn't restore constructor_designated, so we forget we were in
a designated initializer context, which causes the bogus warning.  (The
designated flag is also tracked in constructor_stack, but in this case,
we didn't perform push_init_level between set_designator and start_init
so it wasn't saved anywhere.)

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?  Maybe 11 too.

PR c/82283
PR c/84685

gcc/c/ChangeLog:

* c-typeck.cc (struct initializer_stack): Add 'designated' member.
(start_init): Set it.
(finish_init): Restore constructor_designated.
(push_init_level): Set constructor_designated to the value of
constructor_designated in the upper constructor_stack.

gcc/testsuite/ChangeLog:

* gcc.dg/Wmissing-field-initializers-1.c: New test.
* gcc.dg/Wmissing-field-initializers-2.c: New test.
* gcc.dg/Wmissing-field-initializers-3.c: New test.
* gcc.dg/Wmissing-field-initializers-4.c: New test.
* gcc.dg/Wmissing-field-initializers-5.c: New test.
---
 gcc/c/c-typeck.cc | 10 +++--
 .../gcc.dg/Wmissing-field-initializers-1.c| 22 ++
 .../gcc.dg/Wmissing-field-initializers-2.c| 11 +
 .../gcc.dg/Wmissing-field-initializers-3.c| 24 +++
 .../gcc.dg/Wmissing-field-initializers-4.c| 43 +++
 .../gcc.dg/Wmissing-field-initializers-5.c| 22 ++
 6 files changed, 128 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/Wmissing-field-initializers-1.c
 create mode 100644 gcc/testsuite/gcc.dg/Wmissing-field-initializers-2.c
 create mode 100644 gcc/testsuite/gcc.dg/Wmissing-field-initializers-3.c
 create mode 100644 gcc/testsuite/gcc.dg/Wmissing-field-initializers-4.c
 create mode 100644 gcc/testsuite/gcc.dg/Wmissing-field-initializers-5.c

diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index c0812de84b4..6c4af5e4cde 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -8438,6 +8438,7 @@ struct initializer_stack
   char top_level;
   char require_constant_value;
   char require_constant_elements;
+  char designated;
   rich_location *missing_brace_richloc;
 };
 
@@ -8464,6 +8465,7 @@ start_init (tree decl, tree asmspec_tree 
ATTRIBUTE_UNUSED, int top_level,
   p->top_level = constructor_top_level;
   p->next = initializer_stack;
   p->missing_brace_richloc = richloc;
+  p->designated = constructor_designated;
   initializer_stack = p;
 
   constructor_decl = decl;
@@ -8522,6 +8524,7 @@ finish_init (void)
   require_constant_value = p->require_constant_value;
   require_constant_elements = p->require_constant_elements;
   constructor_stack = p->constructor_stack;
+  constructor_designated = p->designated;
   constructor_range_stack = p->constructor_range_stack;
   constructor_elements = p->elements;
   spelling = p->spelling;
@@ -8731,7 +8734,9 @@ push_init_level (location_t loc, int implicit,
   constructor_depth = SPELLING_DEPTH ();
   constructor_elements = NULL;
   constructor_incremental = 1;
-  constructor_designated = 0;
+  /* If the upper initializer is designated, then mark this as
+ designated too to prevent bogus warnings.  */
+  constructor_designated = p->designated;
   constructor_pending_elts = 0;
   if (!implicit)
 {
@@ -8756,9 +8761,6 @@ push_init_level (location_t loc, int implicit,
  push_member_name (constructor_fields);
  constructor_depth++;
}
-  /* If upper initializer is designated, then mark this as
-designated too to prevent bogus warnings.  */
-  constructor_designated = p->designated;
 }
   else if (TREE_CODE (constructor_type) == ARRAY_TYPE)
 {
diff --git a/gcc/testsuite/gcc.dg/Wmissing-field-initializers-1.c 
b/gcc/testsuite/gcc.dg/Wmissing-field-initializers-1.c
new file mode 100644
index 000..fbcca44db5f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wmissing-field-initializers-

Re: [PATCH] c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

2022-03-22 Thread Joseph Myers
On Tue, 22 Mar 2022, Marek Polacek via Gcc-patches wrote:

>   PR c/82283
>   PR c/84685
> 
> gcc/c/ChangeLog:
> 
>   * c-typeck.cc (struct initializer_stack): Add 'designated' member.
>   (start_init): Set it.
>   (finish_init): Restore constructor_designated.
>   (push_init_level): Set constructor_designated to the value of
>   constructor_designated in the upper constructor_stack.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/Wmissing-field-initializers-1.c: New test.
>   * gcc.dg/Wmissing-field-initializers-2.c: New test.
>   * gcc.dg/Wmissing-field-initializers-3.c: New test.
>   * gcc.dg/Wmissing-field-initializers-4.c: New test.
>   * gcc.dg/Wmissing-field-initializers-5.c: New test.

OK.

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


[PATCH] c++: Fall through for arrays of T vs T cv [PR104996]

2022-03-22 Thread Ed Catmur
If two arrays do not have the exact same element type including qualification, 
this could be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be 
distinguished by the lvalue-rvalue tiebreaker.

By tightening this branch (in accordance with the letter of the Standard) we 
fall through to the next branch, which tests whether they have different 
element type ignoring qualification and returns 0 in that case; thus we only 
actually fall through in the T[...] vs. T cv[...] case, eventually considering 
the lvalue-rvalue tiebreaker at the end of compare_ics.

Add test.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104996
---
 gcc/cp/call.cc  | 7 ++-
 gcc/testsuite/g++.dg/pr104996.C | 5 +
 2 files changed, 7 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr104996.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 23d3fc496b822..28589ab3459ea 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -11535,12 +11535,9 @@ compare_ics (conversion *ics1, conversion *ics2)
 P0388R4.)  */
   else if (t1->kind == ck_aggr
   && TREE_CODE (t1->type) == ARRAY_TYPE
-  && TREE_CODE (t2->type) == ARRAY_TYPE)
+  && TREE_CODE (t2->type) == ARRAY_TYPE
+  && same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
{
- /* The type of the array elements must be the same.  */
- if (!same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
-   return 0;
-
  tree n1 = nelts_initialized_by_list_init (t1);
  tree n2 = nelts_initialized_by_list_init (t2);
  if (tree_int_cst_lt (n1, n2))
diff --git a/gcc/testsuite/g++.dg/pr104996.C b/gcc/testsuite/g++.dg/pr104996.C
new file mode 100644
index 0..2e7558c7b9c77
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr104996.C
@@ -0,0 +1,5 @@
+// { dg-do compile { target c++11 } }
+
+template char f(int (&&)[size]);
+template int f(int const (&)[size]);
+static_assert(sizeof(f({1, 2, 3})) == 1, "");


Re: [PATCH] c++: Fall through for arrays of T vs T cv [PR104996]

2022-03-22 Thread Marek Polacek via Gcc-patches
On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote:
> If two arrays do not have the exact same element type including 
> qualification, this could be e.g. f(int (&&)[]) vs. f(int const (&)[]), which 
> can still be distinguished by the lvalue-rvalue tiebreaker.
> 
> By tightening this branch (in accordance with the letter of the Standard) we 
> fall through to the next branch, which tests whether they have different 
> element type ignoring qualification and returns 0 in that case; thus we only 
> actually fall through in the T[...] vs. T cv[...] case, eventually 
> considering the lvalue-rvalue tiebreaker at the end of compare_ics.
> 
> Add test.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104996

Thanks, the patch looks reasonable.  Can you describe how it's been tested?

You're going to need a ChangeLog entry, something like

* call.c (compare_ics): When comparing list-initialization sequences,
do not return early.

and an entry for the test, which...

> ---
>  gcc/cp/call.cc  | 7 ++-
>  gcc/testsuite/g++.dg/pr104996.C | 5 +
>  2 files changed, 7 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/pr104996.C
> 
> diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
> index 23d3fc496b822..28589ab3459ea 100644
> --- a/gcc/cp/call.cc
> +++ b/gcc/cp/call.cc
> @@ -11535,12 +11535,9 @@ compare_ics (conversion *ics1, conversion *ics2)
>P0388R4.)  */
>else if (t1->kind == ck_aggr
>  && TREE_CODE (t1->type) == ARRAY_TYPE
> -&& TREE_CODE (t2->type) == ARRAY_TYPE)
> +&& TREE_CODE (t2->type) == ARRAY_TYPE
> +&& same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
>   {
> -   /* The type of the array elements must be the same.  */
> -   if (!same_type_p (TREE_TYPE (t1->type), TREE_TYPE (t2->type)))
> - return 0;
> -
> tree n1 = nelts_initialized_by_list_init (t1);
> tree n2 = nelts_initialized_by_list_init (t2);
> if (tree_int_cst_lt (n1, n2))
> diff --git a/gcc/testsuite/g++.dg/pr104996.C b/gcc/testsuite/g++.dg/pr104996.C
> new file mode 100644
> index 0..2e7558c7b9c77
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pr104996.C

...can you please rename the test to initlist129.C and put it into g++.dg/cpp0x?

> @@ -0,0 +1,5 @@

Also please add

// PR c++/104996

in the first line.

> +// { dg-do compile { target c++11 } }
> +
> +template char f(int (&&)[size]);
> +template int f(int const (&)[size]);
> +static_assert(sizeof(f({1, 2, 3})) == 1, "");
> 

Marek



Re: [PATCH] Docs: Document that taint analyzer checker stops other checkers

2022-03-22 Thread David Malcolm via Gcc-patches
On Tue, 2022-03-22 at 23:43 +0530, Avinash Sonawane via Gcc-patches
wrote:
> Hello!
> 
> $ man gcc says that "Some checkers are disabled by default (even with
> -fanalyzer), such as the "taint" checker that implements
> -Wanalyzer-tainted-array-index, and this option is required to enable
> them." but still lists the -Wanalyzer-tainted-* checkers under
> -fanalyzer saying "Enabling this option effectively enables the
> following warnings:"
> 
> This patch comments out the tainted-* checkers so that when
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533 gets fixed we can
> remove the comment and list them under -fanalyzer
> 
> Also, the above wording suggests that `-fanalyzer
> -fanalyzer-checker=taint` enables the taint checkers in addition to
> the default checkers but currently, enabling -fanalyzer-checker=taint
> stops other checkers. This patch documents that too.
> 
> Please find the attached patch.
> 
Thanks for the patch.  I think it's a definite improvement in
readability for the end-user.  

The option and the docs refer to "checkers" e.g.
  "currently, -fanalyzer-checker=taint stops all other checkers"
but these checkers are an implementation detail of the analyzer; not
all of the analyzer warnings relate to a checker.

So it would be even better if the text listed the warnings that are
affected by this: basically all of the ones that are implemented in
checkers i.e. analyzer/sm-*.cc (apart from sm-taint, of course).

I can put that together if need be (but I'm about to sign off for today
and only just saw this patch).

Ideally, of course, we'd fix bug 103533, but that's GCC 13 material at
this point :)

Thanks again for the patch
Dave



[PATCH] c++: FIX_TRUNC_EXPR in tsubst [PR102990]

2022-03-22 Thread Marek Polacek via Gcc-patches
This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().

The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it
was introduced in r181478, but it did the wrong thing, whereupon it
was turned into gcc_unreachable () in r258821 (see this thread:
).

In a template, we should never create a FIX_TRUNC_EXPR (that's what
conv_unsafe_in_template_p is for).  But in this test we are NOT in
a template when we call digest_nsdmi_init which ends up calling
convert_like, converting 1.0e+0 to int, so convert_to_integer_1
gives us a FIX_TRUNC_EXPR.

But then when we get to parsing f's parameters, we are in a template
when processing decltype(Helpers{}), and since r268321, when the
compound literal isn't instantiation-dependent and the type isn't
type-dependent, finish_compound_literal falls back to the normal
processing, so it calls digest_init, which does fold_non_dependent_init
and since the FIX_TRUNC_EXPR isn't dependent, we instantiate and
therefore crash in tsubst_copy_and_build.

Either I can tweak p_c_e to say that a FIX_TRUNC_EXPR in a template
is not potentially constant, or I can just remove the whole F_T_E
case, since:
a) we could not have created an IMPLICIT_CONV_EXPR here, and
b) similar code, FLOAT_EXPR, is not handled here, either.

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

PR c++/102990

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build) : Remove.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template22.C: New test.
* g++.dg/cpp0x/nsdmi-template23.C: New test.
---
 gcc/cp/pt.cc  |  4 
 gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C | 13 +
 gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C | 13 +
 3 files changed, 26 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 715eea27577..a3becc19290 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -20184,10 +20184,6 @@ tsubst_copy_and_build (tree t,
templated_operator_saved_lookups (t),
complain|decltype_flag));
 
-case FIX_TRUNC_EXPR:
-  /* convert_like should have created an IMPLICIT_CONV_EXPR.  */
-  gcc_unreachable ();
-
 case ADDR_EXPR:
   op1 = TREE_OPERAND (t, 0);
   if (TREE_CODE (op1) == LABEL_DECL)
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C 
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C
new file mode 100644
index 000..4ed2501035c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C
@@ -0,0 +1,13 @@
+// PR c++/102990
+// { dg-do compile { target c++11 } }
+
+struct knob_t {
+  /* Let's create a FIX_TRUNC_EXPR.  */
+  int value = 1.0;
+};
+
+struct Helpers {
+  knob_t inputs;
+};
+
+template void f(decltype(Helpers{}));
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C 
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C
new file mode 100644
index 000..240cab4347a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C
@@ -0,0 +1,13 @@
+// PR c++/102990
+// { dg-do compile { target c++11 } }
+
+struct knob_t {
+  /* Let's create a FLOAT_EXPR.  */
+  double value = 1UL;
+};
+
+struct Helpers {
+  knob_t inputs;
+};
+
+template void f(decltype(Helpers{}));

base-commit: 5d2233f4033dfa37ad88dc2eab138524fe64242e
-- 
2.35.1



Re: [PATCH]rs6000: avoid peeking eof after __vector keyword

2022-03-22 Thread Jiufu Guo via Gcc-patches
Segher Boessenkool  writes:

> Hi!
>
> On Tue, Mar 22, 2022 at 01:50:39PM +0800, Jiufu Guo wrote:
>> Segher Boessenkool  writes:
>> > On Mon, Mar 21, 2022 at 02:14:08PM -0400, David Edelsohn wrote:
>> >> On Mon, Mar 21, 2022 at 5:13 AM Jiufu Guo  wrote:
>> >> > There is a rare corner case: where __vector is followed only with ";"
>> >> > and near the end of the file.
>> >
>> >> This is okay. Maybe a tweak to the comment, see below.
>> >
>> > This whole function could use some restructuring / rewriting to make
>> > clearer what it actually does.  See the function comment:
>> >
>> > /* Called to decide whether a conditional macro should be expanded.
>> >Since we have exactly one such macro (i.e, 'vector'), we do not
>> >need to examine the 'tok' parameter.  */
>> >
>> > ... followed by 17 uses of "tok".  Yes, some of those overwrite the
>> > function argument, but that doesn't make it any better!  :-P
>> >
>> > Some factoring would help, too, perhaps.
>> 
>> Thanks for your review!
>> 
>> I am also confused about it when I check this function for the first
>> time. In the function, 'tok' is used directly at the beginning, and
>> then it is overwritten by cpp_peek_token.
>> >From the history of this function, the first version of this function
>> contains this 'inconsistency' between comments and implementations. :-P
>> 
>> With check related code, it seems this function is used to predicate
>> if a conditional macro should be expanded by peeking two or more
>> tokens.
>
> Yes, and the function comment should say that, that's what it's for :-)
>
>> The context-sensitive macros are vector/bool/pixel.  Correponding
>> keywords __vector/__bool/__pixel are unconditional.
>> Based on those related codes, the behavior of function
>> rs6000_macro_to_expand would be checking if the 'vector' token is
>> followed by bool/__bool or pixel/__pixel.  To do this the 'tok' has to
>> be 'examined'.
>> 
>> >From this understanding, we may just update the comment.
>> While the patch does not cover this.
>
> Yes, and it doesn't have to, probably it's best not to change the code
> much in stage 4 anyway.  It is really hard to fix bugs in it, or to
> review the resulting patches, without documentation what it is supposed
> to do (especially if the code isn't clear, is inconsistent, and even
> contradicts the little documentation that there is).

Thanks for your comments!

Understand. :)  I would commit the patch and submit patch to update
the comments in stage 1.

BR,
Jiufu

>
> Oh well.
>
>
> Segher


[PATCH] Fix ICE caused by NULL_RTX returned by lowpart_subreg.

2022-03-22 Thread liuhongt via Gcc-patches
In validate_subreg, both (subreg:V2HF (reg:SI) 0)
and (subreg:V8HF (reg:V2HF) 0) are valid, but not
for (subreg:V8HF (reg:SI) 0) which causes ICE.

Ideally it should be handled in validate_subreg to support
subreg for all modes available in TARGET_CAN_CHANGE_MODE_CLASS, but
that would be too risky in stage4, so the patch is a walkround in the
backend to force_reg operands before lowpart_subreg for expanders or
pre_reload splitters.

Bootstrapped and regtest on x86_64-pc-linux-gnu{-m32,}.
Also with native on SPR.
Ok for trunk?

gcc/ChangeLog:

PR target/104976
* config/i386/sse.md (ssePSmodelower): New.
(*avx_cmp3_ltint_not): Force_reg operand before
lowpart_subreg to avoid NULL_RTX.
(_fmaddc__mask1,
_fcmaddc__mask1,
fma__fmaddc_bcst, fma__fcmaddc_bcst,
___mask,
avx512fp16_fcmaddcsh_v8hf_mask1,
avx512fp16_fcmaddcsh_v8hf_mask3,
avx512fp16_fmaddcsh_v8hf_mask3,
avx512fp16_fmaddcsh_v8hf_mask3,
floatv4hf2,
floatv2div2hf2,
fix_truncv4hf2,
fix_truncv2hfv2di2, extendv4hf2,
extendv2hfv2df2,
truncv4hf2,truncv2dfv2hf2,
*avx512bw_permvar_truncv16siv16hi_1,
*avx512bw_permvar_truncv16siv16hi_1_hf,
*avx512f_permvar_truncv8siv8hi_1,
*avx512f_permvar_truncv8siv8hi_1_hf,
*avx512f_vpermvar_truncv8div8si_1,
*avx512f_permvar_truncv32hiv32qi_1,
*avx512f_permvar_truncv16hiv16qi_1,
*avx512f_permvar_truncv4div4si_1,
*avx512f_pshufb_truncv8hiv8qi_1,
*avx512f_pshufb_truncv4siv4hi_1,
*avx512f_pshufd_truncv2div2si_1,
sdot_prod, avx2_pblend_1,
ashrv2di3,ashrv2di3,usdot_prod): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr104976.c: New test.
* gcc.target/i386/avx512fp16-vfcmaddcph-1a.c: Scan either
vblendps or masked vmovaps.
* gcc.target/i386/avx512fp16-vfmaddcph-1a.c: Ditto
* gcc.target/i386/avx512fp16vl-vfcmaddcph-1a.c: Ditto.
* gcc.target/i386/avx512fp16vl-vfmaddcph-1a.c: Ditto.
---
 gcc/config/i386/sse.md| 236 +-
 .../i386/avx512fp16-vfcmaddcph-1a.c   |   2 +-
 .../gcc.target/i386/avx512fp16-vfmaddcph-1a.c |   2 +-
 .../i386/avx512fp16vl-vfcmaddcph-1a.c |   4 +-
 .../i386/avx512fp16vl-vfmaddcph-1a.c  |   4 +-
 gcc/testsuite/gcc.target/i386/pr104976.c  |  13 +
 6 files changed, 196 insertions(+), 65 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr104976.c

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6f7af2f21d6..a9e18d38323 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -1059,6 +1059,18 @@ (define_mode_attr ssePSmode
(V4DF "V8SF") (V2DF "V4SF")
(V32HF "V16SF") (V16HF "V8SF") (V8HF "V4SF")])
 
+(define_mode_attr ssePSmodelower
+  [(V16SI "v16sf") (V8DF "v16sf")
+   (V16SF "v16sf") (V8DI "v16sf")
+   (V64QI "v16sf") (V32QI "v8sf") (V16QI "v4sf")
+   (V32HI "v16sf") (V16HI "v8sf") (V8HI "v4sf")
+   (V8SI "v8sf") (V4SI "v4sf")
+   (V4DI "v8sf") (V2DI "v4sf")
+   (V4TI "v16sf") (V2TI "v8sf") (V1TI "v4sf")
+   (V8SF "v8sf") (V4SF "v4sf")
+   (V4DF "v8sf") (V2DF "v4sf")
+   (V32HF "v16sf") (V16HF "v8sf") (V8HF "v4sf")])
+
 (define_mode_attr ssePSmode2
   [(V8DI "V8SF") (V4DI "V4SF")])
 
@@ -3617,6 +3629,9 @@ (define_insn_and_split "*avx_cmp3_ltint_not"
   operands[1] = force_reg (mode,
  gen_lowpart (mode, operands[1]));
   operands[2] = gen_lowpart (mode, operands[2]);
+
+  if (!MEM_P (operands[3]))
+operands[3] = force_reg (mode, operands[3]);
   operands[3] = lowpart_subreg (mode, operands[3], mode);
 })
 
@@ -6319,7 +6334,7 @@ (define_expand 
"_fmaddc__mask1"
(match_operand: 4 "register_operand")]
   "TARGET_AVX512FP16 && "
 {
-  rtx op0, op1;
+  rtx op0, op1, dest;
   if ()
 emit_insn (gen__fmaddc__mask (
   operands[0], operands[1], operands[2], operands[3],
@@ -6328,9 +6343,16 @@ (define_expand 
"_fmaddc__mask1"
 emit_insn (gen__fmaddc__mask (operands[0],
   operands[1], operands[2], operands[3], operands[4]));
 
-  op0 = lowpart_subreg (mode, operands[0], mode);
+  op0 = lowpart_subreg (mode,
+   force_reg (mode, operands[0]),
+   mode);
+  dest = gen_reg_rtx (mode);
+  if (!MEM_P (operands[1]))
+operands[1] = force_reg (mode, operands[1]);
   op1 = lowpart_subreg (mode, operands[1], mode);
-  emit_insn (gen__mask (op0, op0, op1, operands[4]));
+  emit_insn (gen__mask (dest, op0, op1, operands[4]));
+  emit_move_insn (operands[0],
+ lowpart_subreg (mode, dest, mode));
   DONE;
 })
 
@@ -6356,7 +6378,7 @@ (define_expand 
"_fcmaddc__mask1"
(match_operand: 4 "register_operand")]
   "TARGET_AVX512FP16 && "
 {
-  rtx op0, op1;
+  rtx op0, op1, dest;
   if ()
 emit_insn (gen__fcmaddc__mask (
   operands[0], operands[1], operands[2], operands[3],
@@ -6367,9 +6389,16 @@ (define_expand 
"_fc

Re: [PATCH] Fix ICE caused by NULL_RTX returned by lowpart_subreg.

2022-03-22 Thread Hongtao Liu via Gcc-patches
On Wed, Mar 23, 2022 at 2:05 PM liuhongt via Gcc-patches
 wrote:
>
> In validate_subreg, both (subreg:V2HF (reg:SI) 0)
> and (subreg:V8HF (reg:V2HF) 0) are valid, but not
> for (subreg:V8HF (reg:SI) 0) which causes ICE.
>
> Ideally it should be handled in validate_subreg to support
> subreg for all modes available in TARGET_CAN_CHANGE_MODE_CLASS, but
> that would be too risky in stage4, so the patch is a walkround in the
> backend to force_reg operands before lowpart_subreg for expanders or
> pre_reload splitters.
>
> Bootstrapped and regtest on x86_64-pc-linux-gnu{-m32,}.
> Also with native on SPR.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/104976
> * config/i386/sse.md (ssePSmodelower): New.
> (*avx_cmp3_ltint_not): Force_reg operand before
> lowpart_subreg to avoid NULL_RTX.
> (_fmaddc__mask1,
> _fcmaddc__mask1,
> fma__fmaddc_bcst, fma__fcmaddc_bcst,
> ___mask,
> avx512fp16_fcmaddcsh_v8hf_mask1,
> avx512fp16_fcmaddcsh_v8hf_mask3,
> avx512fp16_fmaddcsh_v8hf_mask3,
> avx512fp16_fmaddcsh_v8hf_mask3,
> floatv4hf2,
> floatv2div2hf2,
> fix_truncv4hf2,
> fix_truncv2hfv2di2, extendv4hf2,
> extendv2hfv2df2,
> truncv4hf2,truncv2dfv2hf2,
> *avx512bw_permvar_truncv16siv16hi_1,
> *avx512bw_permvar_truncv16siv16hi_1_hf,
> *avx512f_permvar_truncv8siv8hi_1,
> *avx512f_permvar_truncv8siv8hi_1_hf,
> *avx512f_vpermvar_truncv8div8si_1,
> *avx512f_permvar_truncv32hiv32qi_1,
> *avx512f_permvar_truncv16hiv16qi_1,
> *avx512f_permvar_truncv4div4si_1,
> *avx512f_pshufb_truncv8hiv8qi_1,
> *avx512f_pshufb_truncv4siv4hi_1,
> *avx512f_pshufd_truncv2div2si_1,
> sdot_prod, avx2_pblend_1,
> ashrv2di3,ashrv2di3,usdot_prod): Ditto.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr104976.c: New test.
> * gcc.target/i386/avx512fp16-vfcmaddcph-1a.c: Scan either
> vblendps or masked vmovaps.
> * gcc.target/i386/avx512fp16-vfmaddcph-1a.c: Ditto
> * gcc.target/i386/avx512fp16vl-vfcmaddcph-1a.c: Ditto.
> * gcc.target/i386/avx512fp16vl-vfmaddcph-1a.c: Ditto.
> ---
>  gcc/config/i386/sse.md| 236 +-
>  .../i386/avx512fp16-vfcmaddcph-1a.c   |   2 +-
>  .../gcc.target/i386/avx512fp16-vfmaddcph-1a.c |   2 +-
>  .../i386/avx512fp16vl-vfcmaddcph-1a.c |   4 +-
>  .../i386/avx512fp16vl-vfmaddcph-1a.c  |   4 +-
>  gcc/testsuite/gcc.target/i386/pr104976.c  |  13 +
>  6 files changed, 196 insertions(+), 65 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr104976.c
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 6f7af2f21d6..a9e18d38323 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -1059,6 +1059,18 @@ (define_mode_attr ssePSmode
> (V4DF "V8SF") (V2DF "V4SF")
> (V32HF "V16SF") (V16HF "V8SF") (V8HF "V4SF")])
>
> +(define_mode_attr ssePSmodelower
> +  [(V16SI "v16sf") (V8DF "v16sf")
> +   (V16SF "v16sf") (V8DI "v16sf")
> +   (V64QI "v16sf") (V32QI "v8sf") (V16QI "v4sf")
> +   (V32HI "v16sf") (V16HI "v8sf") (V8HI "v4sf")
> +   (V8SI "v8sf") (V4SI "v4sf")
> +   (V4DI "v8sf") (V2DI "v4sf")
> +   (V4TI "v16sf") (V2TI "v8sf") (V1TI "v4sf")
> +   (V8SF "v8sf") (V4SF "v4sf")
> +   (V4DF "v8sf") (V2DF "v4sf")
> +   (V32HF "v16sf") (V16HF "v8sf") (V8HF "v4sf")])
> +
>  (define_mode_attr ssePSmode2
>[(V8DI "V8SF") (V4DI "V4SF")])
>
> @@ -3617,6 +3629,9 @@ (define_insn_and_split "*avx_cmp3_ltint_not"
>operands[1] = force_reg (mode,
>   gen_lowpart (mode, operands[1]));
>operands[2] = gen_lowpart (mode, operands[2]);
> +
> +  if (!MEM_P (operands[3]))
> +operands[3] = force_reg (mode, operands[3]);
>operands[3] = lowpart_subreg (mode, operands[3], mode);
>  })
>
> @@ -6319,7 +6334,7 @@ (define_expand 
> "_fmaddc__mask1"
> (match_operand: 4 "register_operand")]
>"TARGET_AVX512FP16 && "
>  {
> -  rtx op0, op1;
> +  rtx op0, op1, dest;
>if ()
>  emit_insn (gen__fmaddc__mask (
>operands[0], operands[1], operands[2], operands[3],
> @@ -6328,9 +6343,16 @@ (define_expand 
> "_fmaddc__mask1"
>  emit_insn (gen__fmaddc__mask (operands[0],
>operands[1], operands[2], operands[3], operands[4]));
>
> -  op0 = lowpart_subreg (mode, operands[0], mode);
> +  op0 = lowpart_subreg (mode,
> +   force_reg (mode, operands[0]),
> +   mode);
> +  dest = gen_reg_rtx (mode);
> +  if (!MEM_P (operands[1]))
> +operands[1] = force_reg (mode, operands[1]);
>op1 = lowpart_subreg (mode, operands[1], mode);
> -  emit_insn (gen__mask (op0, op0, op1, operands[4]));
> +  emit_insn (gen__mask (dest, op0, op1, operands[4]));
> +  emit_move_insn (operands[0],
> + lowpart_subreg (mode, dest, mode));
>DONE;
>  })
>
> @@ -635

Re: [PATCH] Docs: Document that taint analyzer checker stops other checkers

2022-03-22 Thread Avinash Sonawane via Gcc-patches
On Tue, 22 Mar 2022 19:15:02 -0400
David Malcolm  wrote:

> So it would be even better if the text listed the warnings that are
> affected by this: basically all of the ones that are implemented in
> checkers i.e. analyzer/sm-*.cc (apart from sm-taint, of course).

Done! I could find 13 warnings in analyzer/sm-*.cc. Hope I didn't miss
any. :)

I also rearranged some flags to maintain the sort order.

Please find the attached v2 of the patch. Should I post another
fresh mail with subject line "[PATCH v2] Docs:..."? Or should've the
subject of this current thread been edited to "[PATCH v2]" from
"[PATCH]"?

Sorry for bothering. This is my first time submitting the patch on a
mailing list. :)

Thanks!

Regards,
Avinash Sonawane (rootKea)
https://www.rootkea.me


Re: [PATCH] Docs: Document that taint analyzer checker stops other checkers

2022-03-22 Thread Avinash Sonawane via Gcc-patches
Apologies! Forgot to attach the patch v2.

Done now.
>From 1d986ffd8b20007a6a2140e50935ade1bebc2228 Mon Sep 17 00:00:00 2001
From: Avinash Sonawane 
Date: Tue, 22 Mar 2022 07:32:44 +0530
Subject: [PATCH] Docs: Document that taint analyzer checker disables some
 warnings

---
 gcc/doc/invoke.texi | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4da4a1170f5..1d16f0f167f 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -421,14 +421,13 @@ Objective-C and Objective-C++ Dialects}.
 -fanalyzer-checker=@var{name} @gol
 -fno-analyzer-feasibility @gol
 -fanalyzer-fine-grained @gol
--fanalyzer-state-merge @gol
--fanalyzer-state-purge @gol
+-fno-analyzer-state-merge @gol
+-fno-analyzer-state-purge @gol
 -fanalyzer-transitivity @gol
 -fanalyzer-verbose-edges @gol
 -fanalyzer-verbose-state-changes @gol
 -fanalyzer-verbosity=@var{level} @gol
 -fdump-analyzer @gol
--fdump-analyzer-stderr @gol
 -fdump-analyzer-callgraph @gol
 -fdump-analyzer-exploded-graph @gol
 -fdump-analyzer-exploded-nodes @gol
@@ -438,6 +437,7 @@ Objective-C and Objective-C++ Dialects}.
 -fdump-analyzer-feasibility @gol
 -fdump-analyzer-json @gol
 -fdump-analyzer-state-purge @gol
+-fdump-analyzer-stderr @gol
 -fdump-analyzer-supergraph @gol
 -Wno-analyzer-double-fclose @gol
 -Wno-analyzer-double-free @gol
@@ -9659,22 +9659,24 @@ Enabling this option effectively enables the following warnings:
 -Wanalyzer-free-of-non-heap @gol
 -Wanalyzer-malloc-leak @gol
 -Wanalyzer-mismatching-deallocation @gol
--Wanalyzer-possible-null-argument @gol
--Wanalyzer-possible-null-dereference @gol
 -Wanalyzer-null-argument @gol
 -Wanalyzer-null-dereference @gol
+-Wanalyzer-possible-null-argument @gol
+-Wanalyzer-possible-null-dereference @gol
 -Wanalyzer-shift-count-negative @gol
 -Wanalyzer-shift-count-overflow @gol
 -Wanalyzer-stale-setjmp-buffer @gol
+@ignore
 -Wanalyzer-tainted-allocation-size @gol
 -Wanalyzer-tainted-array-index @gol
 -Wanalyzer-tainted-divisor @gol
 -Wanalyzer-tainted-offset @gol
 -Wanalyzer-tainted-size @gol
+@end ignore
 -Wanalyzer-unsafe-call-within-signal-handler @gol
 -Wanalyzer-use-after-free @gol
--Wanalyzer-use-of-uninitialized-value @gol
 -Wanalyzer-use-of-pointer-in-stale-stack-frame @gol
+-Wanalyzer-use-of-uninitialized-value @gol
 -Wanalyzer-write-to-const @gol
 -Wanalyzer-write-to-string-literal @gol
 }
@@ -10015,6 +10017,25 @@ such as the @code{taint} checker that implements
 @option{-Wanalyzer-tainted-array-index}, and this option is required
 to enable them.
 
+@emph{Note:} currently, @option{-fanalyzer-checker=taint} disables following
+warnings from @option{-fanalyzer}:
+
+@gccoptlist{ @gol
+-Wanalyzer-double-fclose @gol
+-Wanalyzer-double-free @gol
+-Wanalyzer-exposure-through-output-file @gol
+-Wanalyzer-file-leak @gol
+-Wanalyzer-free-of-non-heap @gol
+-Wanalyzer-malloc-leak @gol
+-Wanalyzer-mismatching-deallocation @gol
+-Wanalyzer-null-argument @gol
+-Wanalyzer-null-dereference @gol
+-Wanalyzer-possible-null-argument @gol
+-Wanalyzer-possible-null-dereference @gol
+-Wanalyzer-unsafe-call-within-signal-handler @gol
+-Wanalyzer-use-after-free @gol
+}
+
 @item -fno-analyzer-feasibility
 @opindex fanalyzer-feasibility
 @opindex fno-analyzer-feasibility
-- 
2.32.0