[PATCH] RISC-V: Fix bugs of ternary integer and floating-point ternary intrinsics.

[juzhe . zhong]

From: Ju-Zhe Zhong 

Fix bugs of ternary intrinsic pattern:

interger:
vnmsac.vv vd, vs1, vs2, vm# vd[i] = -(vs1[i] * vs2[i]) + vd[i]  (minus op3 
(mult op1 op2))
vnmsac.vx vd, rs1, vs2, vm# vd[i] = -(x[rs1] * vs2[i]) + vd[i]   (minus op3 
(mult op1 op2))

floating-point:
# FP multiply-accumulate, overwrites addend
vfmacc.vv vd, vs1, vs2, vm# vd[i] = +(vs1[i] * vs2[i]) + vd[i] (plus (mult 
(op1 op2)) op3)
vfmacc.vf vd, rs1, vs2, vm# vd[i] = +(f[rs1] * vs2[i]) + vd[i] (plus (mult 
(op1 op2)) op3)


# FP negate-(multiply-accumulate), overwrites subtrahend
vfnmacc.vv vd, vs1, vs2, vm   # vd[i] = -(vs1[i] * vs2[i]) - vd[i] (minus (neg 
(mult (op1 op2))) op3))
vfnmacc.vf vd, rs1, vs2, vm   # vd[i] = -(f[rs1] * vs2[i]) - vd[i] (minus (neg 
(mult (op1 op2)) op3))
# FP multiply-subtract-accumulator, overwrites subtrahend
vfmsac.vv vd, vs1, vs2, vm# vd[i] = +(vs1[i] * vs2[i]) - vd[i] (minus (mult 
(op1 op2)) op3)
vfmsac.vf vd, rs1, vs2, vm# vd[i] = +(f[rs1] * vs2[i]) - vd[i] (minus (mult 
(op1 op2)) op3)

# FP negate-(multiply-subtract-accumulator), overwrites minuend
vfnmsac.vv vd, vs1, vs2, vm   # vd[i] = -(vs1[i] * vs2[i]) + vd[i] (plus 
(neg:(mult (op1 op2))) op3)
vfnmsac.vf vd, rs1, vs2, vm   # vd[i] = -(f[rs1] * vs2[i]) + vd[i] (plus 
(neg:(mult (op1 op2))) op3)
gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc: Fix ternary bug.
* config/riscv/vector-iterators.md (nmsac): Ditto.
(nmsub): Ditto.
(msac): Ditto.
(msub): Ditto.
(nmadd): Ditto.
(nmacc): Ditto.
* config/riscv/vector.md (@pred_mul_): Ditto.
(@pred_mul_plus): Ditto.
(*pred_madd): Ditto.
(*pred_macc): Ditto.
(*pred_mul_plus): Ditto.
(@pred_mul_plus_scalar): Ditto.
(*pred_madd_scalar): Ditto.
(*pred_macc_scalar): Ditto.
(*pred_mul_plus_scalar): Ditto.
(*pred_madd_extended_scalar): Ditto.
(*pred_macc_extended_scalar): Ditto.
(*pred_mul_plus_extended_scalar): Ditto.
(@pred_minus_mul): Ditto.
(*pred_): Ditto.
(*pred_nmsub): Ditto.
(*pred_): Ditto.
(*pred_nmsac): Ditto.
(*pred_mul_): Ditto.
(*pred_minus_mul): Ditto.
(@pred_mul__scalar): Ditto.
(@pred_minus_mul_scalar): Ditto.
(*pred__scalar): Ditto.
(*pred_nmsub_scalar): Ditto.
(*pred__scalar): Ditto.
(*pred_nmsac_scalar): Ditto.
(*pred_mul__scalar): Ditto.
(*pred_minus_mul_scalar): Ditto.
(*pred__extended_scalar): Ditto.
(*pred_nmsub_extended_scalar): Ditto.
(*pred__extended_scalar): Ditto.
(*pred_nmsac_extended_scalar): Ditto.
(*pred_mul__extended_scalar): Ditto.
(*pred_minus_mul_extended_scalar): Ditto.
(*pred_): Ditto.
(*pred_): Ditto.
(*pred__scalar): Ditto.
(*pred__scalar): Ditto.
(@pred_neg_mul_): Ditto.
(@pred_mul_neg_): Ditto.
(*pred_): Ditto.
(*pred_): Ditto.
(*pred_): Ditto.
(*pred_): Ditto.
(*pred_neg_mul_): Ditto.
(*pred_mul_neg_): Ditto.
(@pred_neg_mul__scalar): Ditto.
(@pred_mul_neg__scalar): Ditto.
(*pred__scalar): Ditto.
(*pred__scalar): Ditto.
(*pred__scalar): Ditto.
(*pred__scalar): Ditto.
(*pred_neg_mul__scalar): Ditto.
(@pred_widen_neg_mul_): Ditto.
(@pred_widen_mul_neg_): Ditto.
(@pred_widen_neg_mul__scalar): Ditto.
(@pred_widen_mul_neg__scalar): Ditto.
 
---
 .../riscv/riscv-vector-builtins-bases.cc  |  80 +-
 gcc/config/riscv/vector-iterators.md  |   8 +-
 gcc/config/riscv/vector.md| 757 +-
 3 files changed, 609 insertions(+), 236 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 3f0f809c714..839eb66efb2 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -627,12 +627,11 @@ public:
   rtx expand (function_expander ) const override
   {
 if (e.op_info->op == OP_TYPE_vx)
-  return e.use_ternop_insn (true,
-   code_for_pred_mul_scalar (PLUS,
- e.vector_mode ()));
+  return e.use_ternop_insn (true, code_for_pred_mul_plus_scalar (
+   e.vector_mode ()));
 if (e.op_info->op == OP_TYPE_vv)
   return e.use_ternop_insn (true,
-   code_for_pred_mul (PLUS, e.vector_mode ()));
+   code_for_pred_mul_plus (e.vector_mode ()));
 gcc_unreachable ();
   }
 };
@@ -645,12 +644,11 @@ public:
   rtx expand (function_expander ) const override
   {
 if (e.op_info->op == OP_TYPE_vx)
-  return e.use_ternop_insn (true,
-   code_for_pred_mul_scalar (MINUS,

Re: [V4][PATCH 2/2] Update documentation to clarify a GCC extension

[Sandra Loosemore]

On 2/24/23 11:35, Qing Zhao via Gcc-patches wrote:


gcc/c-family/ChangeLog:

* c.opt: New option -Wgnu-variable-sized-type-not-at-end.

gcc/c/ChangeLog:

* c-decl.cc (finish_struct): Issue warnings for new option.

gcc/ChangeLog:

* doc/extend.texi: Document GCC extension on a structure containing
a flexible array member to be a member of another structure.

gcc/testsuite/ChangeLog:

* gcc.dg/variable-sized-type-flex-array.c: New test.


I'm only a documentation (and nios2) maintainer so I cannot approve 
adding a new option or warning.  I was going to review the documentation 
parts, at least, but I think this proposal is technically flawed because 
it is trying to document something that is undefined behavior in ways 
that it doesn't actually behave on all targets.



diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c1122916255..e278148c332 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1748,7 +1748,53 @@ Flexible array members may only appear as the last 
member of a
  A structure containing a flexible array member, or a union containing
  such a structure (possibly recursively), may not be a member of a
  structure or an element of an array.  (However, these uses are
-permitted by GCC as extensions.)
+permitted by GCC as extensions, see details below.)
+@end itemize
+
+GCC extension accepts a structure containing an ISO C99 @dfn{flexible array
+member}, or a union containing such a structure (possibly recursively)
+to be a member of a structure.
+
+There are two situations:
+
+@itemize @bullet
+@item
+The structure with a C99 flexible array member is the last field of another
+structure, for example:
+
+@smallexample
+struct flex  @{ int length; char data[]; @};
+union union_flex @{ int others; struct flex f; @};
+
+struct out_flex_struct @{ int m; struct flex flex_data; @};
+struct out_flex_union @{ int n; union union_flex flex_data; @};
+@end smallexample
+
+In the above, both @code{out_flex_struct.flex_data.data[]} and
+@code{out_flex_union.flex_data.f.data[]} are considered as flexible arrays too.
+
+
+@item
+The structure with a C99 flexible array member is the middle field of another
+structure, for example:
+
+@smallexample
+struct flex  @{ int length; char data[]; @};
+
+struct mid_flex @{ int m; struct flex flex_data; int n; @};
+@end smallexample
+
+In the above, @code{mid_flex.flex_data.data[]} is allowed to be extended
+flexibly to the padding.  E.g, up to 4 elements.


I think this paragraph is incorrect; how GCC lays out this structure 
depends on the target and ABI.  Looking at output from a GCC 12 
nios2-elf build I have handy, I see it is in fact laying out mid_flex so 
that member n is at the same address at offset 8 as flex_data.data[0], 
which is not useful at all.



+However, relying on space in struct padding is a bad programming practice,
+compilers do not handle such extension consistently, Any code relying on
+this behavior should be modified to ensure that flexible array members
+only end up at the ends of structures.
+
+Please use warning option  @option{-Wgnu-variable-sized-type-not-at-end} to
+identify all such cases in the source code and modify them.  This extension
+will be deprecated from gcc in the next release.


My suggestion would be to make this a hard error instead of a warning, 
unless there is some real body of code out there that depends on this 
feature on a target that actually does insert padding.  If it's a 
warning, it ought to be enabled by default.  And, rather than trying to 
document the behavior, the manual should just say it's undefined.


-Sandra

Re: Re: [PATCH] RISC-V: Fix Bug 109092

[juzhe.zh...@rivai.ai]

Yes, I have write access. However, I am new to commit patch to GCC trunk.
I didn't figure out how to commit patch to GCC trunk.
And I am afraid of producing a potential risk to GCC trunk during stage 4 in 
GCC 13.

So I am gonna learn to commit codes when GCC 14 is open.
And currently, I let Kito commit patch for me. 


juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-03-15 02:13
To: juzhe.zhong; gcc-patches
CC: kito.cheng
Subject: Re: [PATCH] RISC-V: Fix Bug 109092
 
 
On 3/13/23 08:17, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong 
> 
> This patch fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092.
> 
> gcc/ChangeLog:
> 
>  * config/riscv/riscv.md: Fix subreg bug.
LGTM.  Do you have write access now?  If so, go ahead and commit this patch.
 
Do you have any interest in fixing up a similar bug in peephole.md?
 
Jeff
 

Re: [Patch] More LLP64 fixes and __PIC__ values fixes for PE targets

[Jonathan Yong via Gcc-patches]

On 3/12/23 16:54, Jeff Law wrote:




Windows code is effectively always PIC, since the PE loader can 
relocate it anywhere if the preferred address is already occupied. 
Patch still OK?

Yes, still OK.  Just make the trivial ChangeLog adjustments.



Done, pushed to master branch, thanks.

[pushed] libstdc++: Fix template-head of repeat_view::_Iterator [PR109111]

[Patrick Palka via Gcc-patches]

Tested on x86_64-pc-linux-gnu, pushed to trunk as obvious.

-- >8 --

PR libstdc++/109111

libstdc++-v3/ChangeLog:

* include/std/ranges (repeat_view): Remove redundant parentheses
in requires-clause.
(repeat_view::_Iterator): Correct the requires-clause.
---
 libstdc++-v3/include/std/ranges | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 0725e700c47..b230ebefcf5 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -7407,8 +7407,8 @@ namespace views::__adaptor
 #define __cpp_lib_ranges_repeat 202207L
 
   template
-requires (is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>>
-  && (__detail::__is_integer_like<_Bound> || same_as<_Bound, 
unreachable_sentinel_t>))
+requires is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>>
+  && (__detail::__is_integer_like<_Bound> || same_as<_Bound, 
unreachable_sentinel_t>)
   class repeat_view : public view_interface>
   {
 __detail::__box<_Tp> _M_value;
@@ -7472,7 +7472,8 @@ namespace views::__adaptor
 repeat_view(_Tp, _Bound) -> repeat_view<_Tp, _Bound>;
 
   template
-requires __detail::__is_integer_like<_Bound> || same_as<_Bound, 
unreachable_sentinel_t>
+requires is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>>
+  && (__detail::__is_integer_like<_Bound> || same_as<_Bound, 
unreachable_sentinel_t>)
   class repeat_view<_Tp, _Bound>::_Iterator
   {
 using __index_type
-- 
2.40.0

Re: Re: [PATCH] RISC-V: Refine reduction RA constraint according to RVV ISA

[juzhe.zhong]

Since according to RVV ISA, "The destination vector register can overlap the 
source operands, including the mask register."
That means we can have vredsum.vs v0,v8,v9,v0.t. This patch is to refine the 
constraint to allow this happen that the current RA constraint doesn't allow.
Since you can see "vd" to match  "vm", vd doesn't include mask register (v0). 
This trivial optimization can allow our RA have 1 more register to allocate.
It's overall beneficial to the RA. 



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2023-03-15 02:05
To: juzhe.zhong; gcc-patches
CC: kito.cheng
Subject: Re: [PATCH] RISC-V: Refine reduction RA constraint according to RVV ISA
 
 
On 3/13/23 03:05, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong 
> 
> According to RVV ISA:
> 14. Vector Reduction Operations
> 
> "The destination vector register can overlap the source operands, including 
> the mask register."
> 
> gcc/ChangeLog:
> 
>  * config/riscv/vector.md: Refine RA constraint.
This feels like it ought to wait for gcc-14 as well.
 
One question though, why even bother with the matching constraint at all 
in these patterns?  ISTM it doesn't really accomplish anything. 
Removing it allows a single alternative to handle all the possibilities.
 
Jeff
 

[PATCH] sanitizer: missing signed integer overflow errors [PR109107]

[Marek Polacek via Gcc-patches]

Here we're failing to detect a signed overflow with -O because match.pd,
since r8-1516, transforms

  c = (a + 1) - (int) (short int) b;

into

  c = (int) ((unsigned int) a + 4294946117);

wrongly eliding the overflow.  This kind of problems is usually
avoided by using TYPE_OVERFLOW_SANITIZED in the appropriate place.
The first match.pd hunk in the patch fixes it.  I've constructed
a testcase for each of the surrounding cases as well.  Then I
noticed that fold_binary_loc/associate has the same problem, so I've
added a TYPE_OVERFLOW_SANITIZED there as well (it may be too coarse,
sorry).  Then I found yet another problem, but instead of fixing it
now I've opened 109134.  I could probably go on and find a dozen more.

Is this worth doing?

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

PR sanitizer/109107

gcc/ChangeLog:

* fold-const.cc (fold_binary_loc): Use TYPE_OVERFLOW_SANITIZED
when associating.
* match.pd: Use TYPE_OVERFLOW_SANITIZED.

gcc/testsuite/ChangeLog:

* c-c++-common/ubsan/pr109107-2.c: New test.
* c-c++-common/ubsan/pr109107-3.c: New test.
* c-c++-common/ubsan/pr109107-4.c: New test.
* c-c++-common/ubsan/pr109107.c: New test.
---
 gcc/fold-const.cc |  3 ++-
 gcc/match.pd  |  6 ++---
 gcc/testsuite/c-c++-common/ubsan/pr109107-2.c | 24 ++
 gcc/testsuite/c-c++-common/ubsan/pr109107-3.c | 25 +++
 gcc/testsuite/c-c++-common/ubsan/pr109107-4.c | 24 ++
 gcc/testsuite/c-c++-common/ubsan/pr109107.c   | 23 +
 6 files changed, 101 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/pr109107-2.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/pr109107-3.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/pr109107-4.c
 create mode 100644 gcc/testsuite/c-c++-common/ubsan/pr109107.c

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 02a24c5fe65..8d3308a34e9 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -11319,7 +11319,8 @@ fold_binary_loc (location_t loc, enum tree_code code, 
tree type,
 And, we need to make sure type is not saturating.  */
 
   if ((! FLOAT_TYPE_P (type) || flag_associative_math)
- && !TYPE_SATURATING (type))
+ && !TYPE_SATURATING (type)
+ && !TYPE_OVERFLOW_SANITIZED (type))
{
  tree var0, minus_var0, con0, minus_con0, lit0, minus_lit0;
  tree var1, minus_var1, con1, minus_con1, lit1, minus_lit1;
diff --git a/gcc/match.pd b/gcc/match.pd
index e352bd422f5..98bca9ea388 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2933,7 +2933,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* If the constant operation overflows we cannot do the transform
  directly as we would introduce undefined overflow, for example
  with (a - 1) + INT_MIN.  */
-   (if (types_match (type, @0))
+   (if (types_match (type, @0) && !TYPE_OVERFLOW_SANITIZED (type))
(with { tree cst = const_binop (outer_op == inner_op
? PLUS_EXPR : MINUS_EXPR,
type, @1, @2); }
@@ -2964,7 +2964,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (!ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
  || TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
   (view_convert (minus (outer_op @1 (view_convert @2)) @0))
-  (if (types_match (type, @0))
+  (if (types_match (type, @0) && !TYPE_OVERFLOW_SANITIZED (type))
(with { tree cst = const_binop (outer_op, type, @1, @2); }
(if (cst && !TREE_OVERFLOW (cst))
 (minus { cst; } @0
@@ -2983,7 +2983,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 (if (!ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
 || TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
  (view_convert (plus @0 (minus (view_convert @1) @2)))
- (if (types_match (type, @0))
+ (if (types_match (type, @0) && !TYPE_OVERFLOW_SANITIZED (type))
   (with { tree cst = const_binop (MINUS_EXPR, type, @1, @2); }
(if (cst && !TREE_OVERFLOW (cst))
(plus { cst; } @0)))
diff --git a/gcc/testsuite/c-c++-common/ubsan/pr109107-2.c 
b/gcc/testsuite/c-c++-common/ubsan/pr109107-2.c
new file mode 100644
index 000..eb440b58dd8
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ubsan/pr109107-2.c
@@ -0,0 +1,24 @@
+/* PR sanitizer/109107 */
+/* { dg-do run { target int32 } } */
+/* { dg-options "-fsanitize=signed-integer-overflow" } */
+
+#define INT_MIN (-__INT_MAX__ - 1)
+int a = INT_MIN;
+const int b = 676540;
+
+__attribute__((noipa)) int
+foo ()
+{
+  int c = a - 1 + (int) (short) b;
+  return c;
+}
+
+int
+main ()
+{
+  foo ();
+  return 0;
+}
+
+/* { dg-output "signed integer overflow: -2147483648 - 1 cannot be represented 
in type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*signed integer overflow: 2147483647 \\+ 21180 cannot 
be represented in type 'int'" } */

[pushed] c++: variable tmpl partial specialization [PR108468]

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

Generally we expect TPARMS_PRIMARY_TEMPLATE to be set, but sometimes it
isn't for partial instantiations.  This ought to be improved, but it's
trivial to work around it in this case.

PR c++/108468

gcc/cp/ChangeLog:

* pt.cc (unify_pack_expansion): Check that TPARMS_PRIMARY_TEMPLATE
is non-null.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/var-templ78.C: New test.
---
 gcc/cp/pt.cc |  2 ++
 gcc/testsuite/g++.dg/cpp1y/var-templ78.C | 12 
 2 files changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ78.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 65341c40f97..c53d8e279c6 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -24148,6 +24148,8 @@ unify_pack_expansion (tree tparms, tree targs, tree 
packed_parms,
 arguments if it is not otherwise deduced.  */
  if (cxx_dialect >= cxx20
  && TREE_VEC_LENGTH (new_args) < TREE_VEC_LENGTH (old_args)
+ /* FIXME This isn't set properly for partial instantiations.  */
+ && TPARMS_PRIMARY_TEMPLATE (tparms)
  && builtin_guide_p (TPARMS_PRIMARY_TEMPLATE (tparms)))
TREE_VEC_LENGTH (old_args) = TREE_VEC_LENGTH (new_args);
  if (!comp_template_args (old_args, new_args,
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ78.C 
b/gcc/testsuite/g++.dg/cpp1y/var-templ78.C
new file mode 100644
index 000..48366c92775
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ78.C
@@ -0,0 +1,12 @@
+// PR c++/108468
+// { dg-do compile { target c++14 } }
+
+template struct C {
+  template
+  static constexpr int x = 1;
+};
+
+template template
+int C::x = 2;
+
+int y = C<0>::x;

base-commit: 2b204accd07a3185b58b1edc6e9b019472857a5d
-- 
2.31.1

Re: [PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

[Sam James via Gcc-patches]

Kito Cheng  writes:

> committed to trunk, thanks :)
>
> On Tue, Mar 14, 2023 at 9:44 PM Kito Cheng  wrote:
>>
>> RISC-V part is ok, and I assume you didn't have write access so I'm
>> gonna push that since the system.h change also got approved :)

Thanks a bunch! :)

>>
>> On Tue, Mar 14, 2023 at 5:07 PM Richard Biener via Gcc-patches
>>  wrote:
>> >
>> > On Tue, Mar 14, 2023 at 1:24 AM Sam James via Gcc-patches
>> >  wrote:
>> > >
>> > > This fixes errors like:
>> > > ```
>> > > In file included from /usr/include/pthread.h:30,
>> > >  from 
>> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35,
>> > >  from 
>> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr.h:148,
>> > >  from 
>> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ext/atomicity.h:35,
>> > >  from 
>> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/bits/ios_base.h:39,
>> > >  from 
>> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ios:42,
>> > >  from 
>> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/istream:38,
>> > >  from 
>> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/sstream:38,
>> > >  from 
>> > > /var/tmp/portage/sys-devel/gcc-13.0.1_pre20230305/work/gcc-13-20230305/gcc/config/riscv/genrvv-type-indexer.cc:22:
>> > > /usr/include/sched.h:84:7: error: attempt to use poisoned "calloc"
>> > >84 | void *calloc(size_t, size_t);
>> > >   |   ^
>> > > /usr/include/sched.h:124:36: error: attempt to use poisoned "calloc"
>> > >   124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
>> > >   |^
>> > > make[3]: *** [Makefile:2855: build/genrvv-type-indexer.o] Error 1
>> > > ```
>> > >
>> > > See also 3b21c21f3f5726823e19728fdd1571a14aae0fb3 and 
>> > > 49d508065bdd36fb1a9b6aad9666b1edb5e06474,
>> > > which was fixed in PR106102.
>> >
>> > The system.h change is OK
>> >
>> > > gcc/ChangeLog:
>> > > * config/riscv/genrvv-type-indexer.cc: Avoid calloc() poisoning 
>> > > on musl by
>> > > including  earlier.
>> > > * system.h: Add INCLUDE_SSTREAM.
>> > >
>> > > Signed-off-by: Sam James 
>> > > ---
>> > >  gcc/config/riscv/genrvv-type-indexer.cc | 2 +-
>> > >  gcc/system.h| 4 
>> > >  2 files changed, 5 insertions(+), 1 deletion(-)
>> > >
>> > > diff --git a/gcc/config/riscv/genrvv-type-indexer.cc 
>> > > b/gcc/config/riscv/genrvv-type-indexer.cc
>> > > index 0ef1d766002..e677b55290c 100644
>> > > --- a/gcc/config/riscv/genrvv-type-indexer.cc
>> > > +++ b/gcc/config/riscv/genrvv-type-indexer.cc
>> > > @@ -14,12 +14,12 @@ along with GCC; see the file COPYING3.  If not see
>> > >  .  */
>> > >
>> > >  #include "bconfig.h"
>> > > +#define INCLUDE_SSTREAM
>> > >  #include "system.h"
>> > >  #include "errors.h"
>> > >
>> > >  #include "coretypes.h"
>> > >
>> > > -#include 
>> > >  #include 
>> > >  #include 
>> > >
>> > > diff --git a/gcc/system.h b/gcc/system.h
>> > > index 64cd5a49258..cf45db3f97e 100644
>> > > --- a/gcc/system.h
>> > > +++ b/gcc/system.h
>> > > @@ -751,6 +751,10 @@ extern int vsnprintf (char *, size_t, const char *, 
>> > > va_list);
>> > >  # include 
>> > >  #endif
>> > >
>> > > +#ifdef INCLUDE_SSTREAM
>> > > +# include 
>> > > +#endif
>> > > +
>> > >  #ifdef INCLUDE_MALLOC_H
>> > >  #if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
>> > >  #include 
>> > > --
>> > > 2.40.0
>> > >



signature.asc
Description: PGP signature

[PATCH] vect: Verify that GET_MODE_NUNITS is greater than one.

[Michael Collison]

While working on autovectorizing for the RISCV port I encountered an issue
where can_duplicate_and_interleave_p assumes that GET_MODE_NUNITS is a
evenly divisible by two. The RISC-V target has vector modes (e.g. VNx1DImode),
where GET_MODE_NUNITS is equal to one.

Tested on RISCV and x86_64-linux-gnu. Okay?

2023-03-09  Michael Collison  

* tree-vect-slp.cc (can_duplicate_and_interleave_p):
Check that GET_MODE_NUNITS is greater than one.
---
 gcc/tree-vect-slp.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 9a4e000925e..add58113fa8 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -426,7 +426,8 @@ can_duplicate_and_interleave_p (vec_info *vinfo, unsigned 
int count,
  if (vector_type
  && VECTOR_MODE_P (TYPE_MODE (vector_type))
  && known_eq (GET_MODE_SIZE (TYPE_MODE (vector_type)),
-  GET_MODE_SIZE (base_vector_mode)))
+  GET_MODE_SIZE (base_vector_mode))
+ && known_gt (GET_MODE_NUNITS (TYPE_MODE (vector_type)), 1))
{
  /* Try fusing consecutive sequences of COUNT / NVECTORS elements
 together into elements of type INT_TYPE and using the result
-- 
2.34.1

Re: [PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

[Sam James via Gcc-patches]

Kito Cheng  writes:

> RISC-V part is ok, and I assume you didn't have write access so I'm
> gonna push that since the system.h change also got approved :)
>
> On Tue, Mar 14, 2023 at 5:07 PM Richard Biener via Gcc-patches
>  wrote:
>>
>> On Tue, Mar 14, 2023 at 1:24 AM Sam James via Gcc-patches
>>  wrote:
>> >
>> > This fixes errors like:
>> > ```
>> > In file included from /usr/include/pthread.h:30,
>> >  from 
>> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35,
>> >  from 
>> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr.h:148,
>> >  from 
>> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ext/atomicity.h:35,
>> >  from 
>> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/bits/ios_base.h:39,
>> >  from 
>> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ios:42,
>> >  from 
>> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/istream:38,
>> >  from 
>> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/sstream:38,
>> >  from 
>> > /var/tmp/portage/sys-devel/gcc-13.0.1_pre20230305/work/gcc-13-20230305/gcc/config/riscv/genrvv-type-indexer.cc:22:
>> > /usr/include/sched.h:84:7: error: attempt to use poisoned "calloc"
>> >84 | void *calloc(size_t, size_t);
>> >   |   ^
>> > /usr/include/sched.h:124:36: error: attempt to use poisoned "calloc"
>> >   124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
>> >   |^
>> > make[3]: *** [Makefile:2855: build/genrvv-type-indexer.o] Error 1
>> > ```
>> >
>> > See also 3b21c21f3f5726823e19728fdd1571a14aae0fb3 and 
>> > 49d508065bdd36fb1a9b6aad9666b1edb5e06474,
>> > which was fixed in PR106102.
>>
>> The system.h change is OK

Thanks Richard. Are you able to commit this for me?

best,
sam

>>
>> > gcc/ChangeLog:
>> > * config/riscv/genrvv-type-indexer.cc: Avoid calloc() poisoning on 
>> > musl by
>> > including  earlier.
>> > * system.h: Add INCLUDE_SSTREAM.
>> >
>> > Signed-off-by: Sam James 
>> > ---
>> >  gcc/config/riscv/genrvv-type-indexer.cc | 2 +-
>> >  gcc/system.h| 4 
>> >  2 files changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/gcc/config/riscv/genrvv-type-indexer.cc 
>> > b/gcc/config/riscv/genrvv-type-indexer.cc
>> > index 0ef1d766002..e677b55290c 100644
>> > --- a/gcc/config/riscv/genrvv-type-indexer.cc
>> > +++ b/gcc/config/riscv/genrvv-type-indexer.cc
>> > @@ -14,12 +14,12 @@ along with GCC; see the file COPYING3.  If not see
>> >  .  */
>> >
>> >  #include "bconfig.h"
>> > +#define INCLUDE_SSTREAM
>> >  #include "system.h"
>> >  #include "errors.h"
>> >
>> >  #include "coretypes.h"
>> >
>> > -#include 
>> >  #include 
>> >  #include 
>> >
>> > diff --git a/gcc/system.h b/gcc/system.h
>> > index 64cd5a49258..cf45db3f97e 100644
>> > --- a/gcc/system.h
>> > +++ b/gcc/system.h
>> > @@ -751,6 +751,10 @@ extern int vsnprintf (char *, size_t, const char *, 
>> > va_list);
>> >  # include 
>> >  #endif
>> >
>> > +#ifdef INCLUDE_SSTREAM
>> > +# include 
>> > +#endif
>> > +
>> >  #ifdef INCLUDE_MALLOC_H
>> >  #if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
>> >  #include 
>> > --
>> > 2.40.0
>> >



signature.asc
Description: PGP signature

Re: [PATCH 2/2] c++: redeclaring member of constrained class template [PR96830]

[Jason Merrill via Gcc-patches]

On 3/14/23 12:41, Patrick Palka wrote:

When redeclaring a member of a constrained class template, we need to
repeat the class's constraints, but it turns out we don't verify
anywhere that the repeated constraints match the class's constraints.
A safe place to do so seems to be in push_template_decl, nearby a
similar consistency check for the template parameter list length of a
redeclaration.

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


Both patches are OK for trunk, but not 12; we tend not to backport fixes 
for accepts-invalid bugs, especially if they aren't regressions.  We 
don't want to add new diagnostics to an active release branch.



PR c++/96830

gcc/cp/ChangeLog:

* pt.cc (push_inline_template_parms_recursive): Set
TEMPLATE_PARMS_CONSTRAINTS.
(push_template_decl): For a redeclaration, verify constraints
for each enclosing template scope match those of the original
template declaratation.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-class5.C: New test.
* g++.dg/cpp2a/concepts-class5a.C: New test.
---
  gcc/cp/pt.cc  | 26 +
  gcc/testsuite/g++.dg/cpp2a/concepts-class5.C  | 37 ++
  gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C | 38 +++
  3 files changed, 101 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-class5.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 053cc52b285..370a4f70f08 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -471,6 +471,8 @@ push_inline_template_parms_recursive (tree parmlist, int 
levels)
current_template_parms
  = tree_cons (size_int (current_template_depth + 1),
 parms, current_template_parms);
+  TEMPLATE_PARMS_CONSTRAINTS (current_template_parms)
+= TEMPLATE_PARMS_CONSTRAINTS (parmlist);
TEMPLATE_PARMS_FOR_INLINE (current_template_parms) = 1;
  
begin_scope (TREE_VEC_LENGTH (parms) ? sk_template_parms : sk_template_spec,

@@ -6134,6 +6136,30 @@ push_template_decl (tree decl, bool is_friend)
  DECL_INTERFACE_KNOWN (decl) = 1;
  return error_mark_node;
}
+
+  /* Check that the constraints for each enclosing template scope are
+consistent with the original template declaration.  */
+  if (flag_concepts)
+   {
+ tree decl_parms = DECL_TEMPLATE_PARMS (tmpl);
+ tree scope_parms = current_template_parms;
+ if (PRIMARY_TEMPLATE_P (tmpl))
+   {
+ decl_parms = TREE_CHAIN (decl_parms);
+ scope_parms = TREE_CHAIN (scope_parms);
+   }
+ while (decl_parms)
+   {
+ if (!template_requirements_equivalent_p (decl_parms, scope_parms))
+   {
+ error ("redeclaration of %qD with different constraints",
+TPARMS_PRIMARY_TEMPLATE (TREE_VALUE (decl_parms)));
+ break;
+   }
+ decl_parms = TREE_CHAIN (decl_parms);
+ scope_parms = TREE_CHAIN (scope_parms);
+   }
+   }
  }
  
gcc_checking_assert (!tmpl || DECL_TEMPLATE_RESULT (tmpl) == decl);

diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-class5.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-class5.C
new file mode 100644
index 000..5d893d9f6a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-class5.C
@@ -0,0 +1,37 @@
+// PR c++/96830
+// { dg-do compile { target c++20 } }
+
+template concept C = true;
+
+template requires true
+struct A {
+  void f();
+  template void g();
+
+  struct B;
+  template struct C;
+
+  static int D;
+  template static int E;
+};
+
+template
+void A::f() { }  // { dg-error "different constraints" }
+
+template requires true
+template
+void A::g() { }  // { dg-error "different constraints" }
+
+template requires (!!true)
+struct A::B { }; // { dg-error "different constraints" }
+
+template requires true
+template
+struct A::C { }; // { dg-error "different constraints" }
+
+template
+int A::D = 0;// { dg-error "different constraints" }
+
+template requires true
+template
+int A::E = 0;// { dg-error "different constraints" }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C
new file mode 100644
index 000..a6a3684c258
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C
@@ -0,0 +1,38 @@
+// PR c++/96830
+// A valid version of concepts-class5.C.
+// { dg-do compile { target c++20 } }
+
+template concept C = true;
+
+template requires true
+struct A {
+  void f();
+  template void g();
+
+  struct B;
+  template struct C;
+
+  static int D;
+  template static int E;
+};
+
+template requires true
+void A::f() { }
+
+template requires true
+template
+void A::g() { }
+
+template requires true
+struct A::B { };
+
+template requires true
+template
+struct A::C { };
+

RE: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build

[Eugene Rozenfeld via Gcc-patches]

Hi Jeff,

I revived profile_merger tool in http://github.com/google/autofdo and re-worked 
the patch to merge profiles for compiling the libraries.

Please take a look at the attached patch.

Thanks,

Eugene

-Original Message-
From: Jeff Law  
Sent: Tuesday, November 22, 2022 10:16 PM
To: Eugene Rozenfeld ; gcc-patches@gcc.gnu.org; 
Andi Kleen 
Subject: Re: [EXTERNAL] Re: [PATCH] Fix autoprofiledbootstrap build

[You don't often get email from jeffreya...@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

On 11/22/22 14:20, Eugene Rozenfeld wrote:
> I took another look at this. We actually collect perf data when building the 
> libraries. So, we have ./prev-gcc/perf.data, ./prev-libcpp/perf.data, 
> ./prev-libiberty/perf.data, etc. But when creating gcov data for  
> -fauto-profile build of cc1plus or cc1 we only use ./prev-gcc/perf.data . So, 
> a better solution would be either having a single perf.data for all builds 
> (gcc and libraries) or merging perf.data files before attempting 
> autostagefeedback. What would you recommend?

ISTM that if neither approach loses data, then they're functionally equivalent 
-- meaning that we can select whichever is easier to wire into our build system.

A single perf.data might serialize the build.  So perhaps separate, then merge 
right before autostagefeedback.


But I'm willing to go with whatever you think is best.

Jeff




0001-Fix-autoprofiledbootstrap-build.patch
Description: 0001-Fix-autoprofiledbootstrap-build.patch

[committed] d: Fix undefined reference to lambda defined in private enum [PR109108]

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes linker error as described in PR d/109108.

Previously lambdas were connected to the module they were defined in.
Now they are emitted into every referencing compilation unit, and are
given one-only linkage.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32,
committed to mainline, and backported to releases/gcc-11 and gcc-12.

Regards,
Iain.

---
PR d/109108

gcc/d/ChangeLog:

* decl.cc (function_defined_in_root_p): Remove.
(get_symbol_decl): Set DECL_LAMBDA_FUNCTION_P on function literals.
(start_function): Unconditionally unset DECL_EXTERNAL
(set_linkage_for_decl): Give lambda functions one-only linkage.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/imports/pr109108.d: New test.
* gdc.dg/torture/pr109108.d: New test.
---
 gcc/d/decl.cc | 41 ++-
 .../gdc.dg/torture/imports/pr109108.d | 11 +
 gcc/testsuite/gdc.dg/torture/pr109108.d   | 10 +
 3 files changed, 34 insertions(+), 28 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/torture/imports/pr109108.d
 create mode 100644 gcc/testsuite/gdc.dg/torture/pr109108.d

diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index c451805639d..4fbabd59998 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -1090,25 +1090,6 @@ build_decl_tree (Dsymbol *d)
   input_location = saved_location;
 }
 
-/* Returns true if function FD, or any lexically enclosing scope function of FD
-   is defined or instantiated in a root module.  */
-
-static bool
-function_defined_in_root_p (FuncDeclaration *fd)
-{
-  Module *md = fd->getModule ();
-  if (md && md->isRoot ())
-return true;
-
-  for (TemplateInstance *ti = fd->isInstantiated (); ti != NULL; ti = 
ti->tinst)
-{
-  if (ti->minst && ti->minst->isRoot ())
-   return true;
-}
-
-  return false;
-}
-
 /* Returns true if function FD always needs to be implicitly defined, such as
it was declared `pragma(inline)'.  */
 
@@ -1474,6 +1455,12 @@ get_symbol_decl (Declaration *decl)
  DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (decl->csym) = 1;
}
 
+  /* In [expression/function_literals], function literals (aka lambdas)
+enable embedding anonymous functions and anonymous delegates directly
+into expressions.  They are defined in each referencing module.  */
+  if (fd->isFuncLiteralDeclaration ())
+   DECL_SET_LAMBDA_FUNCTION (decl->csym, true);
+
   /* Mark compiler generated functions as artificial.  */
   if (fd->isGenerated ())
DECL_ARTIFICIAL (decl->csym) = 1;
@@ -2029,12 +2016,9 @@ start_function (FuncDeclaration *fd)
 {
   tree fndecl = get_symbol_decl (fd);
 
-  /* Function has been defined, check now whether we intend to send it to
- object file, or it really is extern.  Such as inlinable functions from
- modules not in this compilation, or thunk aliases.  */
-  if (function_defined_in_root_p (fd))
-DECL_EXTERNAL (fndecl) = 0;
-
+  /* Function has been defined. Whether we intend to send it to object file, or
+ discard it has already been determined by set_linkage_for_decl.  */
+  DECL_EXTERNAL (fndecl) = 0;
   DECL_INITIAL (fndecl) = error_mark_node;
 
   /* Add this decl to the current binding level.  */
@@ -2550,9 +2534,10 @@ set_linkage_for_decl (tree decl)
   if (!TREE_PUBLIC (decl))
 return;
 
-  /* Functions declared as `pragma(inline, true)' can appear in multiple
- translation units.  */
-  if (TREE_CODE (decl) == FUNCTION_DECL && DECL_DECLARED_INLINE_P (decl))
+  /* Function literals and functions declared as `pragma(inline, true)' can
+ appear in multiple translation units.  */
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  && (DECL_DECLARED_INLINE_P (decl) || DECL_LAMBDA_FUNCTION_P (decl)))
 return d_comdat_linkage (decl);
 
   /* Don't need to give private or protected symbols a special linkage.  */
diff --git a/gcc/testsuite/gdc.dg/torture/imports/pr109108.d 
b/gcc/testsuite/gdc.dg/torture/imports/pr109108.d
new file mode 100644
index 000..cec5274098c
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/torture/imports/pr109108.d
@@ -0,0 +1,11 @@
+module imports.pr109108;
+private enum int function(ref int)[] funs =
+[
+0: (ref idx) => 0,
+1: (ref idx) => 1,
+];
+
+int test109108(I)(I idx)
+{
+return funs[idx](idx);
+}
diff --git a/gcc/testsuite/gdc.dg/torture/pr109108.d 
b/gcc/testsuite/gdc.dg/torture/pr109108.d
new file mode 100644
index 000..4a428bf85a6
--- /dev/null
+++ b/gcc/testsuite/gdc.dg/torture/pr109108.d
@@ -0,0 +1,10 @@
+// { dg-additional-files "imports/pr109108.d" }
+// { dg-additional-options "-I[srcdir] -fno-moduleinfo" }
+// { dg-do link }
+// { dg-skip-if "needs gcc/config.d" { ! d_runtime } }
+import imports.pr109108;
+
+extern(C) int main()
+{
+return test109108(0);
+}
-- 
2.37.2

[PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331]

[Harald Anlauf via Gcc-patches]

Dear all,

the attached patch, which is based on a draft by Tobias, fixes
an old rejects-valid issue with rank checking for CLASS arrays
by using the proper array spec of CLASS variables.

The testcase covers only non-coarray cases, as playing with
coarray variants hit pre-exisiting issues in gfortran that
are very likely unrelated to the interface checks.  I consider
this rather as post 13-release stuff.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald

From 4453686ae4e70c14a0898c6687db912fa84ece9f Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 14 Mar 2023 20:23:06 +0100
Subject: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and
 CLASS [PR58331]

gcc/fortran/ChangeLog:

	PR fortran/58331
	* interface.cc (compare_parameter): Adjust check of array dummy
	arguments to handle the case of CLASS variables.

gcc/testsuite/ChangeLog:

	PR fortran/58331
	* gfortran.dg/class_dummy_10.f90: New test.

Co-authored-by: Tobias Burnus 
---
 gcc/fortran/interface.cc | 27 +++---
 gcc/testsuite/gfortran.dg/class_dummy_10.f90 | 56 
 2 files changed, 76 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/class_dummy_10.f90

diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index dafe41753b7..1d0f8bb5915 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2349,6 +2349,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   char err[200];
   gfc_component *ppc;
   bool codimension = false;
+  gfc_array_spec *formal_as;

   /* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
  procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -2540,6 +2541,9 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   return false;
 }

+  formal_as = formal->ts.type == BT_CLASS ? CLASS_DATA (formal)->as
+	  : formal->as;
+
   if (codimension && formal->attr.allocatable)
 {
   gfc_ref *last = NULL;
@@ -2650,10 +2654,10 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   if (symbol_rank (formal) == actual->rank || symbol_rank (formal) == -1)
 return true;

-  rank_check = where != NULL && !is_elemental && formal->as
-	   && (formal->as->type == AS_ASSUMED_SHAPE
-		   || formal->as->type == AS_DEFERRED)
-	   && actual->expr_type != EXPR_NULL;
+  rank_check = where != NULL && !is_elemental && formal_as
+&& (formal_as->type == AS_ASSUMED_SHAPE
+	|| formal_as->type == AS_DEFERRED)
+&& actual->expr_type != EXPR_NULL;

   /* Skip rank checks for NO_ARG_CHECK.  */
   if (formal->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
@@ -2662,14 +2666,20 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
   /* Scalar & coindexed, see: F2008, Section 12.5.2.4.  */
   if (rank_check || ranks_must_agree
   || (formal->attr.pointer && actual->expr_type != EXPR_NULL)
-  || (actual->rank != 0 && !(is_elemental || formal->attr.dimension))
+  || (actual->rank != 0
+	  && !(is_elemental || formal->attr.dimension
+	   || (formal->ts.type == BT_CLASS
+		   && CLASS_DATA (formal)->attr.dimension)))
   || (actual->rank == 0
 	  && ((formal->ts.type == BT_CLASS
 	   && CLASS_DATA (formal)->as->type == AS_ASSUMED_SHAPE)
 	  || (formal->ts.type != BT_CLASS
 		   && formal->as->type == AS_ASSUMED_SHAPE))
 	  && actual->expr_type != EXPR_NULL)
-  || (actual->rank == 0 && formal->attr.dimension
+  || (actual->rank == 0
+	  && (formal->attr.dimension
+	  || (formal->ts.type == BT_CLASS
+		  && CLASS_DATA (formal)->attr.dimension))
 	  && gfc_is_coindexed (actual))
   /* Assumed-rank actual argument; F2018 C838.  */
   || actual->rank == -1)
@@ -2690,7 +2700,10 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
 	}
   return false;
 }
-  else if (actual->rank != 0 && (is_elemental || formal->attr.dimension))
+  else if (actual->rank != 0
+	   && (is_elemental || formal->attr.dimension
+	   || (formal->ts.type == BT_CLASS
+		   && CLASS_DATA (formal)->attr.dimension)))
 return true;

   /* At this point, we are considering a scalar passed to an array.   This
diff --git a/gcc/testsuite/gfortran.dg/class_dummy_10.f90 b/gcc/testsuite/gfortran.dg/class_dummy_10.f90
new file mode 100644
index 000..cee5d4d82b2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_dummy_10.f90
@@ -0,0 +1,56 @@
+! { dg-do compile }
+! PR fortran/58331 - rank checking for CLASS dummy arguments
+
+module mymod
+  implicit none
+contains
+  subroutine mysub(a, n)
+integer,  intent(in) :: n
+class(*), intent(in) :: a(n)
+
+select type(a)
+type is(integer)
+   print *,'a is integer'
+   print *, "n=", n, '  a=', a
+class default
+   print *,'a is unsupported type'
+   stop 1
+end select
+  end
+
+  ! Assumed rank
+  subroutine sub_ar (a)
+class(*), intent(in) :: a(..)
+print *, rank (a), size (a), ":", shape (a)
+  end
+
+  ! 

[pushed] c++: -Wreturn-type with if (true) throw [PR107310]

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

I removed this folding in GCC 12 because it was interfering with an
experiment of richi's, but that never went in and the change causes
regressions, so let's put it back.

This reverts commit r12-5638-ga3e75c1491cd2d.

PR c++/107310

gcc/cp/ChangeLog:

* cp-gimplify.cc (genericize_if_stmt): Restore folding
of constant conditions.

gcc/testsuite/ChangeLog:

* c-c++-common/Wimplicit-fallthrough-39.c: Adjust warning.
* g++.dg/warn/Wreturn-6.C: New test.
---
 gcc/cp/cp-gimplify.cc|  6 ++
 .../c-c++-common/Wimplicit-fallthrough-39.c  |  4 ++--
 gcc/testsuite/g++.dg/warn/Wreturn-6.C| 16 
 3 files changed, 24 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wreturn-6.C

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index b995b4f81a5..4fecd5616bd 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -190,6 +190,12 @@ genericize_if_stmt (tree *stmt_p)
 }
   else if (IF_STMT_CONSTEXPR_P (stmt))
 stmt = integer_nonzerop (cond) ? then_ : else_;
+  /* ??? This optimization doesn't seem to belong here, but removing it
+ causes -Wreturn-type regressions (e.g. 107310).  */
+  else if (integer_nonzerop (cond) && !TREE_SIDE_EFFECTS (else_))
+stmt = then_;
+  else if (integer_zerop (cond) && !TREE_SIDE_EFFECTS (then_))
+stmt = else_;
   else
 stmt = build3 (COND_EXPR, void_type_node, cond, then_, else_);
   protected_set_expr_location_if_unset (stmt, locus);
diff --git a/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-39.c 
b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-39.c
index da4aef3a318..d06bc0db5ec 100644
--- a/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-39.c
+++ b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-39.c
@@ -37,8 +37,8 @@ fn2 (int n)
   switch (n)
 {
 case 0:
-  if (1) /* { dg-warning "statement may fall through" "" { target c++ 
} } */
-   n++;  /* { dg-warning "statement may fall through" "" { 
target c } } */
+  if (1)
+   n++;  /* { dg-warning "statement may fall through" } */
 case 1:  /* { dg-message "here" } */
   return -1;
 }
diff --git a/gcc/testsuite/g++.dg/warn/Wreturn-6.C 
b/gcc/testsuite/g++.dg/warn/Wreturn-6.C
new file mode 100644
index 000..85fef0e16df
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wreturn-6.C
@@ -0,0 +1,16 @@
+// PR c++/107310
+
+struct f
+{
+  ~f();
+};
+
+int foo(int t) {
+  f g;
+  switch (t) {
+  case 1:
+return 1;
+  }
+  if (true)
+throw 1;
+} // { dg-bogus "control reaches end" }

base-commit: 42630fadbe248717859d61c0244c821c32b4e52c
-- 
2.31.1

Re: [PATCH] RISC-V: Fix Bug 109092

[Jeff Law via Gcc-patches]

On 3/13/23 08:17, juzhe.zh...@rivai.ai wrote:

From: Ju-Zhe Zhong 

This patch fix bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092.

gcc/ChangeLog:

 * config/riscv/riscv.md: Fix subreg bug.

LGTM.  Do you have write access now?  If so, go ahead and commit this patch.

Do you have any interest in fixing up a similar bug in peephole.md?

Jeff

Re: [PATCH] RISC-V: Fine tune gather load RA constraint

[Jeff Law via Gcc-patches]

On 3/13/23 02:28, juzhe.zh...@rivai.ai wrote:

From: Ju-Zhe Zhong 

For DEST EEW < SOURCE EEW, we can partial overlap register
according to RVV ISA.

gcc/ChangeLog:

 * config/riscv/vector.md: Fix RA constraint.

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/rvv/base/narrow_constraint-12.c: New test.

Similarly.  I think this can wait for gcc-14.

jeff

Re: [PATCH] RISC-V: Refine reduction RA constraint according to RVV ISA

[Jeff Law via Gcc-patches]

On 3/13/23 03:05, juzhe.zh...@rivai.ai wrote:

From: Ju-Zhe Zhong 

According to RVV ISA:
14. Vector Reduction Operations

"The destination vector register can overlap the source operands, including the mask 
register."

gcc/ChangeLog:

 * config/riscv/vector.md: Refine RA constraint.

This feels like it ought to wait for gcc-14 as well.

One question though, why even bother with the matching constraint at all 
in these patterns?  ISTM it doesn't really accomplish anything. 
Removing it allows a single alternative to handle all the possibilities.


Jeff

Re: [PATCH] RISC-V: Fix reg order of RVV registers.

[Jeff Law via Gcc-patches]

On 3/13/23 02:19, juzhe.zh...@rivai.ai wrote:

From: Ju-Zhe Zhong 

Co-authored-by: kito-cheng 
Co-authored-by: kito-cheng 

Consider this case:
void f19 (void *base,void *base2,void *out,size_t vl, int n)
{
 vuint64m8_t bindex = __riscv_vle64_v_u64m8 (base + 100, vl);
 for (int i = 0; i < n; i++){
   vbool8_t m = __riscv_vlm_v_b8 (base + i, vl);
   vuint64m8_t v = __riscv_vluxei64_v_u64m8_m(m,base,bindex,vl);
   vuint64m8_t v2 = __riscv_vle64_v_u64m8_tu (v, base2 + i, vl);
   vint8m1_t v3 = __riscv_vluxei64_v_i8m1_m(m,base,v,vl);
   vint8m1_t v4 = __riscv_vluxei64_v_i8m1_m(m,base,v2,vl);
   __riscv_vse8_v_i8m1 (out + 100*i,v3,vl);
   __riscv_vse8_v_i8m1 (out + 222*i,v4,vl);
 }
}

Due to the current unreasonable reg order, this case produce unnecessary
register spillings.

Fix the order can help for RA.

Signed-off-by: Ju-Zhe Zhong 
Co-authored-by: kito-cheng 
Co-authored-by: kito-cheng 

gcc/ChangeLog:

 * config/riscv/riscv.h (enum reg_class): Fix reg order.

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/rvv/base/spill-1.c: Adapt test.
 * gcc.target/riscv/rvv/base/spill-2.c: Ditto.
 * gcc.target/riscv/rvv/base/spill-3.c: Ditto.
 * gcc.target/riscv/rvv/base/spill-4.c: Ditto.
 * gcc.target/riscv/rvv/base/spill-5.c: Ditto.
 * gcc.target/riscv/rvv/base/spill-6.c: Ditto.
 * gcc.target/riscv/rvv/base/spill-7.c: Ditto.

Are you OK with deferring this to gcc-14?

jeff

Re: [PATCH v6] RISC-V: Add support for experimental zfa extension.

[Jeff Law via Gcc-patches]

On 3/10/23 05:40, Jin Ma via Gcc-patches wrote:

This patch adds the 'Zfa' extension for riscv, which is based on:
  
https://github.com/riscv/riscv-isa-manual/commit/d74d99e22d5f68832f70982d867614e2149a3bd7
latest 'Zfa' change on the master branch of the RISC-V ISA Manual as
of this writing.

The Wiki Page (details):
  https://github.com/a4lg/binutils-gdb/wiki/riscv_zfa

The binutils-gdb for 'Zfa' extension:
  https://sourceware.org/pipermail/binutils/2022-September/122938.html

Implementation of zfa extension on LLVM:
   https://reviews.llvm.org/rGc0947dc44109252fcc0f68a542fc6ef250d4d3a9

There are three points that need to be discussed here.
1. According to riscv-spec, "The FCVTMO D.W.D instruction was added principally 
to
   accelerate the processing of JavaScript Numbers.", so it seems that no 
implementation
   is required in the compiler.
2. The FROUND and FROUNDN instructions in this patch use related functions in 
the math
   library, such as round, floor, ceil, etc. Since there is no interface for 
half-precision in
   the math library, the instructions FROUN D.H and FROUNDN X.H have not been 
implemented for
   the time being. Is it necessary to add a built-in interface belonging to 
riscv such as
  __builtin_roundhf or __builtin_roundf16 to generate half floating point 
instructions?
3. As far as I know, FMINM and FMAXM instructions correspond to C23 library 
function fminimum
   and fmaximum. Therefore, I have not dealt with such instructions for the 
time being, but have
   simply implemented the pattern of fminm3 and fmaxm3. Is 
it necessary to
   add a built-in interface belonging to riscv such as__builtin_fminm to 
generate half
   floating-point instructions?

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: Add zfa extension.
* config/riscv/constraints.md (Zf): Constrain the floating point number 
that the FLI instruction can load.
* config/riscv/iterators.md (round_pattern): New.
* config/riscv/predicates.md: Predicate the floating point number that 
the FLI instruction can load.
* config/riscv/riscv-opts.h (MASK_ZFA): New.
(TARGET_ZFA): New.
* config/riscv/riscv-protos.h (riscv_float_const_rtx_index_for_fli): 
Get the index of the
   floating-point number that the FLI instruction can load.
* config/riscv/riscv.cc (find_index_in_array): New.
(riscv_float_const_rtx_index_for_fli): New.
(riscv_cannot_force_const_mem): Likewise.
(riscv_const_insns): Likewise.
(riscv_legitimize_const_move): Likewise.
(riscv_split_64bit_move_p): Exclude floating point numbers that can be 
loaded by FLI instructions.
(riscv_output_move): Likewise.
(riscv_memmodel_needs_release_fence): Likewise.
(riscv_print_operand): Likewise.
(riscv_secondary_memory_needed): Likewise.
* config/riscv/riscv.h (GP_REG_RTX_P): New.
* config/riscv/riscv.md (fminm3): New.
(fmaxm3): New.
(2): New.
(rint2): New.
(f_quiet4_zfa): New.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zfa-fleq-fltq-rv32.c: New test.
* gcc.target/riscv/zfa-fleq-fltq.c: New test.
* gcc.target/riscv/zfa-fli-rv32.c: New test.
* gcc.target/riscv/zfa-fli-zfh-rv32.c: New test.
* gcc.target/riscv/zfa-fli-zfh.c: New test.
* gcc.target/riscv/zfa-fli.c: New test.
* gcc.target/riscv/zfa-fmovh-fmovp-rv32.c: New test.
* gcc.target/riscv/zfa-fround-rv32.c: New test.
* gcc.target/riscv/zfa-fround.c: New test.

This needs to wait for gcc-14 IMHO.

jeff

Re: [PATCH] RISC-V: Fine tune RA constraint for narrow instructions

[Jeff Law via Gcc-patches]

On 3/9/23 20:02, juzhe.zh...@rivai.ai wrote:

From: Ju-Zhe Zhong 

According to RVV ISA, for narrow instructions:

The destination EEW is smaller than the source EEW and the overlap is
in the lowest-numbered part of the source register group.
(e.g., when LMUL=1, vnsrl.wi v0, v0, 3 is legal, but a destination of v1 is 
not).

We should allow narrow instructions partially overlap base on the rule of RVV 
ISA above
so that we could exploit the useage of vector registers.

Consider these cases:
https://godbolt.org/z/o6sc4eqGj

some cases in LLVM have redundant move instructions,
some cases in LLVM have redundant register spillings.

Now after this patch, GCC can have perfect RA && codegen for different pressure 
RA cases.

gcc/ChangeLog:

 * config/riscv/vector.md: Fine tune RA constraints.

gcc/testsuite/ChangeLog:

 * gcc.target/riscv/rvv/base/narrow_constraint-1.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-10.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-11.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-2.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-3.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-4.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-5.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-6.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-7.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-8.c: New test.
 * gcc.target/riscv/rvv/base/narrow_constraint-9.c: New test.
ISTM this should wait for gcc-14.  Yea, the risk is low and limited to 
RVV, but it seems to fall outside the basic intrinsic support we agreed 
to allow into gcc-13 post-feature-freeze.


Comments?
Jeff

Re: [PATCH] vect: Check that vector factor is a compile-time constant

[Jeff Law via Gcc-patches]

On 2/23/23 21:04, Kito Cheng wrote:

Hi Jeff:


What I'd been planning to do internally at Ventana was to update our
codebase to gcc-13 once it's released.  Then I'd backport RVV autovec
work from the gcc-14 dev tree into that Ventana branch.

Instead, but along the same lines, we could have a public gcc-13 based
branch which follows that same process and where Rivos, SiFive, Rivai,
Ventana (and potentially others with an interest in this space) could
collaborate.  Essentially it'd be gcc-13 + RVV autovec support.  We'd
probably have to hash out a bit of policy with the shared branch, but
I'd like to think we could make it work.


+1, I like the idea, I could imagine we definitely will do the same
work more than four times by different companies if we don't have a
collaboration branch...
So it looks like there's a general sense that a coordination branch off 
gcc-13 is reasonable.  So I'd like to hammer out a few details.



First, I recommend we cut a branch from gcc-13 soon after gcc-13 
branches.  That way we've got a place to land the vector work.


Second, I recommend we rebase that branch periodically so that it 
follows gcc-13.  That means downstream consumers may have non-ff pulls, 
but I think we want to follow gcc-13 fairly closely.  I'm open to other 
approaches here.


Third, I was thinking that once a patch related to risc-v vectorization 
goes to the trunk, any one of the principals should be able to 
cherry-pick that patch onto our branch.


That implies we need to identify the principals.  I'll suggest Kito, 
Juzhe, Michael and myself as the initial list.  I'm certainly open to 
others joining.



Other thoughts or suggestions?

Jeff

[PATCH] i386: Use movss to implement V2SImode VEC_PERM.

[Uros Bizjak via Gcc-patches]

Perform V2SI vector permutation in the same way as existing V2SF for
TARGET_MMX_WITH_SSE targets. The testcase:

typedef unsigned int v2si __attribute__((vector_size(8)));
v2si foo(v2si x, v2si y) { return (v2si){y[0], x[1]}; }

is currently compiled to (-O2):

foo:
movdqa  %xmm0, %xmm2
movdqa  %xmm1, %xmm0
pshufd  $0xe5, %xmm2, %xmm2
punpckldq %xmm2, %xmm0
ret

and with the patched compiler:

foo:
movss   %xmm1, %xmm0
ret

The functionality is already tested in gcc.target/i386/vperm-v2si.c

gcc/ChangeLog:

* config/i386/i386-expand.cc (expand_vec_perm_movs):
Handle V2SImode for TARGET_MMX_WITH_SSE.
* config/i386/mmx.md (*mmx_movss_): Rename from *mmx_movss
using V2FI mode iterator to handle both V2SI and V2SF modes.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 1094ece8b6d..6cc8bd5c80c 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -18949,11 +18949,9 @@ expand_vec_perm_movs (struct expand_vec_perm_d *d)
   if (d->one_operand_p)
 return false;
 
-  if (!(TARGET_SSE && vmode == V4SFmode)
-  && !(TARGET_SSE && vmode == V4SImode)
-  && !(TARGET_MMX_WITH_SSE && vmode == V2SFmode)
-  && !(TARGET_SSE2 && vmode == V2DFmode)
-  && !(TARGET_SSE2 && vmode == V2DImode))
+  if (!(TARGET_SSE && (vmode == V4SFmode || vmode == V4SImode))
+  && !(TARGET_MMX_WITH_SSE && (vmode == V2SFmode || vmode == V2SImode))
+  && !(TARGET_SSE2 && (vmode == V2DFmode || vmode == V2DImode)))
 return false;
 
   /* Only the first element is changed.  */
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 0deccc2d2f4..f9c66115f81 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -1518,11 +1518,11 @@
(set_attr "prefix" "*,maybe_vex,orig")
(set_attr "mode" "DI,V4SF,V4SF")])
 
-(define_insn "*mmx_movss"
-  [(set (match_operand:V2SF 0 "register_operand"   "=x,v")
-   (vec_merge:V2SF
- (match_operand:V2SF 2 "register_operand" " x,v")
- (match_operand:V2SF 1 "register_operand" " 0,v")
+(define_insn "*mmx_movss_"
+  [(set (match_operand:V2FI 0 "register_operand"   "=x,v")
+   (vec_merge:V2FI
+ (match_operand:V2FI 2 "register_operand" " x,v")
+ (match_operand:V2FI 1 "register_operand" " 0,v")
  (const_int 1)))]
   "TARGET_MMX_WITH_SSE"
   "@

Re: [PATCH v2] doc: md.texi (Insn Splitting): Tweak wording for readability.

[Sandra Loosemore]

On 3/14/23 10:04, Hans-Peter Nilsson via Gcc-patches wrote:


Thank you for the review!  Updated version below with your
suggestions.


This looks fine to me, from a writing perspective at least.


When spot-checking the pdf I noticed a strange
split of the page after the next after the section I
changed: last on page 484 "17.17 Including Patterns in
Machine Descriptions", there's a "(include" last on the page
and "pathname)" on top of page 485.  I'm afraid this patch
triggered that.  IMHO it'd be wrong to diddle with
formatting of *that* in *this* patch, instead leaving it to
a follow-up-patch.  I think the obvious fix is to *not*
split up (include pathname)" because that just looks odd
even without the page end in-between.  Right?


Yes.  I was skimming through the PDF of the GCC user manual myself last 
week, and noticed a *lot* of problems with both extraneous line breaks 
and lines that are too long and get cut off on the right in preformatted 
text pieces (including the option tables).  I'm sure the internals 
manual is even worse because it's gotten much less clean-up effort than 
the user-facing documentation.


FWIW, I consider fixes to whitespace, adding missing markup like @code, 
etc to be "obvious" changes in the same category as fixing typos. 
There's no need to ask for review of such changes, just go ahead and 
push them and post the patch of what you did.


-Sandra

[PATCH 1/2] c++: constrained template friend class matching [PR96830]

[Patrick Palka via Gcc-patches]

Here when instantiating a constrained template friend naming an already
declared class template, we erroneously pass the existing template's
constraints instead of the friend declaration's constraints to
redeclare_class_template, which causes the constraint comparison check
therein to always be vacuously true, and we fail to diagnose legitimate
constraint mismatches.

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

PR c++/96830

gcc/cp/ChangeLog:

* pt.cc (redeclare_class_template): Add missing "of" in
constraint mismatch diagnostic.
(tsubst_friend_class): For an already declared class template,
substitute and pass the friend declaration's constraints to
redeclare_class_template instead of passing the existing
template's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-friend14.C: New test.
---
 gcc/cp/pt.cc  |  8 --
 .../g++.dg/cpp2a/concepts-friend14.C  | 26 +++
 2 files changed, 32 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-friend14.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 85136df1730..053cc52b285 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -6377,7 +6377,7 @@ redeclare_class_template (tree type, tree parms, tree 
cons)
   if (!cp_tree_equal (req1, req2))
 {
   auto_diagnostic_group d;
-  error_at (input_location, "redeclaration %q#D with different "
+  error_at (input_location, "redeclaration of %q#D with different "
 "constraints", tmpl);
   inform (DECL_SOURCE_LOCATION (tmpl),
   "original declaration appeared here");
@@ -11503,7 +11503,11 @@ tsubst_friend_class (tree friend_tmpl, tree args)
 tf_warning_or_error);
   location_t saved_input_location = input_location;
   input_location = DECL_SOURCE_LOCATION (friend_tmpl);
-  tree cons = get_constraints (tmpl);
+ tree cons = get_constraints (friend_tmpl);
+ ++processing_template_decl;
+ cons = tsubst_constraint_info (cons, args, tf_warning_or_error,
+DECL_FRIEND_CONTEXT (friend_tmpl));
+ --processing_template_decl;
   redeclare_class_template (TREE_TYPE (tmpl), parms, cons);
   input_location = saved_input_location;
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-friend14.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-friend14.C
new file mode 100644
index 000..f46c7e4bdfb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-friend14.C
@@ -0,0 +1,26 @@
+// PR c++/96830
+// { dg-do compile { target c++20 } }
+
+template requires true
+struct A {
+  template friend struct A;   // { dg-error 
"different constraints" }
+  template requires (!!true) friend struct A; // { dg-error 
"different constraints" }
+};
+
+template
+struct B {
+  template requires true friend struct A;
+  template requires true friend struct B; // { dg-error "different 
constraints" }
+};
+
+template concept C = true;
+
+template
+struct D {
+  template friend struct D; // { dg-error "different constraints" }
+  template friend struct D;
+};
+
+template struct A;
+template struct B;
+template struct D;
-- 
2.40.0

[PATCH 2/2] c++: redeclaring member of constrained class template [PR96830]

[Patrick Palka via Gcc-patches]

When redeclaring a member of a constrained class template, we need to
repeat the class's constraints, but it turns out we don't verify
anywhere that the repeated constraints match the class's constraints.
A safe place to do so seems to be in push_template_decl, nearby a
similar consistency check for the template parameter list length of a
redeclaration.

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

PR c++/96830

gcc/cp/ChangeLog:

* pt.cc (push_inline_template_parms_recursive): Set
TEMPLATE_PARMS_CONSTRAINTS.
(push_template_decl): For a redeclaration, verify constraints
for each enclosing template scope match those of the original
template declaratation.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-class5.C: New test.
* g++.dg/cpp2a/concepts-class5a.C: New test.
---
 gcc/cp/pt.cc  | 26 +
 gcc/testsuite/g++.dg/cpp2a/concepts-class5.C  | 37 ++
 gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C | 38 +++
 3 files changed, 101 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-class5.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 053cc52b285..370a4f70f08 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -471,6 +471,8 @@ push_inline_template_parms_recursive (tree parmlist, int 
levels)
   current_template_parms
 = tree_cons (size_int (current_template_depth + 1),
 parms, current_template_parms);
+  TEMPLATE_PARMS_CONSTRAINTS (current_template_parms)
+= TEMPLATE_PARMS_CONSTRAINTS (parmlist);
   TEMPLATE_PARMS_FOR_INLINE (current_template_parms) = 1;
 
   begin_scope (TREE_VEC_LENGTH (parms) ? sk_template_parms : sk_template_spec,
@@ -6134,6 +6136,30 @@ push_template_decl (tree decl, bool is_friend)
  DECL_INTERFACE_KNOWN (decl) = 1;
  return error_mark_node;
}
+
+  /* Check that the constraints for each enclosing template scope are
+consistent with the original template declaration.  */
+  if (flag_concepts)
+   {
+ tree decl_parms = DECL_TEMPLATE_PARMS (tmpl);
+ tree scope_parms = current_template_parms;
+ if (PRIMARY_TEMPLATE_P (tmpl))
+   {
+ decl_parms = TREE_CHAIN (decl_parms);
+ scope_parms = TREE_CHAIN (scope_parms);
+   }
+ while (decl_parms)
+   {
+ if (!template_requirements_equivalent_p (decl_parms, scope_parms))
+   {
+ error ("redeclaration of %qD with different constraints",
+TPARMS_PRIMARY_TEMPLATE (TREE_VALUE (decl_parms)));
+ break;
+   }
+ decl_parms = TREE_CHAIN (decl_parms);
+ scope_parms = TREE_CHAIN (scope_parms);
+   }
+   }
 }
 
   gcc_checking_assert (!tmpl || DECL_TEMPLATE_RESULT (tmpl) == decl);
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-class5.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-class5.C
new file mode 100644
index 000..5d893d9f6a7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-class5.C
@@ -0,0 +1,37 @@
+// PR c++/96830
+// { dg-do compile { target c++20 } }
+
+template concept C = true;
+
+template requires true
+struct A {
+  void f();
+  template void g();
+
+  struct B;
+  template struct C;
+
+  static int D;
+  template static int E;
+};
+
+template
+void A::f() { }  // { dg-error "different constraints" }
+
+template requires true
+template
+void A::g() { }  // { dg-error "different constraints" }
+
+template requires (!!true)
+struct A::B { }; // { dg-error "different constraints" }
+
+template requires true
+template
+struct A::C { }; // { dg-error "different constraints" }
+
+template
+int A::D = 0;// { dg-error "different constraints" }
+
+template requires true
+template
+int A::E = 0;// { dg-error "different constraints" }
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C
new file mode 100644
index 000..a6a3684c258
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-class5a.C
@@ -0,0 +1,38 @@
+// PR c++/96830
+// A valid version of concepts-class5.C.
+// { dg-do compile { target c++20 } }
+
+template concept C = true;
+
+template requires true
+struct A {
+  void f();
+  template void g();
+
+  struct B;
+  template struct C;
+
+  static int D;
+  template static int E;
+};
+
+template requires true
+void A::f() { }
+
+template requires true
+template
+void A::g() { }
+
+template requires true
+struct A::B { };
+
+template requires true
+template
+struct A::C { };
+
+template requires true
+int A::D = 0;
+
+template requires true
+template
+int A::E = 0;
-- 
2.40.0

Re: [PATCH] i386: Fix up split_double_concat [PR109109]

[Uros Bizjak via Gcc-patches]

On Tue, Mar 14, 2023 at 5:09 PM Jakub Jelinek  wrote:
>
> Hi!
>
> In my PR107627 change I've missed one important case, which causes
> miscompilation of f4 and f6 in the following tests.
>
> Combine matches there *concatsidi3_3 define_insn_and_split (as with all
> other f* functions in those tests), and RA ends up with:
> (insn 11 10 17 2 (set (reg:DI 0 ax [89])
> (ior:DI (ashift:DI (zero_extend:DI (mem:SI (plus:SI (mult:SI (reg:SI 
> 0 ax [94])
> (const_int 4 [0x4]))
> (symbol_ref:SI ("arr") [flags 0x2]   0x7f4e7fe4ccf0 arr>)) [1 arr[ax_6(D)]+0 S4 A32]))
> (const_int 32 [0x20]))
> (zero_extend:DI (reg:SI 1 dx [95] "pr109109-6.c":24:49 681 
> {*concatsidi3_3}
>  (nil))
> split_double_concat turned that into:
> movlarr(,%eax,4), %edx
> movl%edx, %eax
> which is incorrect, because the first instruction overrides the input
> %edx value that should be put into output %eax; the two insns can't be
> swapped because the MEM's address uses %eax.
>
> The following patch fixes that case to emit
> movlarr(,%eax,4), %eax
> xchgl   %edx, %eax
> instead.
>
> Bootstrap/regtest on x86_64-linux and i686-linux pending, ok for trunk
> if it passes on both?
>
> 2023-03-14  Jakub Jelinek  
>
> PR target/109109
> * config/i386/i386-expand.cc (split_double_concat): Fix splitting
> when lo is equal to dhi and hi is a MEM which uses dlo register.
>
> * gcc.target/i386/pr109109-1.c: New test.
> * gcc.target/i386/pr109109-2.c: New test.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/i386-expand.cc.jj   2023-02-18 12:39:58.334768946 +0100
> +++ gcc/config/i386/i386-expand.cc  2023-03-14 15:07:38.672919652 +0100
> @@ -197,9 +197,20 @@ split_double_concat (machine_mode mode,
>  {
>/* In this case, code below would first emit_move_insn (dlo, lo)
>  and then emit_move_insn (dhi, hi).  But the former would
> -invalidate hi's address.  Load into dhi first.  */
> -  emit_move_insn (dhi, hi);
> -  hi = dhi;
> +invalidate hi's address.  */
> +  if (rtx_equal_p (dhi, lo))
> +   {
> + /* We can't load into dhi first, so load into dlo
> +first and we'll swap.  */
> + emit_move_insn (dlo, hi);
> + hi = dlo;
> +   }
> +  else
> +   {
> + /* Load into dhi first.  */
> + emit_move_insn (dhi, hi);
> + hi = dhi;
> +   }
>  }
>if (!rtx_equal_p (dlo, hi))
>  {
> --- gcc/testsuite/gcc.target/i386/pr109109-1.c.jj   2023-03-14 
> 15:51:35.104926863 +0100
> +++ gcc/testsuite/gcc.target/i386/pr109109-1.c  2023-03-14 15:51:16.715191961 
> +0100
> @@ -0,0 +1,139 @@
> +/* PR target/109109 */
> +/* { dg-do run { target ia32 } } */
> +/* { dg-options "-O2" } */
> +
> +unsigned int arr[64];
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f1 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) arr[ax]) << 32) | ax;
> +}
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f2 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) arr[dx]) << 32) | ax;
> +}
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f3 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) ((unsigned int *) (((char *) arr) + 
> ax))[dx]) << 32) | ax;
> +}
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f4 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) arr[ax]) << 32) | dx;
> +}
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f5 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) arr[dx]) << 32) | dx;
> +}
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f6 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) ((unsigned int *) (((char *) arr) + 
> ax))[dx]) << 32) | dx;
> +}
> +
> +__attribute__((noipa, regparm (3))) unsigned long long
> +f7 (unsigned int ax, unsigned int dx, unsigned int cx)
> +{
> +  return (((unsigned long long) arr[ax]) << 32) | cx;
> +}
> +
> +__attribute__((noipa, regparm (3))) unsigned long long
> +f8 (unsigned int ax, unsigned int dx, unsigned int cx)
> +{
> +  return (((unsigned long long) arr[dx]) << 32) | cx;
> +}
> +
> +__attribute__((noipa, regparm (3))) unsigned long long
> +f9 (unsigned int ax, unsigned int dx, unsigned int cx)
> +{
> +  return (((unsigned long long) ((unsigned int *) (((char *) arr) + 
> ax))[dx]) << 32) | cx;
> +}
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f10 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) ax) << 32) | arr[ax];
> +}
> +
> +__attribute__((noipa, regparm (2))) unsigned long long
> +f11 (unsigned int ax, unsigned int dx)
> +{
> +  return (((unsigned long long) ax) << 32) | arr[dx];
> +}
> +
> +__attribute__((noipa, regparm (2))) 

[PATCH] i386: Fix up split_double_concat [PR109109]

[Jakub Jelinek via Gcc-patches]

Hi!

In my PR107627 change I've missed one important case, which causes
miscompilation of f4 and f6 in the following tests.

Combine matches there *concatsidi3_3 define_insn_and_split (as with all
other f* functions in those tests), and RA ends up with:
(insn 11 10 17 2 (set (reg:DI 0 ax [89])
(ior:DI (ashift:DI (zero_extend:DI (mem:SI (plus:SI (mult:SI (reg:SI 0 
ax [94])
(const_int 4 [0x4]))
(symbol_ref:SI ("arr") [flags 0x2]  )) [1 arr[ax_6(D)]+0 S4 A32]))
(const_int 32 [0x20]))
(zero_extend:DI (reg:SI 1 dx [95] "pr109109-6.c":24:49 681 
{*concatsidi3_3}
 (nil))
split_double_concat turned that into:
movlarr(,%eax,4), %edx
movl%edx, %eax
which is incorrect, because the first instruction overrides the input
%edx value that should be put into output %eax; the two insns can't be
swapped because the MEM's address uses %eax.

The following patch fixes that case to emit
movlarr(,%eax,4), %eax
xchgl   %edx, %eax
instead.

Bootstrap/regtest on x86_64-linux and i686-linux pending, ok for trunk
if it passes on both?

2023-03-14  Jakub Jelinek  

PR target/109109
* config/i386/i386-expand.cc (split_double_concat): Fix splitting
when lo is equal to dhi and hi is a MEM which uses dlo register.

* gcc.target/i386/pr109109-1.c: New test.
* gcc.target/i386/pr109109-2.c: New test.

--- gcc/config/i386/i386-expand.cc.jj   2023-02-18 12:39:58.334768946 +0100
+++ gcc/config/i386/i386-expand.cc  2023-03-14 15:07:38.672919652 +0100
@@ -197,9 +197,20 @@ split_double_concat (machine_mode mode,
 {
   /* In this case, code below would first emit_move_insn (dlo, lo)
 and then emit_move_insn (dhi, hi).  But the former would
-invalidate hi's address.  Load into dhi first.  */
-  emit_move_insn (dhi, hi);
-  hi = dhi;
+invalidate hi's address.  */
+  if (rtx_equal_p (dhi, lo))
+   {
+ /* We can't load into dhi first, so load into dlo
+first and we'll swap.  */
+ emit_move_insn (dlo, hi);
+ hi = dlo;
+   }
+  else
+   {
+ /* Load into dhi first.  */
+ emit_move_insn (dhi, hi);
+ hi = dhi;
+   }
 }
   if (!rtx_equal_p (dlo, hi))
 {
--- gcc/testsuite/gcc.target/i386/pr109109-1.c.jj   2023-03-14 
15:51:35.104926863 +0100
+++ gcc/testsuite/gcc.target/i386/pr109109-1.c  2023-03-14 15:51:16.715191961 
+0100
@@ -0,0 +1,139 @@
+/* PR target/109109 */
+/* { dg-do run { target ia32 } } */
+/* { dg-options "-O2" } */
+
+unsigned int arr[64];
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f1 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) arr[ax]) << 32) | ax;
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f2 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) arr[dx]) << 32) | ax;
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f3 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) ((unsigned int *) (((char *) arr) + ax))[dx]) 
<< 32) | ax;
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f4 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) arr[ax]) << 32) | dx;
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f5 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) arr[dx]) << 32) | dx;
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f6 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) ((unsigned int *) (((char *) arr) + ax))[dx]) 
<< 32) | dx;
+}
+
+__attribute__((noipa, regparm (3))) unsigned long long
+f7 (unsigned int ax, unsigned int dx, unsigned int cx)
+{
+  return (((unsigned long long) arr[ax]) << 32) | cx;
+}
+
+__attribute__((noipa, regparm (3))) unsigned long long
+f8 (unsigned int ax, unsigned int dx, unsigned int cx)
+{
+  return (((unsigned long long) arr[dx]) << 32) | cx;
+}
+
+__attribute__((noipa, regparm (3))) unsigned long long
+f9 (unsigned int ax, unsigned int dx, unsigned int cx)
+{
+  return (((unsigned long long) ((unsigned int *) (((char *) arr) + ax))[dx]) 
<< 32) | cx;
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f10 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) ax) << 32) | arr[ax];
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f11 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) ax) << 32) | arr[dx];
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f12 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) ax) << 32) | ((unsigned int *) (((char *) arr) 
+ ax))[dx];
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f13 (unsigned int ax, unsigned int dx)
+{
+  return (((unsigned long long) dx) << 32) | arr[ax];
+}
+
+__attribute__((noipa, regparm (2))) unsigned long long
+f14 

[PATCH v2] doc: md.texi (Insn Splitting): Tweak wording for readability.

[Hans-Peter Nilsson via Gcc-patches]

> Date: Mon, 13 Mar 2023 22:31:21 -0600
> From: Sandra Loosemore 

> On 3/13/23 19:25, Hans-Peter Nilsson via Gcc-patches wrote:
> > Jan, did I get this right?  This was from your
> > r0-36413-g6b24c25948265c / svn r44249, now on its 22nd year!
> > 
> > I spot-checked the pdf for readability.  Also calling on a
> > doc maintainer to check grammos etc.  Ok to commit?
> > 
> > -- >8 --
> > I needed to check what was allowed in a define_split, but
> > had problems understanding what was meant by "Splitting of
> > jump instruction into sequence that over by another jump
> > instruction".
> > 
> > * doc/md.texi (Insn Splitting): Tweak wording for readability.
> 
> Thanks for noticing this!  I can't comment on technical correctness, but 
> I do have some further suggestions on wording below.

Thank you for the review!  Updated version below with your
suggestions.  When spot-checking the pdf I noticed a strange
split of the page after the next after the section I
changed: last on page 484 "17.17 Including Patterns in
Machine Descriptions", there's a "(include" last on the page
and "pathname)" on top of page 485.  I'm afraid this patch
triggered that.  IMHO it'd be wrong to diddle with
formatting of *that* in *this* patch, instead leaving it to
a follow-up-patch.  I think the obvious fix is to *not*
split up (include pathname)" because that just looks odd
even without the page end in-between.  Right?

-- >8 --
I needed to check what was allowed in a define_split, but
had problems understanding what was meant by "Splitting of
jump instruction into sequence that over by another jump
instruction".

* doc/md.texi (Insn Splitting): Tweak wording for readability.

Co-Authored-By: Sandra Loosemore 
---
 gcc/doc/md.texi | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 8e3113599fdc..134b227b9a93 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -8756,21 +8756,21 @@ insns that don't.  Instead, write two separate 
@code{define_split}
 definitions, one for the insns that are valid and one for the insns that
 are not valid.
 
-The splitter is allowed to split jump instructions into sequence of
-jumps or create new jumps in while splitting non-jump instructions.  As
-the control flow graph and branch prediction information needs to be updated,
-several restriction apply.
-
-Splitting of jump instruction into sequence that over by another jump
-instruction is always valid, as compiler expect identical behavior of new
-jump.  When new sequence contains multiple jump instructions or new labels,
-more assistance is needed.  Splitter is required to create only unconditional
-jumps, or simple conditional jump instructions.  Additionally it must attach a
-@code{REG_BR_PROB} note to each conditional jump.  A global variable
-@code{split_branch_probability} holds the probability of the original branch 
in case
-it was a simple conditional jump, @minus{}1 otherwise.  To simplify
-recomputing of edge frequencies, the new sequence is required to have only
-forward jumps to the newly created labels.
+The splitter is allowed to split jump instructions into a sequence of jumps or
+create new jumps while splitting non-jump instructions.  As the control flow
+graph and branch prediction information needs to be updated after the splitter
+runs, several restrictions apply.
+
+Splitting of a jump instruction into a sequence that has another jump
+instruction to the same label is always valid, as the compiler expects
+identical behavior of the new jump.  When the new sequence contains multiple
+jump instructions or new labels, more assistance is needed.  The splitter is
+permitted to create only unconditional jumps, or simple conditional jump
+instructions.  Additionally it must attach a @code{REG_BR_PROB} note to each
+conditional jump.  A global variable @code{split_branch_probability} holds the
+probability of the original branch in case it was a simple conditional jump,
+@minus{}1 otherwise.  To simplify recomputing of edge frequencies, the new
+sequence is permitted to have only forward jumps to the newly-created labels.
 
 @findex define_insn_and_split
 For the common case where the pattern of a define_split exactly matches the
-- 
2.30.2

brgds, H-P

Re: [PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634]

[Jason Merrill via Gcc-patches]

On 3/14/23 11:42, Jakub Jelinek wrote:

Hi!

On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:

The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
gdbhooks, which expects tree_code_type to always be available.  I considered
trying to make gdbhooks more robust, but it seemed simpler to define
tree_code_type as a reference to the template.


As I said earlier, I think it is better to tweak gdbhooks.

The following patch does that, I've tested it now both with gcc 12 and
older gcc as system compiler and the patch fixed the latter while keeping
the former working as before.

Ok for trunk?


LGTM, OK on Friday if no other comments.


2023-03-14  Jakub Jelinek  

PR plugins/108634
* gdbhooks.py (TreePrinter.to_string): Wrap
gdb.parse_and_eval('tree_code_type') in a try block, parse
and eval 'tree_code_type_tmpl<0>::tree_code_type' instead if it
raises exception.  Update comments for the recent tree_code_type
changes.

--- gcc/gdbhooks.py.jj  2023-03-04 11:24:01.348791347 +0100
+++ gcc/gdbhooks.py 2023-03-14 16:35:48.445671242 +0100
@@ -220,13 +220,23 @@ class TreePrinter:
  
  val_TREE_CODE = self.node.TREE_CODE()
  
-# extern const enum tree_code_class tree_code_type[];

+# constexpr inline enum tree_code_class tree_code_type[] = { ... };
  # #define TREE_CODE_CLASS(CODE)   tree_code_type[(int) (CODE)]
+# or
+# template 
+# struct tree_code_type_tmpl {
+# static constexpr enum tree_code_class tree_code_type[] = { ... };
+# }; };
+# #define TREE_CODE_CLASS(CODE) \
+# tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)]
  
  if val_TREE_CODE == 0xa5a5:

  return '' % intptr(self.gdbval)
  
-val_tree_code_type = gdb.parse_and_eval('tree_code_type')

+try:
+val_tree_code_type = gdb.parse_and_eval('tree_code_type')
+except:
+val_tree_code_type = 
gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type')
  val_tclass = val_tree_code_type[val_TREE_CODE]
  
  val_tree_code_name = gdb.parse_and_eval('tree_code_name')



Jakub

[PATCH] gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634]

[Jakub Jelinek via Gcc-patches]

Hi!

On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke
> gdbhooks, which expects tree_code_type to always be available.  I considered
> trying to make gdbhooks more robust, but it seemed simpler to define
> tree_code_type as a reference to the template.

As I said earlier, I think it is better to tweak gdbhooks.

The following patch does that, I've tested it now both with gcc 12 and
older gcc as system compiler and the patch fixed the latter while keeping
the former working as before.

Ok for trunk?

2023-03-14  Jakub Jelinek  

PR plugins/108634
* gdbhooks.py (TreePrinter.to_string): Wrap
gdb.parse_and_eval('tree_code_type') in a try block, parse
and eval 'tree_code_type_tmpl<0>::tree_code_type' instead if it
raises exception.  Update comments for the recent tree_code_type
changes.

--- gcc/gdbhooks.py.jj  2023-03-04 11:24:01.348791347 +0100
+++ gcc/gdbhooks.py 2023-03-14 16:35:48.445671242 +0100
@@ -220,13 +220,23 @@ class TreePrinter:
 
 val_TREE_CODE = self.node.TREE_CODE()
 
-# extern const enum tree_code_class tree_code_type[];
+# constexpr inline enum tree_code_class tree_code_type[] = { ... };
 # #define TREE_CODE_CLASS(CODE)tree_code_type[(int) (CODE)]
+# or
+# template 
+# struct tree_code_type_tmpl {
+# static constexpr enum tree_code_class tree_code_type[] = { ... };
+# }; };
+# #define TREE_CODE_CLASS(CODE) \
+# tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)]
 
 if val_TREE_CODE == 0xa5a5:
 return '' % intptr(self.gdbval)
 
-val_tree_code_type = gdb.parse_and_eval('tree_code_type')
+try:
+val_tree_code_type = gdb.parse_and_eval('tree_code_type')
+except:
+val_tree_code_type = 
gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type')
 val_tclass = val_tree_code_type[val_TREE_CODE]
 
 val_tree_code_name = gdb.parse_and_eval('tree_code_name')


Jakub

Ping Re: [PATCH RFC] c++: lambda mangling alias issues [PR107897]

[Jason Merrill via Gcc-patches]

On 3/8/23 11:54, Jason Merrill wrote:

On 3/8/23 11:15, Jason Merrill wrote:

On 3/8/23 10:53, Jan Hubicka wrote:
Tested x86_64-pc-linux-gnu.  Does this look good, or do we want to 
factor the

flag clearing into a symtab_node counterpart to cgraph_node::reset?

-- 8< --

In 107897, by the time we are looking at the mangling clash, the
alias has already been removed from the symbol table by 
analyze_functions,

so we can't look at n->cpp_implicit_alias.  So just assume that it's an
alias if it's internal.

In 108887 the problem is that removing the mangling alias from the 
symbol

table confuses analyze_functions, because it ended up as first_analyzed
somehow, so it becomes a dangling pointer.  Fixed by clearing 
various flags

to neutralize the alias.

PR c++/107897
PR c++/108887

gcc/cp/ChangeLog:

* decl2.cc (record_mangling): Improve symbol table handling.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported.
* g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.
---
  gcc/cp/decl2.cc   | 25 +--
  .../g++.dg/cpp0x/lambda/lambda-mangle7.C  | 70 
+++

  gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C |  1 +
  3 files changed, 91 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle7.C

diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 387e24542cd..e6e58b08de4 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -4742,15 +4742,30 @@ record_mangling (tree decl, bool need_warning)
  = mangled_decls->find_slot_with_hash (id, 
IDENTIFIER_HASH_VALUE (id),

    INSERT);
-  /* If this is already an alias, remove the alias, because the real
+  /* If this is already an alias, cancel the alias, because the real
   decl takes precedence.  */
    if (*slot && DECL_ARTIFICIAL (*slot) && DECL_IGNORED_P (*slot))
-    if (symtab_node *n = symtab_node::get (*slot))
-  if (n->cpp_implicit_alias)
+    {
+  if (symtab_node *n = symtab_node::get (*slot))
  {
-  n->remove ();
-  *slot = NULL_TREE;
+  if (n->cpp_implicit_alias)
+    {
+  /* Actually removing the node isn't safe if other code is 
already

+ holding a pointer to it, so just neutralize it.  */
+  n->remove_from_same_comdat_group ();
+  n->analyzed = false;
+  n->definition = false;
+  n->alias = false;
+  n->cpp_implicit_alias = false;

We have n->reset () for that which is used in similar situation when
frontends overwrites extern inline function by its different offline
implementation.


The problem there is that reset() is a member of cgraph_node, not 
symtab_node, and I need something that works for variables as well.



reset doesn't call remove_from_same_comdat_group probably because it was
never used on anything in comdat group.  So I think it would make sense
to call n->reset() here and add remove_from_same_comdat_group into that.


How about moving it to symtab_node and using dyn_cast for the cgraph 
bits, like this:


Ping? (Patch in attachment in earlier message)

Re: [PATCH] RISC-V: Fix bugs of ternary integer and floating-point ternary intrinsics.

[Jeff Law via Gcc-patches]

On 3/13/23 20:37, Kito Cheng via Gcc-patches wrote:

IIRC the canonical form of (plus (op)  (mult (op) (op))) is (plus
(mult (op) (op) (op)), so using the first form might not friendly for
the combine pass.
You're correct.  The other form shouldn't be used at all and should not 
appear in the MD files.


jeff

Re: [PATCH v4 2/2] gcc: Drop obsolete INCLUDE_PTHREAD_H

[Jeff Law via Gcc-patches]

On 3/14/23 07:45, Kito Cheng via Gcc-patches wrote:

It's not the RISC-V part, so this requires a global maintainer there I think?
It does.  I hadn't had a chance to dig into the history of the pthread.h 
include to understand why it was originally included which would be the 
first step in determining if it's actually safe to remove.


Jeff

Re: [PATCH] c++: Treat unnamed bitfields as padding for __has_unique_object_representations [PR109096]

[Jason Merrill via Gcc-patches]

On 3/14/23 03:58, Jakub Jelinek wrote:

Hi!

As reported in the PR, for __has_unique_object_representations we
were treating unnamed bitfields as named ones, which is wrong, they
are actually padding.

THe following patch fixes that.  Ok for trunk (and what about release
branches later?)?


OK.


2023-03-14  Jakub Jelinek  

PR c++/109096
* tree.cc (record_has_unique_obj_representations): Ignore unnamed
bitfields.

* g++.dg/cpp1z/has-unique-obj-representations3.C: New test.

--- gcc/cp/tree.cc.jj   2023-03-10 10:06:40.247560614 +0100
+++ gcc/cp/tree.cc  2023-03-13 10:38:03.394836926 +0100
@@ -4851,7 +4851,7 @@ record_has_unique_obj_representations (c
DECL_SIZE (field)))
  return false;
}
-else if (DECL_C_BIT_FIELD (field))
+else if (DECL_C_BIT_FIELD (field) && !DECL_UNNAMED_BIT_FIELD (field))
{
tree btype = DECL_BIT_FIELD_TYPE (field);
if (!type_has_unique_obj_representations (btype))
@@ -4862,7 +4862,7 @@ record_has_unique_obj_representations (c
  
offset_int cur = 0;

for (tree field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
-if (TREE_CODE (field) == FIELD_DECL)
+if (TREE_CODE (field) == FIELD_DECL && !DECL_UNNAMED_BIT_FIELD (field))
{
offset_int fld = wi::to_offset (DECL_FIELD_OFFSET (field));
offset_int bitpos = wi::to_offset (DECL_FIELD_BIT_OFFSET (field));
--- gcc/testsuite/g++.dg/cpp1z/has-unique-obj-representations3.C.jj 
2023-03-13 10:50:21.705127719 +0100
+++ gcc/testsuite/g++.dg/cpp1z/has-unique-obj-representations3.C
2023-03-13 10:50:17.751185067 +0100
@@ -0,0 +1,10 @@
+// PR c++/109096
+// { dg-do compile { target c++11 } }
+
+#define INTB (__SIZEOF_INT__ * __CHAR_BIT__)
+struct U { int i : INTB * 3 / 4; int : INTB / 4; };
+struct V { int : INTB * 3 / 4; int j : INTB / 4; };
+struct W { int i; int : 0; int j; };
+static_assert (__has_unique_object_representations (U) == false, "");
+static_assert (__has_unique_object_representations (V) == false, "");
+static_assert (sizeof (W) != 2 * sizeof (int) || __has_unique_object_representations (W) 
== true, "");

Jakub

Re: [PATCH] testsuite: Fix up g++.dg/cpp2a/concepts-lambda3.C [PR108972]

[Jason Merrill via Gcc-patches]

On 3/14/23 03:54, Jakub Jelinek wrote:

Hi!

On Fri, Mar 10, 2023 at 01:49:38PM -0500, Jason Merrill via Gcc-patches wrote:

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels,
but expect errors.


I'm seeing
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++11 compilation failed to 
produce executable
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++14 compilation failed to 
produce executable
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++17 compilation failed to 
produce executable
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++98 compilation failed to 
produce executable
with this change, and if I test with
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++ -k 
RUNTESTFLAGS="--target_board=unix\{-m32,-m64,-m64/-fconcepts\} 
dg.exp=concepts-lambda3.C"
I see even FAILs for the -fconcepts case, so apparently even -std=c++17
-fconcepts isn't enough to make it compile without errors.

The following patch will expect errors for all of c++17_down and will
make the test dg-do compile for that case too, such that the UNRESOLVED
stuff is gone.

Ok for trunk?


OK.


2023-03-14  Jakub Jelinek  

PR c++/108972
* g++.dg/cpp2a/concepts-lambda3.C: Use dg-do run only for c++20,
for c++17_down dg-do compile.  Expect dg-excess-errors for c++17_down
rather than ! concepts.

--- gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C.jj2023-03-13 
23:01:42.082959131 +0100
+++ gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C   2023-03-14 
08:48:12.834128044 +0100
@@ -1,5 +1,6 @@
-// { dg-do run }
-// { dg-excess-errors "" { target { ! concepts } } } (PR108972)
+// { dg-do run { target c++20 } }
+// { dg-do compile { target c++17_down } }
+// { dg-excess-errors "" { target { c++17_down } } } (PR108972)
  
  template

  concept C1 = __is_same_as(T, int)


Jakub

Re: [PATCH v4 2/2] gcc: Drop obsolete INCLUDE_PTHREAD_H

[Kito Cheng via Gcc-patches]

It's not the RISC-V part, so this requires a global maintainer there I think?

On Tue, Mar 14, 2023 at 8:28 AM juzhe.zh...@rivai.ai
 wrote:
>
> Thank you for fixing this. I am not familiar with this.
> This generator code (genrvv-type-indexer.cc) is written by @kito.
>
> Kito ? Can you take a look at this?
>
>
> juzhe.zh...@rivai.ai
>
> From: Sam James
> Date: 2023-03-14 08:23
> To: gcc-patches
> CC: Kito Cheng; Palmer Dabbelt; Andrew Waterman; Jim Wilson; Ju-Zhe Zhong; 
> Sam James
> Subject: [PATCH v4 2/2] gcc: Drop obsolete INCLUDE_PTHREAD_H
> This is no longer used since 0a62889c7a155f8ed971860d68870dc9c46bb004, so
> let's clean it up.
>
> gcc/ChangeLog:
> * system.h: Drop unused INCLUDE_PTHREAD_H.
>
> Signed-off-by: Sam James 
> ---
> gcc/system.h | 4 
> 1 file changed, 4 deletions(-)
>
> diff --git a/gcc/system.h b/gcc/system.h
> index cf45db3f97e..3fdad7abf1e 100644
> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -761,10 +761,6 @@ extern int vsnprintf (char *, size_t, const char *, 
> va_list);
> #endif
> #endif
> -#ifdef INCLUDE_PTHREAD_H
> -#include 
> -#endif
> -
> #ifdef INCLUDE_ISL
> #ifdef HAVE_isl
> #include 
> --
> 2.40.0
>
>

Re: [PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

[Kito Cheng via Gcc-patches]

RISC-V part is ok, and I assume you didn't have write access so I'm
gonna push that since the system.h change also got approved :)

On Tue, Mar 14, 2023 at 5:07 PM Richard Biener via Gcc-patches
 wrote:
>
> On Tue, Mar 14, 2023 at 1:24 AM Sam James via Gcc-patches
>  wrote:
> >
> > This fixes errors like:
> > ```
> > In file included from /usr/include/pthread.h:30,
> >  from 
> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35,
> >  from 
> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr.h:148,
> >  from 
> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ext/atomicity.h:35,
> >  from 
> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/bits/ios_base.h:39,
> >  from 
> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ios:42,
> >  from 
> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/istream:38,
> >  from 
> > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/sstream:38,
> >  from 
> > /var/tmp/portage/sys-devel/gcc-13.0.1_pre20230305/work/gcc-13-20230305/gcc/config/riscv/genrvv-type-indexer.cc:22:
> > /usr/include/sched.h:84:7: error: attempt to use poisoned "calloc"
> >84 | void *calloc(size_t, size_t);
> >   |   ^
> > /usr/include/sched.h:124:36: error: attempt to use poisoned "calloc"
> >   124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
> >   |^
> > make[3]: *** [Makefile:2855: build/genrvv-type-indexer.o] Error 1
> > ```
> >
> > See also 3b21c21f3f5726823e19728fdd1571a14aae0fb3 and 
> > 49d508065bdd36fb1a9b6aad9666b1edb5e06474,
> > which was fixed in PR106102.
>
> The system.h change is OK
>
> > gcc/ChangeLog:
> > * config/riscv/genrvv-type-indexer.cc: Avoid calloc() poisoning on 
> > musl by
> > including  earlier.
> > * system.h: Add INCLUDE_SSTREAM.
> >
> > Signed-off-by: Sam James 
> > ---
> >  gcc/config/riscv/genrvv-type-indexer.cc | 2 +-
> >  gcc/system.h| 4 
> >  2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/riscv/genrvv-type-indexer.cc 
> > b/gcc/config/riscv/genrvv-type-indexer.cc
> > index 0ef1d766002..e677b55290c 100644
> > --- a/gcc/config/riscv/genrvv-type-indexer.cc
> > +++ b/gcc/config/riscv/genrvv-type-indexer.cc
> > @@ -14,12 +14,12 @@ along with GCC; see the file COPYING3.  If not see
> >  .  */
> >
> >  #include "bconfig.h"
> > +#define INCLUDE_SSTREAM
> >  #include "system.h"
> >  #include "errors.h"
> >
> >  #include "coretypes.h"
> >
> > -#include 
> >  #include 
> >  #include 
> >
> > diff --git a/gcc/system.h b/gcc/system.h
> > index 64cd5a49258..cf45db3f97e 100644
> > --- a/gcc/system.h
> > +++ b/gcc/system.h
> > @@ -751,6 +751,10 @@ extern int vsnprintf (char *, size_t, const char *, 
> > va_list);
> >  # include 
> >  #endif
> >
> > +#ifdef INCLUDE_SSTREAM
> > +# include 
> > +#endif
> > +
> >  #ifdef INCLUDE_MALLOC_H
> >  #if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
> >  #include 
> > --
> > 2.40.0
> >

Re: [PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

[Kito Cheng via Gcc-patches]

committed to trunk, thanks :)

On Tue, Mar 14, 2023 at 9:44 PM Kito Cheng  wrote:
>
> RISC-V part is ok, and I assume you didn't have write access so I'm
> gonna push that since the system.h change also got approved :)
>
> On Tue, Mar 14, 2023 at 5:07 PM Richard Biener via Gcc-patches
>  wrote:
> >
> > On Tue, Mar 14, 2023 at 1:24 AM Sam James via Gcc-patches
> >  wrote:
> > >
> > > This fixes errors like:
> > > ```
> > > In file included from /usr/include/pthread.h:30,
> > >  from 
> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35,
> > >  from 
> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr.h:148,
> > >  from 
> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ext/atomicity.h:35,
> > >  from 
> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/bits/ios_base.h:39,
> > >  from 
> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ios:42,
> > >  from 
> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/istream:38,
> > >  from 
> > > /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/sstream:38,
> > >  from 
> > > /var/tmp/portage/sys-devel/gcc-13.0.1_pre20230305/work/gcc-13-20230305/gcc/config/riscv/genrvv-type-indexer.cc:22:
> > > /usr/include/sched.h:84:7: error: attempt to use poisoned "calloc"
> > >84 | void *calloc(size_t, size_t);
> > >   |   ^
> > > /usr/include/sched.h:124:36: error: attempt to use poisoned "calloc"
> > >   124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
> > >   |^
> > > make[3]: *** [Makefile:2855: build/genrvv-type-indexer.o] Error 1
> > > ```
> > >
> > > See also 3b21c21f3f5726823e19728fdd1571a14aae0fb3 and 
> > > 49d508065bdd36fb1a9b6aad9666b1edb5e06474,
> > > which was fixed in PR106102.
> >
> > The system.h change is OK
> >
> > > gcc/ChangeLog:
> > > * config/riscv/genrvv-type-indexer.cc: Avoid calloc() poisoning 
> > > on musl by
> > > including  earlier.
> > > * system.h: Add INCLUDE_SSTREAM.
> > >
> > > Signed-off-by: Sam James 
> > > ---
> > >  gcc/config/riscv/genrvv-type-indexer.cc | 2 +-
> > >  gcc/system.h| 4 
> > >  2 files changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/gcc/config/riscv/genrvv-type-indexer.cc 
> > > b/gcc/config/riscv/genrvv-type-indexer.cc
> > > index 0ef1d766002..e677b55290c 100644
> > > --- a/gcc/config/riscv/genrvv-type-indexer.cc
> > > +++ b/gcc/config/riscv/genrvv-type-indexer.cc
> > > @@ -14,12 +14,12 @@ along with GCC; see the file COPYING3.  If not see
> > >  .  */
> > >
> > >  #include "bconfig.h"
> > > +#define INCLUDE_SSTREAM
> > >  #include "system.h"
> > >  #include "errors.h"
> > >
> > >  #include "coretypes.h"
> > >
> > > -#include 
> > >  #include 
> > >  #include 
> > >
> > > diff --git a/gcc/system.h b/gcc/system.h
> > > index 64cd5a49258..cf45db3f97e 100644
> > > --- a/gcc/system.h
> > > +++ b/gcc/system.h
> > > @@ -751,6 +751,10 @@ extern int vsnprintf (char *, size_t, const char *, 
> > > va_list);
> > >  # include 
> > >  #endif
> > >
> > > +#ifdef INCLUDE_SSTREAM
> > > +# include 
> > > +#endif
> > > +
> > >  #ifdef INCLUDE_MALLOC_H
> > >  #if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
> > >  #include 
> > > --
> > > 2.40.0
> > >

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

[Qing Zhao via Gcc-patches]

> On Mar 14, 2023, at 5:04 AM, Richard Biener  wrote:
> 
> On Mon, 13 Mar 2023, Qing Zhao wrote:
> 
>> Hi, Richard,
>> 
>> Do you have more comments on my responds to your previous questions?
> 
> No, generally we're not good at naming the shared bits, so keeping the
> old name is fine here.
Okay. I will keep the old name for it. 

> 
> Btw, I do not feel competent enough to approve the patch, instead that's
> on the burden of the C frontend maintainers and the people understanding
> the object-size code more.

So, Joseph and Jakub should be the ones to approve these patches?

I will update the patches with your suggestions for the bit.
And send the 5th version .

Thanks.

Qing

> 
> Richard.
> 
>> thanks.
>> 
>> Qing
>> 
>>> On Mar 10, 2023, at 8:48 AM, Qing Zhao via Gcc-patches 
>>>  wrote:
>>> 
>>> 
>>> 
 On Mar 10, 2023, at 2:54 AM, Richard Biener  wrote:
 
 On Thu, 9 Mar 2023, Qing Zhao wrote:
 
> 
> 
>> On Mar 9, 2023, at 7:20 AM, Richard Biener  wrote:
>> 
>> On Fri, 24 Feb 2023, Qing Zhao wrote:
>> 
>>> GCC extension accepts the case when a struct with a C99 flexible array 
>>> member
>>> is embedded into another struct or union (possibly recursively).
>>> __builtin_object_size should treat such struct as flexible size.
>>> 
>>> gcc/c/ChangeLog:
>>> 
>>> PR tree-optimization/101832
>>> * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for
>>> struct/union type.
>> 
>> I can't really comment on the correctness of this part but since
>> only the C frontend will ever set this and you are using it from
>> addr_object_size which is also used for other C family languages
>> (at least), I wonder if you can really test
>> 
>> +   if (!TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (v)))
>> 
>> there.
> 
> You mean for C++ and also other C family languages (other than C), the 
> above bit cannot be set?
> Yes, that’s true. The bit is only set for C. So is the bit 
> DECL_NOT_FLEXARRAY, which is only set for C too. 
> So, I am wondering whether the bit DECL_NOT_FLEXARRAY should be also set 
> in middle end? Or we can set DECL_NOT_FLEXARRAY in C++ FE too? And then 
> we can set TYPE_INCLUDE_FLEXARRAY also in C++ FE?
> What’s your suggestion?
> 
> (I personally feel that DECL_NOT_FLEXARRAY and TYPE_INCLUDE_FLEXARRAY 
> should be set in the same places).
 
 I was wondering if the above test errors on the conservative side
 correctly - it will now, for all but C, cut off some thing where it
 didn't before?
>>> 
>>> As long as the default value of TYPE_INCLUDE_FLEXARRAY reflects the correct 
>>> conservative  behavior, then the testing should be correct, right?
>>> 
>>> The default value of TYPE_INCLUDE_FLEXARRAY is 0, i.e, FALSE, means that 
>>> the TYPE does not include a flex array by default, this is the correct 
>>> behavior. Only when the TYPE does include a flexiarray, it will be set to 
>>> TRUE. So, I think it’s correct.
>>> 
>>> This is a different situation for DECL_NOT_FLEXARRAY, by default, the 
>>> compiler will treat ALL trailing arrays as FMA, so in order to keep the 
>>> correct conservative behavior, we should keep the default value for 
>>> DECL_NOT_FLEXARRAY as it’s a FMA, i.e, DECL_NOT_FLEXARRAY being FALSE, by 
>>> default. Only when the array is NOT a FMA, we set it to true. 
>>> 
>>> So, the default value for TYPE_INCLUDE_FLEXARRAY is correct. 
 
>> 
>> Originally I was suggesting to set this flag in stor-layout.cc
>> which eventually all languages funnel their types through and
>> if there's language specific handling use a langhook (with the
>> default implementation preserving the status quo).
> 
> If we decide to set the bits in stor-layout.cc, where is the best place 
> to do it? I checked the star-layout.cc code, looks like “layout_type” 
> might be the place where we can set these bits for RECORD_TYPE, 
> UNION_TYPE? 
 
 Yes, it would be layout_type.
 
>> 
>> Some more comments below ...
>> 
>>> gcc/cp/ChangeLog:
>>> 
>>> PR tree-optimization/101832
>>> * module.cc (trees_out::core_bools): Stream out new bit
>>> type_include_flexarray.
>>> (trees_in::core_bools): Stream in new bit 
>>> type_include_flexarray.
>>> 
>>> gcc/ChangeLog:
>>> 
>>> PR tree-optimization/101832
>>> * print-tree.cc (print_node): Print new bit 
>>> type_include_flexarray.
>>> * tree-core.h (struct tree_type_common): New bit
>>> type_include_flexarray.
>>> * tree-object-size.cc (addr_object_size): Handle 
>>> structure/union type
>>> when it has flexible size.
>>> * tree-streamer-in.cc (unpack_ts_type_common_value_fields): 
>>> Stream
>>> in new bit 

Re: [committed] libstdc++: Fix preprocessor condition for inline variables

[Daniel Krügler via Gcc-patches]

Am Di., 14. März 2023 um 12:02 Uhr schrieb Jonathan Wakely :
>
> On Tue, 14 Mar 2023 at 10:51, Daniel Krügler wrote:
>>
>> Apologies for the late response:
>>
>
> I only just committed the change, so it's not delayed :-)
>
>
>>
>> What about changing the test to check for __cpp_inline_variables or
>> combining it with __cpp_variable_templates instead?
>>
>
> We could do that, but it would complicate their use.
>
> Currently they're only used in C++17 code (chrono::floor etc.) and C++20 code 
> (chrono::hh_mm_ss etc. and chrono formatters). We know it's OK for C++17 and 
> C++20 code to use __is_duration_v and __is_time_point_v because they're 
> defined for C++17 and later.
>
> If we change them to be defined for __cpp_inline_variables && 
> __cpp_variable_templates then what changes? It should be safe to assume we 
> can still use them in C++17 and C++20 code, but could we also use them 
> elsewhere, e.g. in C++14 code such as chrono::literals? Maybe, but only if 
> __cpp_inline_variables is defined for C++14 mode, and if it's not, then we'd 
> need something like:
>
> #if __cplusplus >= 201402L
>   template
> #if __cpp_inline_variables
> enable_if_t<__is_duration_v<_Dur>, _Dur>
> #else
> enable_if_t<__is_duration<_Dur>::value, _Dur>
> #endif
> foo(const _Dur&);
> #endif
>
> And this is not an improvement over simply:
>
> #if __cplusplus >= 201402L
>   template
> enable_if_t<__is_duration<_Dur>::value, _Dur>
> foo(const _Dur&);
> #endif
>
> So I don't see why we would want to do it. I think it was a mistake for me to 
> ever make them depend on __cpp_variable_templates, instead of just depending 
> on C++17. I think it's better to fix that mistake.

Sounds reasonable, thanks.

- Daniel

Re: [committed] libstdc++: Fix preprocessor condition for inline variables

[Jonathan Wakely via Gcc-patches]

On Tue, 14 Mar 2023 at 10:51, Daniel Krügler wrote:

> Apologies for the late response:
>
>
I only just committed the change, so it's not delayed :-)



> What about changing the test to check for __cpp_inline_variables or
> combining it with __cpp_variable_templates instead?
>
>
We could do that, but it would complicate their use.

Currently they're only used in C++17 code (chrono::floor etc.) and C++20
code (chrono::hh_mm_ss etc. and chrono formatters). We know it's OK for
C++17 and C++20 code to use __is_duration_v and __is_time_point_v because
they're defined for C++17 and later.

If we change them to be defined for __cpp_inline_variables &&
__cpp_variable_templates then what changes? It should be safe to assume we
can still use them in C++17 and C++20 code, but could we also use them
elsewhere, e.g. in C++14 code such as chrono::literals? Maybe, but only if
__cpp_inline_variables is defined for C++14 mode, and if it's not, then
we'd need something like:

#if __cplusplus >= 201402L
  template
#if __cpp_inline_variables
enable_if_t<__is_duration_v<_Dur>, _Dur>
#else
enable_if_t<__is_duration<_Dur>::value, _Dur>
#endif
foo(const _Dur&);
#endif

And this is not an improvement over simply:

#if __cplusplus >= 201402L
  template
enable_if_t<__is_duration<_Dur>::value, _Dur>
foo(const _Dur&);
#endif

So I don't see why we would want to do it. I think it was a mistake for me
to ever make them depend on __cpp_variable_templates, instead of just
depending on C++17. I think it's better to fix that mistake.

Re: [committed] libstdc++: Fix preprocessor condition for inline variables

[Daniel Krügler via Gcc-patches]

Am Di., 14. März 2023 um 11:32 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> Although variable templates are valid in C++14, inline ones aren't.
> These are only used in C++17 (or later) code, so they don't need to be
> defined for C++14.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/chrono.h (__is_duration_v, __is_time_point_v):
> Only define for C++17 and later.
> ---
>  libstdc++-v3/include/bits/chrono.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/include/bits/chrono.h 
> b/libstdc++-v3/include/bits/chrono.h
> index b2e4f4c33a8..fb99fe5eed7 100644
> --- a/libstdc++-v3/include/bits/chrono.h
> +++ b/libstdc++-v3/include/bits/chrono.h
> @@ -244,7 +244,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>using __disable_if_is_duration
> = typename enable_if::value, _Tp>::type;
>
> -#if __cpp_variable_templates
> +#if __cplusplus >= 201703L
>  template
>inline constexpr bool __is_duration_v = false;
>  template
> --
> 2.39.2

Apologies for the late response:

What about changing the test to check for __cpp_inline_variables or
combining it with __cpp_variable_templates instead?

Thanks,

- Daniel

[committed] libstdc++: Add comment about symver linker scripts to makefile

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* src/Makefile.am: Add comment about linker script fragments.
* src/Makefile.in: Regenerate.
---
 libstdc++-v3/src/Makefile.am | 1 +
 libstdc++-v3/src/Makefile.in | 1 +
 2 files changed, 2 insertions(+)

diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index 8cbf34a19e8..5b9af41cdb9 100644
--- a/libstdc++-v3/src/Makefile.am
+++ b/libstdc++-v3/src/Makefile.am
@@ -302,6 +302,7 @@ CXXLINK = \
-o $@
 
 # Symbol versioning for shared libraries.
+# See configure.host and configure.ac for port_specific_symbol_files.
 if ENABLE_SYMVERS
 libstdc++-symbols.ver:  ${glibcxx_srcdir}/$(SYMVER_FILE) \
$(port_specific_symbol_files)
diff --git a/libstdc++-v3/src/Makefile.in b/libstdc++-v3/src/Makefile.in
index 10fd9aa0daf..f42d957af36 100644
--- a/libstdc++-v3/src/Makefile.in
+++ b/libstdc++-v3/src/Makefile.in
@@ -1064,6 +1064,7 @@ compatibility-condvar.o: compatibility-condvar.cc
$(CXXCOMPILE) -std=gnu++11 -c $<
 
 # Symbol versioning for shared libraries.
+# See configure.host and configure.ac for port_specific_symbol_files.
 @ENABLE_SYMVERS_TRUE@libstdc++-symbols.ver:  ${glibcxx_srcdir}/$(SYMVER_FILE) \
 @ENABLE_SYMVERS_TRUE@  $(port_specific_symbol_files)
 @ENABLE_SYMVERS_TRUE@  cp ${glibcxx_srcdir}/$(SYMVER_FILE) $@.tmp
-- 
2.39.2

[committed] libstdc++: Fix preprocessor condition for inline variables

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

Although variable templates are valid in C++14, inline ones aren't.
These are only used in C++17 (or later) code, so they don't need to be
defined for C++14.

libstdc++-v3/ChangeLog:

* include/bits/chrono.h (__is_duration_v, __is_time_point_v):
Only define for C++17 and later.
---
 libstdc++-v3/include/bits/chrono.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/bits/chrono.h 
b/libstdc++-v3/include/bits/chrono.h
index b2e4f4c33a8..fb99fe5eed7 100644
--- a/libstdc++-v3/include/bits/chrono.h
+++ b/libstdc++-v3/include/bits/chrono.h
@@ -244,7 +244,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   using __disable_if_is_duration
= typename enable_if::value, _Tp>::type;
 
-#if __cpp_variable_templates
+#if __cplusplus >= 201703L
 template
   inline constexpr bool __is_duration_v = false;
 template
-- 
2.39.2

[committed] libstdc++: Add assertions to std::mask_array operations [PR62196]

[Jonathan Wakely via Gcc-patches]

The PR has an example where we currently just read off the end of a heap
buffer. We can check the preconditions and assert instead.

Tested x86_64-linux. Pushed to trunk.

-- >8 --

Add assertions to diagnose incorrect uses of valarray masks.

The assignment operators of std::mask_array do not have any explicit
preconditions in the standard, but the assignment operator
valarray::operator=(const mask_array&) requires the lengths to
match, so it seems consistent to also require that when the operands are
reversed.  In support of that interpretation, libstdc++ has undefined
behaviour if the right-hand operand has more elements than are selected
by the mask, and libc++ has undefined behaviour if it has fewer
elements. Our std::mask_array stores the number of selected elements as
_M_sz so it's easy to add an assertion that checks it.

For the valarray::operator[] that takes a valarray mask,
[valarray.sub] in the standard says: "In each case the selected
element(s) shall exist." This makes it undefined to have a mask that
refers to out-of-range elements. We can easily check this too.

libstdc++-v3/ChangeLog:

PR libstdc++/62196
* include/bits/mask_array.h (mask_array): Add assertions to
assignment operators.
* include/std/valarray (valarray::operator[](valarray)):
Add assertions.
* testsuite/26_numerics/valarray/mask-1_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-2_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-3_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-4_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-5_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-6_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-7_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-8_neg.cc: New test.
* testsuite/26_numerics/valarray/mask.cc: New test.
---
 libstdc++-v3/include/bits/mask_array.h| 13 -
 libstdc++-v3/include/std/valarray |  2 +
 .../26_numerics/valarray/mask-1_neg.cc| 16 +++
 .../26_numerics/valarray/mask-2_neg.cc| 16 +++
 .../26_numerics/valarray/mask-3_neg.cc| 19 
 .../26_numerics/valarray/mask-4_neg.cc| 18 +++
 .../26_numerics/valarray/mask-5_neg.cc| 19 
 .../26_numerics/valarray/mask-6_neg.cc| 19 
 .../26_numerics/valarray/mask-7_neg.cc| 18 +++
 .../26_numerics/valarray/mask-8_neg.cc| 18 +++
 .../testsuite/26_numerics/valarray/mask.cc| 47 +++
 11 files changed, 203 insertions(+), 2 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-1_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-2_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-3_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-4_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-5_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-6_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-7_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask-8_neg.cc
 create mode 100644 libstdc++-v3/testsuite/26_numerics/valarray/mask.cc

diff --git a/libstdc++-v3/include/bits/mask_array.h 
b/libstdc++-v3/include/bits/mask_array.h
index 657ab43fa7b..d4112a9d0a3 100644
--- a/libstdc++-v3/include/bits/mask_array.h
+++ b/libstdc++-v3/include/bits/mask_array.h
@@ -153,6 +153,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline mask_array<_Tp>&
 mask_array<_Tp>::operator=(const mask_array<_Tp>& __a)
 {
+  __glibcxx_assert(__a._M_sz == _M_sz);
   std::__valarray_copy(__a._M_array, __a._M_mask,
   _M_sz, _M_array, _M_mask);
   return *this;
@@ -166,13 +167,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 inline void
 mask_array<_Tp>::operator=(const valarray<_Tp>& __v) const
-{ std::__valarray_copy(_Array<_Tp>(__v), __v.size(), _M_array, _M_mask); }
+{
+  __glibcxx_assert(__v.size() == _M_sz);
+  std::__valarray_copy(_Array<_Tp>(__v), __v.size(), _M_array, _M_mask);
+}
 
   template
 template
   inline void
   mask_array<_Tp>::operator=(const _Expr<_Ex, _Tp>& __e) const
-  { std::__valarray_copy(__e, __e.size(), _M_array, _M_mask); }
+  {
+   __glibcxx_assert(__e.size() == _M_sz);
+   std::__valarray_copy(__e, __e.size(), _M_array, _M_mask);
+  }
 
 #undef _DEFINE_VALARRAY_OPERATOR
 #define _DEFINE_VALARRAY_OPERATOR(_Op, _Name)  \
@@ -180,6 +187,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline void
\
 mask_array<_Tp>::operator _Op##=(const valarray<_Tp>& __v) const   \
 {  \
+  

[PATCH][committed][testsuite]: move mla_1 test to aarch64 only [PR109118]

[Tamar Christina via Gcc-patches]

Hi All,

I previously made the test generic, but there's no list
of targets that support integer MLA, and so it's not
really feasible for me to make this generic.

As such I've moved it to be AArch64 only.

committed under the obvious rule.

Thanks,
Tamar

gcc/testsuite/ChangeLog:

PR testsuite/109118
* gcc.dg/mla_1.c: Moved to...
* gcc.target/aarch64/sve/mla_3.c: ...here.

--- inline copy of patch -- 
diff --git a/gcc/testsuite/gcc.dg/mla_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/mla_3.c
similarity index 78%
rename from gcc/testsuite/gcc.dg/mla_1.c
rename to gcc/testsuite/gcc.target/aarch64/sve/mla_3.c
index 
98e5808ee7005e3e5c1b2d5688bfaf267a4d66ce..25e99f7d72a2fd5be0cdf9a8e9d9edddf22c40cb
 100644
--- a/gcc/testsuite/gcc.dg/mla_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/mla_3.c
@@ -1,6 +1,5 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -msve-vector-bits=256 -march=armv8.2-a+sve 
-fdump-tree-optimized" { target aarch64*-*-* } } */
+/* { dg-options "-O2 -msve-vector-bits=256 -march=armv8.2-a+sve 
-fdump-tree-optimized" } */
 
 unsigned int
 f1 (unsigned int a, unsigned int b, unsigned int c) {
@@ -37,4 +36,4 @@ g3 (vec a, vec b, vec c)
   return a * b + c;
 }
 
-/* { dg-final { scan-tree-dump-times {\.FMA } 1 "optimized" { target 
aarch64*-*-* } } } */
+/* { dg-final { scan-tree-dump-times {\.FMA } 1 "optimized" } } */




-- 
diff --git a/gcc/testsuite/gcc.dg/mla_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/mla_3.c
similarity index 78%
rename from gcc/testsuite/gcc.dg/mla_1.c
rename to gcc/testsuite/gcc.target/aarch64/sve/mla_3.c
index 
98e5808ee7005e3e5c1b2d5688bfaf267a4d66ce..25e99f7d72a2fd5be0cdf9a8e9d9edddf22c40cb
 100644
--- a/gcc/testsuite/gcc.dg/mla_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/mla_3.c
@@ -1,6 +1,5 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target vect_int } */
-/* { dg-options "-O2 -msve-vector-bits=256 -march=armv8.2-a+sve 
-fdump-tree-optimized" { target aarch64*-*-* } } */
+/* { dg-options "-O2 -msve-vector-bits=256 -march=armv8.2-a+sve 
-fdump-tree-optimized" } */
 
 unsigned int
 f1 (unsigned int a, unsigned int b, unsigned int c) {
@@ -37,4 +36,4 @@ g3 (vec a, vec b, vec c)
   return a * b + c;
 }
 
-/* { dg-final { scan-tree-dump-times {\.FMA } 1 "optimized" { target 
aarch64*-*-* } } } */
+/* { dg-final { scan-tree-dump-times {\.FMA } 1 "optimized" } } */

Re: [PATCH] Remove variables only used with .DEFERRED_INIT

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 14, 2023 at 10:12:58AM +, Richard Biener via Gcc-patches wrote:
> In PR109087 it was noticed that we rely on DSE to remove .DEFERRED_INIT
> when it is the only remaining use of a variable.  Since DSE is imperfect
> and even if it were not would be limited by the amount of statements to
> walk the following enhances the unused var removal pass to handle
> .DEFERRED_INIT like CLOBBERs, thus we do not keep local variables just
> because they are deferred initialized.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, for now queued
> for stage1 unless somebody thinks its applicable for GCC 13.
> 
>   * tree-ssa-live.cc (remove_unused_locals): Do not treat
>   the .DEFERRED_INIT of a variable as use, instead remove
>   that if it is the only use.
> 
>   * gcc.dg/auto-init-unused-1.c: New testcase.

Given how simple the patch is and that -ftrivial-auto-var-init= is still
a fairly new feature, I think it would be nice to commit this to GCC 13.
That option is not on by default, but when people do use it, better not
make it uselessly expensive.

LGTM.

> diff --git a/gcc/testsuite/gcc.dg/auto-init-unused-1.c 
> b/gcc/testsuite/gcc.dg/auto-init-unused-1.c
> new file mode 100644
> index 000..b7d44e6b4f2
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/auto-init-unused-1.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O -ftrivial-auto-var-init=zero -fdump-tree-ssa" } */
> +
> +int a;
> +int foo (void);
> +int bar (void);
> +
> +void
> +baz (void)
> +{
> +  int *b[6];
> +  if (foo ())
> +a |= bar ();
> +}
> +
> +/* { dg-final { scan-tree-dump-not "DEFERRED_INIT" "ssa" } } */
> diff --git a/gcc/tree-ssa-live.cc b/gcc/tree-ssa-live.cc
> index c179444e8e1..9118e82b4f1 100644
> --- a/gcc/tree-ssa-live.cc
> +++ b/gcc/tree-ssa-live.cc
> @@ -813,6 +813,12 @@ remove_unused_locals (void)
> continue;
>   }
>  
> +   if (gimple_call_internal_p (stmt, IFN_DEFERRED_INIT))
> + {
> +   have_local_clobbers = true;
> +   continue;
> + }
> +
> if (b)
>   TREE_USED (b) = true;
>  
> @@ -856,7 +862,7 @@ remove_unused_locals (void)
>   to remove them if they are the only references to a local variable,
>   but we want to retain them when there's any other.  So the first pass
>   ignores them, and the second pass (if there were any) tries to remove
> - them.  */
> + them.  We do the same for .DEFERRED_INIT.  */
>if (have_local_clobbers)
>  FOR_EACH_BB_FN (bb, cfun)
>{
> @@ -888,6 +894,19 @@ remove_unused_locals (void)
>   if (b)
> TREE_USED (b) = true;
> }
> + else if (gimple_call_internal_p (stmt, IFN_DEFERRED_INIT))
> +   {
> + tree lhs = gimple_call_lhs (stmt);
> + if (DECL_P (lhs) && !is_used_p (lhs))
> +   {
> + unlink_stmt_vdef (stmt);
> + gsi_remove (, true);
> + release_defs (stmt);
> + continue;
> +   }
> + if (b)
> +   TREE_USED (b) = true;
> +   }
>   else if (gimple_debug_bind_p (stmt))
> {
>   tree var = gimple_debug_bind_get_var (stmt);
> -- 
> 2.35.3

Jakub

[PATCH] Remove variables only used with .DEFERRED_INIT

[Richard Biener via Gcc-patches]

In PR109087 it was noticed that we rely on DSE to remove .DEFERRED_INIT
when it is the only remaining use of a variable.  Since DSE is imperfect
and even if it were not would be limited by the amount of statements to
walk the following enhances the unused var removal pass to handle
.DEFERRED_INIT like CLOBBERs, thus we do not keep local variables just
because they are deferred initialized.

Bootstrapped and tested on x86_64-unknown-linux-gnu, for now queued
for stage1 unless somebody thinks its applicable for GCC 13.

* tree-ssa-live.cc (remove_unused_locals): Do not treat
the .DEFERRED_INIT of a variable as use, instead remove
that if it is the only use.

* gcc.dg/auto-init-unused-1.c: New testcase.
---
 gcc/testsuite/gcc.dg/auto-init-unused-1.c | 16 
 gcc/tree-ssa-live.cc  | 21 -
 2 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/auto-init-unused-1.c

diff --git a/gcc/testsuite/gcc.dg/auto-init-unused-1.c 
b/gcc/testsuite/gcc.dg/auto-init-unused-1.c
new file mode 100644
index 000..b7d44e6b4f2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/auto-init-unused-1.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O -ftrivial-auto-var-init=zero -fdump-tree-ssa" } */
+
+int a;
+int foo (void);
+int bar (void);
+
+void
+baz (void)
+{
+  int *b[6];
+  if (foo ())
+a |= bar ();
+}
+
+/* { dg-final { scan-tree-dump-not "DEFERRED_INIT" "ssa" } } */
diff --git a/gcc/tree-ssa-live.cc b/gcc/tree-ssa-live.cc
index c179444e8e1..9118e82b4f1 100644
--- a/gcc/tree-ssa-live.cc
+++ b/gcc/tree-ssa-live.cc
@@ -813,6 +813,12 @@ remove_unused_locals (void)
  continue;
}
 
+ if (gimple_call_internal_p (stmt, IFN_DEFERRED_INIT))
+   {
+ have_local_clobbers = true;
+ continue;
+   }
+
  if (b)
TREE_USED (b) = true;
 
@@ -856,7 +862,7 @@ remove_unused_locals (void)
  to remove them if they are the only references to a local variable,
  but we want to retain them when there's any other.  So the first pass
  ignores them, and the second pass (if there were any) tries to remove
- them.  */
+ them.  We do the same for .DEFERRED_INIT.  */
   if (have_local_clobbers)
 FOR_EACH_BB_FN (bb, cfun)
   {
@@ -888,6 +894,19 @@ remove_unused_locals (void)
if (b)
  TREE_USED (b) = true;
  }
+   else if (gimple_call_internal_p (stmt, IFN_DEFERRED_INIT))
+ {
+   tree lhs = gimple_call_lhs (stmt);
+   if (DECL_P (lhs) && !is_used_p (lhs))
+ {
+   unlink_stmt_vdef (stmt);
+   gsi_remove (, true);
+   release_defs (stmt);
+   continue;
+ }
+   if (b)
+ TREE_USED (b) = true;
+ }
else if (gimple_debug_bind_p (stmt))
  {
tree var = gimple_debug_bind_get_var (stmt);
-- 
2.35.3

Re: [PATCH] i386:Add missing OPTION_MASK_ISA_AVX512VL in i386-builtin.def for VAES builtins

[Hongtao Liu via Gcc-patches]

On Tue, Mar 14, 2023 at 4:52 PM Hu, Lin1 via Gcc-patches
 wrote:
>
> It has regtested on x86_64-pc-linux-gnu. OK for trunk?
I think uros has approved your patch.
>
> Thanks.
> Lin
>
> -Original Message-
> From: Uros Bizjak 
> Sent: Tuesday, March 14, 2023 3:05 PM
> To: Hu, Lin1 
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao 
> Subject: Re: [PATCH] i386:Add missing OPTION_MASK_ISA_AVX512VL in 
> i386-builtin.def for VAES builtins
>
> On Tue, Mar 14, 2023 at 7:2 AM Hu, Lin1  wrote:
> >
> > The implementation of these builtins requires support for both
> > AVX512VL and VAES. However, the builtins didn't request AVX512VL. As a
> > result, compiling pr109117-1.c with the options -mvaes -mno-avx512vl caused 
> > an ICE.
> >
> > This patch aims to fix the bug.
> >
> > gcc/ChangeLog:
> >
> > PR target/109117
> > * config/i386/i386-builtin.def (__builtin_ia32_vaesdec_v16qi,
> > __builtin_ia32_vaesdeclast_v16qi,__builtin_ia32_vaesenc_v16qi,
> > __builtin_ia32_vaesenclast_v16qi): Require OPTION_MASK_ISA_AVX512VL.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR target/109117
> > * gcc.target/i386/pr109117-1.c: New test.
>
> OK.
>
> Thanks,
> Uros.
>
> > ---
> >  gcc/config/i386/i386-builtin.def   |  8 
> >  gcc/testsuite/gcc.target/i386/pr109117-1.c | 14 ++
> >  2 files changed, 18 insertions(+), 4 deletions(-)  create mode 100644
> > gcc/testsuite/gcc.target/i386/pr109117-1.c
> >
> > diff --git a/gcc/config/i386/i386-builtin.def
> > b/gcc/config/i386/i386-builtin.def
> > index f1c295c34f6..17dfe40fac7 100644
> > --- a/gcc/config/i386/i386-builtin.def
> > +++ b/gcc/config/i386/i386-builtin.def
> > @@ -2797,16 +2797,16 @@ BDESC (0, OPTION_MASK_ISA2_AVX5124VNNIW,
> > CODE_FOR_avx5124vnniw_vp4dpwssds_mask,
> >  BDESC (0, OPTION_MASK_ISA2_RDPID, CODE_FOR_rdpid,
> > "__builtin_ia32_rdpid", IX86_BUILTIN_RDPID, UNKNOWN, (int)
> > UNSIGNED_FTYPE_VOID)
> >
> >  /* VAES.  */
> > -BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v16qi,
> > "__builtin_ia32_vaesdec_v16qi", IX86_BUILTIN_VAESDEC16, UNKNOWN, (int)
> > V16QI_FTYPE_V16QI_V16QI)
> > +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES,
> > +CODE_FOR_vaesdec_v16qi, "__builtin_ia32_vaesdec_v16qi",
> > +IX86_BUILTIN_VAESDEC16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> >  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v32qi,
> > "__builtin_ia32_vaesdec_v32qi", IX86_BUILTIN_VAESDEC32, UNKNOWN, (int)
> > V32QI_FTYPE_V32QI_V32QI)  BDESC (0, OPTION_MASK_ISA2_VAES,
> > CODE_FOR_vaesdec_v64qi, "__builtin_ia32_vaesdec_v64qi",
> > IX86_BUILTIN_VAESDEC64, UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI) -BDESC
> > (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v16qi,
> > "__builtin_ia32_vaesdeclast_v16qi", IX86_BUILTIN_VAESDECLAST16,
> > UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> > +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES,
> > +CODE_FOR_vaesdeclast_v16qi, "__builtin_ia32_vaesdeclast_v16qi",
> > +IX86_BUILTIN_VAESDECLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> >  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v32qi,
> > "__builtin_ia32_vaesdeclast_v32qi", IX86_BUILTIN_VAESDECLAST32,
> > UNKNOWN, (int) V32QI_FTYPE_V32QI_V32QI)  BDESC (0,
> > OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v64qi,
> > "__builtin_ia32_vaesdeclast_v64qi", IX86_BUILTIN_VAESDECLAST64,
> > UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI) -BDESC (0,
> > OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v16qi,
> > "__builtin_ia32_vaesenc_v16qi", IX86_BUILTIN_VAESENC16, UNKNOWN, (int)
> > V16QI_FTYPE_V16QI_V16QI)
> > +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES,
> > +CODE_FOR_vaesenc_v16qi, "__builtin_ia32_vaesenc_v16qi",
> > +IX86_BUILTIN_VAESENC16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> >  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v32qi,
> > "__builtin_ia32_vaesenc_v32qi", IX86_BUILTIN_VAESENC32, UNKNOWN, (int)
> > V32QI_FTYPE_V32QI_V32QI)  BDESC (0, OPTION_MASK_ISA2_VAES,
> > CODE_FOR_vaesenc_v64qi, "__builtin_ia32_vaesenc_v64qi",
> > IX86_BUILTIN_VAESENC64, UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI) -BDESC
> > (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v16qi,
> > "__builtin_ia32_vaesenclast_v16qi", IX86_BUILTIN_VAESENCLAST16,
> > UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> > +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES,
> > +CODE_FOR_vaesenclast_v16qi, "__builtin_ia32_vaesenclast_v16qi",
> > +IX86_BUILTIN_VAESENCLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> >  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v32qi,
> > "__builtin_ia32_vaesenclast_v32qi", IX86_BUILTIN_VAESENCLAST32,
> > UNKNOWN, (int) V32QI_FTYPE_V32QI_V32QI)  BDESC (0,
> > OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v64qi,
> > "__builtin_ia32_vaesenclast_v64qi", IX86_BUILTIN_VAESENCLAST64,
> > UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI)
> >
> > diff --git a/gcc/testsuite/gcc.target/i386/pr109117-1.c
> > b/gcc/testsuite/gcc.target/i386/pr109117-1.c
> > new file mode 100644
> > index 000..87a5c0e7fc9
> > --- /dev/null

Re: [PATCH v4 1/2] RISC-V: Avoid calloc() poisoning on musl

[Richard Biener via Gcc-patches]

On Tue, Mar 14, 2023 at 1:24 AM Sam James via Gcc-patches
 wrote:
>
> This fixes errors like:
> ```
> In file included from /usr/include/pthread.h:30,
>  from 
> /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr-default.h:35,
>  from 
> /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/riscv64-gentoo-linux-musl/bits/gthr.h:148,
>  from 
> /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ext/atomicity.h:35,
>  from 
> /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/bits/ios_base.h:39,
>  from 
> /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/ios:42,
>  from 
> /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/istream:38,
>  from 
> /usr/lib/gcc/riscv64-gentoo-linux-musl/12/include/g++-v12/sstream:38,
>  from 
> /var/tmp/portage/sys-devel/gcc-13.0.1_pre20230305/work/gcc-13-20230305/gcc/config/riscv/genrvv-type-indexer.cc:22:
> /usr/include/sched.h:84:7: error: attempt to use poisoned "calloc"
>84 | void *calloc(size_t, size_t);
>   |   ^
> /usr/include/sched.h:124:36: error: attempt to use poisoned "calloc"
>   124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
>   |^
> make[3]: *** [Makefile:2855: build/genrvv-type-indexer.o] Error 1
> ```
>
> See also 3b21c21f3f5726823e19728fdd1571a14aae0fb3 and 
> 49d508065bdd36fb1a9b6aad9666b1edb5e06474,
> which was fixed in PR106102.

The system.h change is OK

> gcc/ChangeLog:
> * config/riscv/genrvv-type-indexer.cc: Avoid calloc() poisoning on 
> musl by
> including  earlier.
> * system.h: Add INCLUDE_SSTREAM.
>
> Signed-off-by: Sam James 
> ---
>  gcc/config/riscv/genrvv-type-indexer.cc | 2 +-
>  gcc/system.h| 4 
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/genrvv-type-indexer.cc 
> b/gcc/config/riscv/genrvv-type-indexer.cc
> index 0ef1d766002..e677b55290c 100644
> --- a/gcc/config/riscv/genrvv-type-indexer.cc
> +++ b/gcc/config/riscv/genrvv-type-indexer.cc
> @@ -14,12 +14,12 @@ along with GCC; see the file COPYING3.  If not see
>  .  */
>
>  #include "bconfig.h"
> +#define INCLUDE_SSTREAM
>  #include "system.h"
>  #include "errors.h"
>
>  #include "coretypes.h"
>
> -#include 
>  #include 
>  #include 
>
> diff --git a/gcc/system.h b/gcc/system.h
> index 64cd5a49258..cf45db3f97e 100644
> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -751,6 +751,10 @@ extern int vsnprintf (char *, size_t, const char *, 
> va_list);
>  # include 
>  #endif
>
> +#ifdef INCLUDE_SSTREAM
> +# include 
> +#endif
> +
>  #ifdef INCLUDE_MALLOC_H
>  #if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
>  #include 
> --
> 2.40.0
>

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

[Richard Biener via Gcc-patches]

On Mon, 13 Mar 2023, Qing Zhao wrote:

> Hi, Richard,
> 
> Do you have more comments on my responds to your previous questions?

No, generally we're not good at naming the shared bits, so keeping the
old name is fine here.

Btw, I do not feel competent enough to approve the patch, instead that's
on the burden of the C frontend maintainers and the people understanding
the object-size code more.

Richard.

> thanks.
> 
> Qing
> 
> > On Mar 10, 2023, at 8:48 AM, Qing Zhao via Gcc-patches 
> >  wrote:
> > 
> > 
> > 
> >> On Mar 10, 2023, at 2:54 AM, Richard Biener  wrote:
> >> 
> >> On Thu, 9 Mar 2023, Qing Zhao wrote:
> >> 
> >>> 
> >>> 
>  On Mar 9, 2023, at 7:20 AM, Richard Biener  wrote:
>  
>  On Fri, 24 Feb 2023, Qing Zhao wrote:
>  
> > GCC extension accepts the case when a struct with a C99 flexible array 
> > member
> > is embedded into another struct or union (possibly recursively).
> > __builtin_object_size should treat such struct as flexible size.
> > 
> > gcc/c/ChangeLog:
> > 
> > PR tree-optimization/101832
> > * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for
> > struct/union type.
>  
>  I can't really comment on the correctness of this part but since
>  only the C frontend will ever set this and you are using it from
>  addr_object_size which is also used for other C family languages
>  (at least), I wonder if you can really test
>  
>  +   if (!TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (v)))
>  
>  there.
> >>> 
> >>> You mean for C++ and also other C family languages (other than C), the 
> >>> above bit cannot be set?
> >>> Yes, that’s true. The bit is only set for C. So is the bit 
> >>> DECL_NOT_FLEXARRAY, which is only set for C too. 
> >>> So, I am wondering whether the bit DECL_NOT_FLEXARRAY should be also set 
> >>> in middle end? Or we can set DECL_NOT_FLEXARRAY in C++ FE too? And then 
> >>> we can set TYPE_INCLUDE_FLEXARRAY also in C++ FE?
> >>> What’s your suggestion?
> >>> 
> >>> (I personally feel that DECL_NOT_FLEXARRAY and TYPE_INCLUDE_FLEXARRAY 
> >>> should be set in the same places).
> >> 
> >> I was wondering if the above test errors on the conservative side
> >> correctly - it will now, for all but C, cut off some thing where it
> >> didn't before?
> > 
> > As long as the default value of TYPE_INCLUDE_FLEXARRAY reflects the correct 
> > conservative  behavior, then the testing should be correct, right?
> > 
> > The default value of TYPE_INCLUDE_FLEXARRAY is 0, i.e, FALSE, means that 
> > the TYPE does not include a flex array by default, this is the correct 
> > behavior. Only when the TYPE does include a flexiarray, it will be set to 
> > TRUE. So, I think it’s correct.
> > 
> > This is a different situation for DECL_NOT_FLEXARRAY, by default, the 
> > compiler will treat ALL trailing arrays as FMA, so in order to keep the 
> > correct conservative behavior, we should keep the default value for 
> > DECL_NOT_FLEXARRAY as it’s a FMA, i.e, DECL_NOT_FLEXARRAY being FALSE, by 
> > default. Only when the array is NOT a FMA, we set it to true. 
> > 
> > So, the default value for TYPE_INCLUDE_FLEXARRAY is correct. 
> >> 
>  
>  Originally I was suggesting to set this flag in stor-layout.cc
>  which eventually all languages funnel their types through and
>  if there's language specific handling use a langhook (with the
>  default implementation preserving the status quo).
> >>> 
> >>> If we decide to set the bits in stor-layout.cc, where is the best place 
> >>> to do it? I checked the star-layout.cc code, looks like “layout_type” 
> >>> might be the place where we can set these bits for RECORD_TYPE, 
> >>> UNION_TYPE? 
> >> 
> >> Yes, it would be layout_type.
> >> 
>  
>  Some more comments below ...
>  
> > gcc/cp/ChangeLog:
> > 
> > PR tree-optimization/101832
> > * module.cc (trees_out::core_bools): Stream out new bit
> > type_include_flexarray.
> > (trees_in::core_bools): Stream in new bit 
> > type_include_flexarray.
> > 
> > gcc/ChangeLog:
> > 
> > PR tree-optimization/101832
> > * print-tree.cc (print_node): Print new bit 
> > type_include_flexarray.
> > * tree-core.h (struct tree_type_common): New bit
> > type_include_flexarray.
> > * tree-object-size.cc (addr_object_size): Handle 
> > structure/union type
> > when it has flexible size.
> > * tree-streamer-in.cc (unpack_ts_type_common_value_fields): 
> > Stream
> > in new bit type_include_flexarray.
> > * tree-streamer-out.cc (pack_ts_type_common_value_fields): 
> > Stream
> > out new bit type_include_flexarray.
> > * tree.h (TYPE_INCLUDE_FLEXARRAY): New macro
> > TYPE_INCLUDE_FLEXARRAY.
> > 
> > 

RE: [PATCH] i386:Add missing OPTION_MASK_ISA_AVX512VL in i386-builtin.def for VAES builtins

[Hu, Lin1 via Gcc-patches]

It has regtested on x86_64-pc-linux-gnu. OK for trunk?

Thanks.
Lin

-Original Message-
From: Uros Bizjak  
Sent: Tuesday, March 14, 2023 3:05 PM
To: Hu, Lin1 
Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao 
Subject: Re: [PATCH] i386:Add missing OPTION_MASK_ISA_AVX512VL in 
i386-builtin.def for VAES builtins

On Tue, Mar 14, 2023 at 7:2 AM Hu, Lin1  wrote:
>
> The implementation of these builtins requires support for both 
> AVX512VL and VAES. However, the builtins didn't request AVX512VL. As a 
> result, compiling pr109117-1.c with the options -mvaes -mno-avx512vl caused 
> an ICE.
>
> This patch aims to fix the bug.
>
> gcc/ChangeLog:
>
> PR target/109117
> * config/i386/i386-builtin.def (__builtin_ia32_vaesdec_v16qi,
> __builtin_ia32_vaesdeclast_v16qi,__builtin_ia32_vaesenc_v16qi,
> __builtin_ia32_vaesenclast_v16qi): Require OPTION_MASK_ISA_AVX512VL.
>
> gcc/testsuite/ChangeLog:
>
> PR target/109117
> * gcc.target/i386/pr109117-1.c: New test.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/i386-builtin.def   |  8 
>  gcc/testsuite/gcc.target/i386/pr109117-1.c | 14 ++
>  2 files changed, 18 insertions(+), 4 deletions(-)  create mode 100644 
> gcc/testsuite/gcc.target/i386/pr109117-1.c
>
> diff --git a/gcc/config/i386/i386-builtin.def 
> b/gcc/config/i386/i386-builtin.def
> index f1c295c34f6..17dfe40fac7 100644
> --- a/gcc/config/i386/i386-builtin.def
> +++ b/gcc/config/i386/i386-builtin.def
> @@ -2797,16 +2797,16 @@ BDESC (0, OPTION_MASK_ISA2_AVX5124VNNIW, 
> CODE_FOR_avx5124vnniw_vp4dpwssds_mask,
>  BDESC (0, OPTION_MASK_ISA2_RDPID, CODE_FOR_rdpid, 
> "__builtin_ia32_rdpid", IX86_BUILTIN_RDPID, UNKNOWN, (int) 
> UNSIGNED_FTYPE_VOID)
>
>  /* VAES.  */
> -BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v16qi, 
> "__builtin_ia32_vaesdec_v16qi", IX86_BUILTIN_VAESDEC16, UNKNOWN, (int) 
> V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> +CODE_FOR_vaesdec_v16qi, "__builtin_ia32_vaesdec_v16qi", 
> +IX86_BUILTIN_VAESDEC16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v32qi, 
> "__builtin_ia32_vaesdec_v32qi", IX86_BUILTIN_VAESDEC32, UNKNOWN, (int) 
> V32QI_FTYPE_V32QI_V32QI)  BDESC (0, OPTION_MASK_ISA2_VAES, 
> CODE_FOR_vaesdec_v64qi, "__builtin_ia32_vaesdec_v64qi", 
> IX86_BUILTIN_VAESDEC64, UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI) -BDESC 
> (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v16qi, 
> "__builtin_ia32_vaesdeclast_v16qi", IX86_BUILTIN_VAESDECLAST16, 
> UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> +CODE_FOR_vaesdeclast_v16qi, "__builtin_ia32_vaesdeclast_v16qi", 
> +IX86_BUILTIN_VAESDECLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v32qi, 
> "__builtin_ia32_vaesdeclast_v32qi", IX86_BUILTIN_VAESDECLAST32, 
> UNKNOWN, (int) V32QI_FTYPE_V32QI_V32QI)  BDESC (0, 
> OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v64qi, 
> "__builtin_ia32_vaesdeclast_v64qi", IX86_BUILTIN_VAESDECLAST64, 
> UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI) -BDESC (0, 
> OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v16qi, 
> "__builtin_ia32_vaesenc_v16qi", IX86_BUILTIN_VAESENC16, UNKNOWN, (int) 
> V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> +CODE_FOR_vaesenc_v16qi, "__builtin_ia32_vaesenc_v16qi", 
> +IX86_BUILTIN_VAESENC16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v32qi, 
> "__builtin_ia32_vaesenc_v32qi", IX86_BUILTIN_VAESENC32, UNKNOWN, (int) 
> V32QI_FTYPE_V32QI_V32QI)  BDESC (0, OPTION_MASK_ISA2_VAES, 
> CODE_FOR_vaesenc_v64qi, "__builtin_ia32_vaesenc_v64qi", 
> IX86_BUILTIN_VAESENC64, UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI) -BDESC 
> (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v16qi, 
> "__builtin_ia32_vaesenclast_v16qi", IX86_BUILTIN_VAESENCLAST16, 
> UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> +CODE_FOR_vaesenclast_v16qi, "__builtin_ia32_vaesenclast_v16qi", 
> +IX86_BUILTIN_VAESENCLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v32qi, 
> "__builtin_ia32_vaesenclast_v32qi", IX86_BUILTIN_VAESENCLAST32, 
> UNKNOWN, (int) V32QI_FTYPE_V32QI_V32QI)  BDESC (0, 
> OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v64qi, 
> "__builtin_ia32_vaesenclast_v64qi", IX86_BUILTIN_VAESENCLAST64, 
> UNKNOWN, (int) V64QI_FTYPE_V64QI_V64QI)
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr109117-1.c 
> b/gcc/testsuite/gcc.target/i386/pr109117-1.c
> new file mode 100644
> index 000..87a5c0e7fc9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr109117-1.c
> @@ -0,0 +1,14 @@
> +/* PR target/109117 */
> +/* { dg-do compile } */
> +/* { dg-options "-mvaes -mno-avx512vl" } */
> +
> +typedef char __v16qi __attribute__ ((__vector_size__(16))); typedef 
> +long long __m128i 

Fix ICE in profile_count::to_sreal_frequency

[Jan Hubicka via Gcc-patches]

As discussed in the PR log, profile_count::to_cgraph_frequency was originally
intended to work across function boundary and has some extra logic and sanity
check for that.  It is used only within single function and with current
API it can not really work well globally, so this patch synchronizes its
implementation with probability_in which does similar job but to determine
relative probability.

Bootstrpped/regtested x86_64-linux, and also profilebootstrapped. Comitted.

gcc/ChangeLog:

2023-03-14  Jan Hubicka  

PR tree-optimization/106896
* profile-count.cc (profile_count::to_sreal_scale): Synchronize
implementatoin with probability_in; avoid some asserts.

diff --git a/gcc/profile-count.cc b/gcc/profile-count.cc
index d05fef3fb00..16585045f8e 100644
--- a/gcc/profile-count.cc
+++ b/gcc/profile-count.cc
@@ -325,6 +325,13 @@ profile_count::to_cgraph_frequency (profile_count 
entry_bb_count) const
 sreal
 profile_count::to_sreal_scale (profile_count in, bool *known) const
 {
+  if (*this == zero ()
+  && !(in == zero ()))
+  {
+if (known)
+  *known = true;
+return 0;
+  }
   if (!initialized_p () || !in.initialized_p ())
 {
   if (known)
@@ -333,32 +340,13 @@ profile_count::to_sreal_scale (profile_count in, bool 
*known) const
 }
   if (known)
 *known = true;
-  /* Watch for cases where one count is IPA and other is not.  */
-  if (in.ipa ().initialized_p ())
-{
-  gcc_checking_assert (ipa ().initialized_p ());
-  /* If current count is inter-procedurally 0 and IN is inter-procedurally
-non-zero, return 0.  */
-  if (in.ipa ().nonzero_p ()
- && !ipa().nonzero_p ())
-   return 0;
-}
-  else 
-/* We can handle correctly 0 IPA count within locally estimated
-   profile, but otherwise we are lost and this should not happen.   */
-gcc_checking_assert (!ipa ().initialized_p () || !ipa ().nonzero_p ());
-  if (*this == zero ())
-return 0;
-  if (m_val == in.m_val)
+  if (*this == in)
 return 1;
   gcc_checking_assert (compatible_p (in));
-
+  if (m_val == in.m_val)
+return 1;
   if (!in.m_val)
-{
-  if (!m_val)
-   return 1;
-  return m_val * 4;
-}
+return m_val * 4;
   return (sreal)m_val / (sreal)in.m_val;
 }
 

Re: [PATCH] tree-vect-patterns: Fix up ICE in upper_bound [PR109115]

[Richard Biener via Gcc-patches]

On Tue, 14 Mar 2023, Jakub Jelinek wrote:

> Hi!
> 
> As mentioned in the PR, range_of_expr returns false if the type
> of the expression isn't suitable for corresponding range type,
> but doesn't if the range is undefined for other reasons.  Still,
> lower/upper_bound is defined only for ranges which actually have
> at least one pair of subranges, VR_UNDEFINED range doesn't have it.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?

OK.

> 2023-03-14  Jakub Jelinek  
> 
>   PR tree-optimization/109115
>   * tree-vect-patterns.cc (vect_recog_divmod_pattern): Don't use
>   r.upper_bound () on r.undefined_p () range.
> 
>   * gcc.dg/pr109115.c: New test.
> 
> --- gcc/tree-vect-patterns.cc.jj  2023-03-12 22:36:06.388177607 +0100
> +++ gcc/tree-vect-patterns.cc 2023-03-13 22:49:18.278476093 +0100
> @@ -3973,7 +3973,7 @@ vect_recog_divmod_pattern (vec_info *vin
> /* Check that no overflow will occur.  If we don't have range
>information we can't perform the optimization.  */
>  
> -   if (ranger.range_of_expr (r, oprnd0, stmt))
> +   if (ranger.range_of_expr (r, oprnd0, stmt) && !r.undefined_p ())
>   {
> wide_int max = r.upper_bound ();
> wide_int one = wi::shwi (1, prec);
> --- gcc/testsuite/gcc.dg/pr109115.c.jj2023-03-13 22:56:27.269428198 
> +0100
> +++ gcc/testsuite/gcc.dg/pr109115.c   2023-03-13 22:56:04.174753778 +0100
> @@ -0,0 +1,20 @@
> +/* PR tree-optimization/109115 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +int a, b;
> +
> +int
> +main ()
> +{
> +  unsigned short c = a, e = -1;
> +  if (b)
> +{
> +  unsigned d = (a ^ 1U) / a & c;
> +  int f = (~d >> ~a) / e;
> +  if (a)
> + f = a;
> +  a = f;
> +}
> +  return 0;
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

[PATCH] tree-vect-patterns: Fix up ICE in upper_bound [PR109115]

[Jakub Jelinek via Gcc-patches]

Hi!

As mentioned in the PR, range_of_expr returns false if the type
of the expression isn't suitable for corresponding range type,
but doesn't if the range is undefined for other reasons.  Still,
lower/upper_bound is defined only for ranges which actually have
at least one pair of subranges, VR_UNDEFINED range doesn't have it.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

2023-03-14  Jakub Jelinek  

PR tree-optimization/109115
* tree-vect-patterns.cc (vect_recog_divmod_pattern): Don't use
r.upper_bound () on r.undefined_p () range.

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

--- gcc/tree-vect-patterns.cc.jj2023-03-12 22:36:06.388177607 +0100
+++ gcc/tree-vect-patterns.cc   2023-03-13 22:49:18.278476093 +0100
@@ -3973,7 +3973,7 @@ vect_recog_divmod_pattern (vec_info *vin
  /* Check that no overflow will occur.  If we don't have range
 information we can't perform the optimization.  */
 
- if (ranger.range_of_expr (r, oprnd0, stmt))
+ if (ranger.range_of_expr (r, oprnd0, stmt) && !r.undefined_p ())
{
  wide_int max = r.upper_bound ();
  wide_int one = wi::shwi (1, prec);
--- gcc/testsuite/gcc.dg/pr109115.c.jj  2023-03-13 22:56:27.269428198 +0100
+++ gcc/testsuite/gcc.dg/pr109115.c 2023-03-13 22:56:04.174753778 +0100
@@ -0,0 +1,20 @@
+/* PR tree-optimization/109115 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int a, b;
+
+int
+main ()
+{
+  unsigned short c = a, e = -1;
+  if (b)
+{
+  unsigned d = (a ^ 1U) / a & c;
+  int f = (~d >> ~a) / e;
+  if (a)
+   f = a;
+  a = f;
+}
+  return 0;
+}

Jakub

[PATCH] c++: Treat unnamed bitfields as padding for __has_unique_object_representations [PR109096]

[Jakub Jelinek via Gcc-patches]

Hi!

As reported in the PR, for __has_unique_object_representations we
were treating unnamed bitfields as named ones, which is wrong, they
are actually padding.

THe following patch fixes that.  Ok for trunk (and what about release
branches later?)?

2023-03-14  Jakub Jelinek  

PR c++/109096
* tree.cc (record_has_unique_obj_representations): Ignore unnamed
bitfields.

* g++.dg/cpp1z/has-unique-obj-representations3.C: New test.

--- gcc/cp/tree.cc.jj   2023-03-10 10:06:40.247560614 +0100
+++ gcc/cp/tree.cc  2023-03-13 10:38:03.394836926 +0100
@@ -4851,7 +4851,7 @@ record_has_unique_obj_representations (c
DECL_SIZE (field)))
  return false;
   }
-else if (DECL_C_BIT_FIELD (field))
+else if (DECL_C_BIT_FIELD (field) && !DECL_UNNAMED_BIT_FIELD (field))
   {
tree btype = DECL_BIT_FIELD_TYPE (field);
if (!type_has_unique_obj_representations (btype))
@@ -4862,7 +4862,7 @@ record_has_unique_obj_representations (c
 
   offset_int cur = 0;
   for (tree field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
-if (TREE_CODE (field) == FIELD_DECL)
+if (TREE_CODE (field) == FIELD_DECL && !DECL_UNNAMED_BIT_FIELD (field))
   {
offset_int fld = wi::to_offset (DECL_FIELD_OFFSET (field));
offset_int bitpos = wi::to_offset (DECL_FIELD_BIT_OFFSET (field));
--- gcc/testsuite/g++.dg/cpp1z/has-unique-obj-representations3.C.jj 
2023-03-13 10:50:21.705127719 +0100
+++ gcc/testsuite/g++.dg/cpp1z/has-unique-obj-representations3.C
2023-03-13 10:50:17.751185067 +0100
@@ -0,0 +1,10 @@
+// PR c++/109096
+// { dg-do compile { target c++11 } }
+
+#define INTB (__SIZEOF_INT__ * __CHAR_BIT__)
+struct U { int i : INTB * 3 / 4; int : INTB / 4; };
+struct V { int : INTB * 3 / 4; int j : INTB / 4; };
+struct W { int i; int : 0; int j; };
+static_assert (__has_unique_object_representations (U) == false, "");
+static_assert (__has_unique_object_representations (V) == false, "");
+static_assert (sizeof (W) != 2 * sizeof (int) || 
__has_unique_object_representations (W) == true, "");

Jakub

[PATCH] testsuite: Fix up g++.dg/cpp2a/concepts-lambda3.C [PR108972]

[Jakub Jelinek via Gcc-patches]

Hi!

On Fri, Mar 10, 2023 at 01:49:38PM -0500, Jason Merrill via Gcc-patches wrote:
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp2a/concepts-lambda3.C: Run at lower std levels,
>   but expect errors.

I'm seeing
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++11 compilation failed to 
produce executable
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++14 compilation failed to 
produce executable
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++17 compilation failed to 
produce executable
+UNRESOLVED: g++.dg/cpp2a/concepts-lambda3.C  -std=c++98 compilation failed to 
produce executable
with this change, and if I test with
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++ -k 
RUNTESTFLAGS="--target_board=unix\{-m32,-m64,-m64/-fconcepts\} 
dg.exp=concepts-lambda3.C"
I see even FAILs for the -fconcepts case, so apparently even -std=c++17
-fconcepts isn't enough to make it compile without errors.

The following patch will expect errors for all of c++17_down and will
make the test dg-do compile for that case too, such that the UNRESOLVED
stuff is gone.

Ok for trunk?

2023-03-14  Jakub Jelinek  

PR c++/108972
* g++.dg/cpp2a/concepts-lambda3.C: Use dg-do run only for c++20,
for c++17_down dg-do compile.  Expect dg-excess-errors for c++17_down
rather than ! concepts.

--- gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C.jj2023-03-13 
23:01:42.082959131 +0100
+++ gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C   2023-03-14 
08:48:12.834128044 +0100
@@ -1,5 +1,6 @@
-// { dg-do run }
-// { dg-excess-errors "" { target { ! concepts } } } (PR108972)
+// { dg-do run { target c++20 } }
+// { dg-do compile { target c++17_down } }
+// { dg-excess-errors "" { target { c++17_down } } } (PR108972)
 
 template
 concept C1 = __is_same_as(T, int)


Jakub

Re: [PATCH]middle-end: don't form FMAs when multiplication is not single use. [PR108583]

[Jakub Jelinek via Gcc-patches]

On Thu, Mar 09, 2023 at 07:36:21PM +, Tamar Christina via Gcc-patches wrote:
>   PR target/108583
>   * gcc.dg/mla_1.c: New test.

The testcase FAILs on all targets but AArch64 (maybe ARM is fine too).
While f1/g1 are compilable on all targets and f3/g3 with -Wno-psabi in
dg-options, f2/g2 are AArch64 specific.  So, I think either
the testcase should be moved to gcc.target/aarch64/ as whole,
or you should split it, have gcc.dg/mla_1.c contain everything but
f2/g2, drop vect_int requires and change dg-options to "-O2 -Wno-psabi",
and then gcc.target/aarch64/mla_1.c which has the dg- directives as you
currently have and #include "../../gcc.dg/mla_1.c" to get the functions
+ add f2/g2.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/mla_1.c
> @@ -0,0 +1,40 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target vect_int } */
> +/* { dg-options "-O2 -msve-vector-bits=256 -march=armv8.2-a+sve 
> -fdump-tree-optimized" } */
> +
> +unsigned int
> +f1 (unsigned int a, unsigned int b, unsigned int c) {
> +  unsigned int d = a * b;
> +  return d + ((c + d) >> 1);
> +}
> +
> +unsigned int
> +g1 (unsigned int a, unsigned int b, unsigned int c) {
> +  return a * b + c;
> +}
> +
> +__Uint32x4_t
> +f2 (__Uint32x4_t a, __Uint32x4_t b, __Uint32x4_t c) {
> +  __Uint32x4_t d = a * b;
> +  return d + ((c + d) >> 1);
> +}
> +
> +__Uint32x4_t
> +g2 (__Uint32x4_t a, __Uint32x4_t b, __Uint32x4_t c) {
> +  return a * b + c;
> +}
> +
> +typedef unsigned int vec __attribute__((vector_size(32))); vec
> +f3 (vec a, vec b, vec c)
> +{
> +  vec d = a * b;
> +  return d + ((c + d) >> 1);
> +}
> +
> +vec
> +g3 (vec a, vec b, vec c)
> +{
> +  return a * b + c;
> +}
> +
> +/* { dg-final { scan-tree-dump-times {\.FMA } 1 "optimized" { target 
> aarch64*-*-* } } } */

Jakub

[PATCH] New testcase

[Richard Biener via Gcc-patches]

This is a reduced testcase for an issue I ran into when trying to
improve PTA compile-time further, there wasn't any C family runfail
in the testsuite for this.

Pushed.

* g++.dg/torture/20230313.C: New testcase.
---
 gcc/testsuite/g++.dg/torture/20230313.C | 109 
 1 file changed, 109 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/torture/20230313.C

diff --git a/gcc/testsuite/g++.dg/torture/20230313.C 
b/gcc/testsuite/g++.dg/torture/20230313.C
new file mode 100644
index 000..d1f348003bd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/20230313.C
@@ -0,0 +1,109 @@
+/* { dg-do run } */
+/* { dg-additional-options "-fno-exceptions -fno-rtti" } */
+
+extern "C" void free (void *);
+void fancy_abort () { __builtin_abort (); }
+struct vec_prefix
+{
+  unsigned m_alloc : 1;
+  unsigned m_using_auto_storage : 1;
+  unsigned m_num;
+};
+struct vl_ptr
+;
+struct va_heap
+{
+  typedef vl_ptr default_layout;
+};
+template
+struct vec
+;
+template
+struct vec
+{
+  T & operator[] (unsigned ix)
+{
+  int *__trans_tmp_2;
+  !m_vecpfx.m_num ? fancy_abort (), 0 : 0;
+  __trans_tmp_2 =  reinterpret_cast  (this + 1);
+  return __trans_tmp_2[ix];
+}
+  bool iterate (unsigned , T *ptr) {
+  *ptr = 0;
+  return false;
+  }
+  void embedded_init (unsigned , unsigned num, unsigned aut)
+{
+  m_vecpfx.m_alloc =
+ m_vecpfx.m_using_auto_storage = aut;
+  m_vecpfx.m_num = num;
+}
+  void quick_grow (unsigned len)
+{
+  !m_vecpfx.m_alloc ? fancy_abort (), 0 : m_vecpfx.m_num = len;
+}
+  vec_prefix m_vecpfx;
+};
+template
+struct auto_vec : vec
+{
+  auto_vec ()
+  {
+m_auto.embedded_init (N, 0, 1);
+long off = (char *) _auto - (char *) this;
+this->m_vec = (vec *) ((char *) this + off);
+  }
+  ~auto_vec ()
+  {
+this->release ();
+  }
+  vec m_auto;
+  char m_data;
+};
+template
+struct vec
+{
+void
+release ()
+{
+  bool __trans_tmp_1 =  m_vec ? m_vec->m_vecpfx.m_using_auto_storage : false;
+  if (__trans_tmp_1)
+  return;
+  vec * = m_vec;
+free (m_vec);
+v = nullptr;
+}
+T [] (unsigned ix) { return (*m_vec)[ix]; }
+bool
+iterate (unsigned ix, T *ptr) {
+m_vec->iterate (ix, ptr);
+return false;
+}
+void
+quick_grow (unsigned len)
+{
+  m_vec->quick_grow (len);
+}
+  vec *m_vec;
+};
+void test_auto_alias ()
+{
+  volatile int i = 1;
+  auto_vec v;
+  v.quick_grow (2);
+  v[0] = 1;
+  v[1] = 2;
+  int val;
+  for (int ix = i; v.iterate (ix, ); ix++)
+if (val != 2)
+  __builtin_abort ();
+  if (val != 0)
+__builtin_abort ();
+}
+int main()
+{
+  test_auto_alias ();
+  return 0;
+}
-- 
2.35.3

Re: [PATCH] i386:Add missing OPTION_MASK_ISA_AVX512VL in i386-builtin.def for VAES builtins

[Uros Bizjak via Gcc-patches]

On Tue, Mar 14, 2023 at 7:27 AM Hu, Lin1  wrote:
>
> The implementation of these builtins requires support for both AVX512VL and
> VAES. However, the builtins didn't request AVX512VL. As a result, compiling
> pr109117-1.c with the options -mvaes -mno-avx512vl caused an ICE.
>
> This patch aims to fix the bug.
>
> gcc/ChangeLog:
>
> PR target/109117
> * config/i386/i386-builtin.def (__builtin_ia32_vaesdec_v16qi,
> __builtin_ia32_vaesdeclast_v16qi,__builtin_ia32_vaesenc_v16qi,
> __builtin_ia32_vaesenclast_v16qi): Require OPTION_MASK_ISA_AVX512VL.
>
> gcc/testsuite/ChangeLog:
>
> PR target/109117
> * gcc.target/i386/pr109117-1.c: New test.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/i386-builtin.def   |  8 
>  gcc/testsuite/gcc.target/i386/pr109117-1.c | 14 ++
>  2 files changed, 18 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr109117-1.c
>
> diff --git a/gcc/config/i386/i386-builtin.def 
> b/gcc/config/i386/i386-builtin.def
> index f1c295c34f6..17dfe40fac7 100644
> --- a/gcc/config/i386/i386-builtin.def
> +++ b/gcc/config/i386/i386-builtin.def
> @@ -2797,16 +2797,16 @@ BDESC (0, OPTION_MASK_ISA2_AVX5124VNNIW, 
> CODE_FOR_avx5124vnniw_vp4dpwssds_mask,
>  BDESC (0, OPTION_MASK_ISA2_RDPID, CODE_FOR_rdpid, "__builtin_ia32_rdpid", 
> IX86_BUILTIN_RDPID, UNKNOWN, (int) UNSIGNED_FTYPE_VOID)
>
>  /* VAES.  */
> -BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v16qi, 
> "__builtin_ia32_vaesdec_v16qi", IX86_BUILTIN_VAESDEC16, UNKNOWN, (int) 
> V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> CODE_FOR_vaesdec_v16qi, "__builtin_ia32_vaesdec_v16qi", 
> IX86_BUILTIN_VAESDEC16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v32qi, 
> "__builtin_ia32_vaesdec_v32qi", IX86_BUILTIN_VAESDEC32, UNKNOWN, (int) 
> V32QI_FTYPE_V32QI_V32QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v64qi, 
> "__builtin_ia32_vaesdec_v64qi", IX86_BUILTIN_VAESDEC64, UNKNOWN, (int) 
> V64QI_FTYPE_V64QI_V64QI)
> -BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v16qi, 
> "__builtin_ia32_vaesdeclast_v16qi", IX86_BUILTIN_VAESDECLAST16, UNKNOWN, 
> (int) V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> CODE_FOR_vaesdeclast_v16qi, "__builtin_ia32_vaesdeclast_v16qi", 
> IX86_BUILTIN_VAESDECLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v32qi, 
> "__builtin_ia32_vaesdeclast_v32qi", IX86_BUILTIN_VAESDECLAST32, UNKNOWN, 
> (int) V32QI_FTYPE_V32QI_V32QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v64qi, 
> "__builtin_ia32_vaesdeclast_v64qi", IX86_BUILTIN_VAESDECLAST64, UNKNOWN, 
> (int) V64QI_FTYPE_V64QI_V64QI)
> -BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v16qi, 
> "__builtin_ia32_vaesenc_v16qi", IX86_BUILTIN_VAESENC16, UNKNOWN, (int) 
> V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> CODE_FOR_vaesenc_v16qi, "__builtin_ia32_vaesenc_v16qi", 
> IX86_BUILTIN_VAESENC16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v32qi, 
> "__builtin_ia32_vaesenc_v32qi", IX86_BUILTIN_VAESENC32, UNKNOWN, (int) 
> V32QI_FTYPE_V32QI_V32QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v64qi, 
> "__builtin_ia32_vaesenc_v64qi", IX86_BUILTIN_VAESENC64, UNKNOWN, (int) 
> V64QI_FTYPE_V64QI_V64QI)
> -BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v16qi, 
> "__builtin_ia32_vaesenclast_v16qi", IX86_BUILTIN_VAESENCLAST16, UNKNOWN, 
> (int) V16QI_FTYPE_V16QI_V16QI)
> +BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
> CODE_FOR_vaesenclast_v16qi, "__builtin_ia32_vaesenclast_v16qi", 
> IX86_BUILTIN_VAESENCLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v32qi, 
> "__builtin_ia32_vaesenclast_v32qi", IX86_BUILTIN_VAESENCLAST32, UNKNOWN, 
> (int) V32QI_FTYPE_V32QI_V32QI)
>  BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v64qi, 
> "__builtin_ia32_vaesenclast_v64qi", IX86_BUILTIN_VAESENCLAST64, UNKNOWN, 
> (int) V64QI_FTYPE_V64QI_V64QI)
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr109117-1.c 
> b/gcc/testsuite/gcc.target/i386/pr109117-1.c
> new file mode 100644
> index 000..87a5c0e7fc9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr109117-1.c
> @@ -0,0 +1,14 @@
> +/* PR target/109117 */
> +/* { dg-do compile } */
> +/* { dg-options "-mvaes -mno-avx512vl" } */
> +
> +typedef char __v16qi __attribute__ ((__vector_size__(16)));
> +typedef long long __m128i __attribute__((__vector_size__(16), 
> __aligned__(16)));
> +volatile __v16qi x, y;
> +volatile __m128i res;
> +
> +void
> +foo (void)
> +{
> +  res = __builtin_ia32_vaesdec_v16qi (x, y); /* { dg-warning "implicit 
> declaration of function" } */
> +} /* { dg-error "incompatible types when assigning to type" "" { target 
> 

[PATCH] i386:Add missing OPTION_MASK_ISA_AVX512VL in i386-builtin.def for VAES builtins

[Hu, Lin1 via Gcc-patches]

The implementation of these builtins requires support for both AVX512VL and
VAES. However, the builtins didn't request AVX512VL. As a result, compiling
pr109117-1.c with the options -mvaes -mno-avx512vl caused an ICE.

This patch aims to fix the bug.

gcc/ChangeLog:

PR target/109117
* config/i386/i386-builtin.def (__builtin_ia32_vaesdec_v16qi,
__builtin_ia32_vaesdeclast_v16qi,__builtin_ia32_vaesenc_v16qi,
__builtin_ia32_vaesenclast_v16qi): Require OPTION_MASK_ISA_AVX512VL.

gcc/testsuite/ChangeLog:

PR target/109117
* gcc.target/i386/pr109117-1.c: New test.
---
 gcc/config/i386/i386-builtin.def   |  8 
 gcc/testsuite/gcc.target/i386/pr109117-1.c | 14 ++
 2 files changed, 18 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr109117-1.c

diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index f1c295c34f6..17dfe40fac7 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -2797,16 +2797,16 @@ BDESC (0, OPTION_MASK_ISA2_AVX5124VNNIW, 
CODE_FOR_avx5124vnniw_vp4dpwssds_mask,
 BDESC (0, OPTION_MASK_ISA2_RDPID, CODE_FOR_rdpid, "__builtin_ia32_rdpid", 
IX86_BUILTIN_RDPID, UNKNOWN, (int) UNSIGNED_FTYPE_VOID)
 
 /* VAES.  */
-BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v16qi, 
"__builtin_ia32_vaesdec_v16qi", IX86_BUILTIN_VAESDEC16, UNKNOWN, (int) 
V16QI_FTYPE_V16QI_V16QI)
+BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
CODE_FOR_vaesdec_v16qi, "__builtin_ia32_vaesdec_v16qi", IX86_BUILTIN_VAESDEC16, 
UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v32qi, 
"__builtin_ia32_vaesdec_v32qi", IX86_BUILTIN_VAESDEC32, UNKNOWN, (int) 
V32QI_FTYPE_V32QI_V32QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdec_v64qi, 
"__builtin_ia32_vaesdec_v64qi", IX86_BUILTIN_VAESDEC64, UNKNOWN, (int) 
V64QI_FTYPE_V64QI_V64QI)
-BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v16qi, 
"__builtin_ia32_vaesdeclast_v16qi", IX86_BUILTIN_VAESDECLAST16, UNKNOWN, (int) 
V16QI_FTYPE_V16QI_V16QI)
+BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
CODE_FOR_vaesdeclast_v16qi, "__builtin_ia32_vaesdeclast_v16qi", 
IX86_BUILTIN_VAESDECLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v32qi, 
"__builtin_ia32_vaesdeclast_v32qi", IX86_BUILTIN_VAESDECLAST32, UNKNOWN, (int) 
V32QI_FTYPE_V32QI_V32QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesdeclast_v64qi, 
"__builtin_ia32_vaesdeclast_v64qi", IX86_BUILTIN_VAESDECLAST64, UNKNOWN, (int) 
V64QI_FTYPE_V64QI_V64QI)
-BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v16qi, 
"__builtin_ia32_vaesenc_v16qi", IX86_BUILTIN_VAESENC16, UNKNOWN, (int) 
V16QI_FTYPE_V16QI_V16QI)
+BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
CODE_FOR_vaesenc_v16qi, "__builtin_ia32_vaesenc_v16qi", IX86_BUILTIN_VAESENC16, 
UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v32qi, 
"__builtin_ia32_vaesenc_v32qi", IX86_BUILTIN_VAESENC32, UNKNOWN, (int) 
V32QI_FTYPE_V32QI_V32QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenc_v64qi, 
"__builtin_ia32_vaesenc_v64qi", IX86_BUILTIN_VAESENC64, UNKNOWN, (int) 
V64QI_FTYPE_V64QI_V64QI)
-BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v16qi, 
"__builtin_ia32_vaesenclast_v16qi", IX86_BUILTIN_VAESENCLAST16, UNKNOWN, (int) 
V16QI_FTYPE_V16QI_V16QI)
+BDESC (OPTION_MASK_ISA_AVX512VL, OPTION_MASK_ISA2_VAES, 
CODE_FOR_vaesenclast_v16qi, "__builtin_ia32_vaesenclast_v16qi", 
IX86_BUILTIN_VAESENCLAST16, UNKNOWN, (int) V16QI_FTYPE_V16QI_V16QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v32qi, 
"__builtin_ia32_vaesenclast_v32qi", IX86_BUILTIN_VAESENCLAST32, UNKNOWN, (int) 
V32QI_FTYPE_V32QI_V32QI)
 BDESC (0, OPTION_MASK_ISA2_VAES, CODE_FOR_vaesenclast_v64qi, 
"__builtin_ia32_vaesenclast_v64qi", IX86_BUILTIN_VAESENCLAST64, UNKNOWN, (int) 
V64QI_FTYPE_V64QI_V64QI)
 
diff --git a/gcc/testsuite/gcc.target/i386/pr109117-1.c 
b/gcc/testsuite/gcc.target/i386/pr109117-1.c
new file mode 100644
index 000..87a5c0e7fc9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr109117-1.c
@@ -0,0 +1,14 @@
+/* PR target/109117 */
+/* { dg-do compile } */
+/* { dg-options "-mvaes -mno-avx512vl" } */
+
+typedef char __v16qi __attribute__ ((__vector_size__(16)));
+typedef long long __m128i __attribute__((__vector_size__(16), 
__aligned__(16)));
+volatile __v16qi x, y;
+volatile __m128i res;
+
+void
+foo (void)
+{
+  res = __builtin_ia32_vaesdec_v16qi (x, y); /* { dg-warning "implicit 
declaration of function" } */
+} /* { dg-error "incompatible types when assigning to type" "" { target 
*-*-* } .-1 } */
-- 
2.31.1