[committed] libgomp: Don't define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC for _aligned_malloc [PR105745]

[Jakub Jelinek via Gcc-patches]

since apparently _aligned_malloc requires freeing with _aligned_free and:
 /* Defined if gomp_aligned_alloc doesn't use fallback version
and free can be used instead of gomp_aligned_free.  */
 #define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1
so the second condition isn't satisfied.  For uses inside of the OpenMP
allocators we can still use _aligned_malloc but we need to call _aligned_free
in gomp_aligned_free.

Bootstrapped/regtested on x86_64-linux and i686-linux (no way to test on
mingw), committed to trunk.

2022-05-28  Jakub Jelinek  

PR libgomp/105745
* libgomp.h (GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC): Don't define for
defined(HAVE__ALIGNED_MALLOC) case.
* alloc.c (gomp_aligned_alloc): Move defined(HAVE__ALIGNED_MALLOC)
handling as last option before fallback instead of first.
(gomp_aligned_free): For defined(HAVE__ALIGNED_MALLOC) call
_aligned_free.

--- libgomp/libgomp.h.jj2022-05-23 21:44:48.941848475 +0200
+++ libgomp/libgomp.h   2022-05-27 13:11:55.576057315 +0200
@@ -87,7 +87,6 @@ enum memmodel
 /* alloc.c */
 
 #if defined(HAVE_ALIGNED_ALLOC) \
-|| defined(HAVE__ALIGNED_MALLOC) \
 || defined(HAVE_POSIX_MEMALIGN) \
 || defined(HAVE_MEMALIGN)
 /* Defined if gomp_aligned_alloc doesn't use fallback version
--- libgomp/alloc.c.jj  2022-01-11 22:31:41.361758955 +0100
+++ libgomp/alloc.c 2022-05-27 13:15:32.151816509 +0200
@@ -65,9 +65,7 @@ gomp_aligned_alloc (size_t al, size_t si
   void *ret;
   if (al < sizeof (void *))
 al = sizeof (void *);
-#ifdef HAVE__ALIGNED_MALLOC
-  ret = _aligned_malloc (size, al);
-#elif defined(HAVE_MEMALIGN)
+#ifdef HAVE_MEMALIGN
   {
 extern void *memalign (size_t, size_t);
 ret = memalign (al, size);
@@ -83,6 +81,8 @@ gomp_aligned_alloc (size_t al, size_t si
 else
   ret = NULL;
   }
+#elif defined(HAVE__ALIGNED_MALLOC)
+  ret = _aligned_malloc (size, al);
 #else
   ret = NULL;
   if ((al & (al - 1)) == 0 && size)
@@ -106,6 +106,8 @@ gomp_aligned_free (void *ptr)
 {
 #ifdef GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC
   free (ptr);
+#elif defined(HAVE__ALIGNED_MALLOC)
+  _aligned_free (ptr);
 #else
   if (ptr)
 free (((void **) ptr)[-1]);

Jakub

[COMMITTED] [Ada, build] Rename OSCONS_CC to GCC_FOR_ADA_RTS

[Alexandre Oliva via Gcc-patches]

Several gnatlib* targets perform, with a subshell and sed, the same
GCC_FOR_TARGET pathname transformation that OSCONS_CC performs with
make subst macros.  Rename OSCONS_CC to a more general name, and use
it for gnatlib as well.

Tested on x86_64-linux-gnu, checking in.


for  gcc/ada/ChangeLog

* gcc-interface/Makefile (OSCONS_CC): Rename to...
(GCC_FOR_ADA_RTS): ... this.  Adjust users.
(gnatlib): Pass it down as CC.
(gnatlib-shared-default): Likewise.
(gnatlib-shared-win32, gnatlib-shared-darwin): Likewise.
---
 gcc/ada/gcc-interface/Makefile.in |   32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/gcc/ada/gcc-interface/Makefile.in 
b/gcc/ada/gcc-interface/Makefile.in
index 1e9801a8b961d..8c34f421adfc7 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -588,9 +588,9 @@ install-gnatlib: ../stamp-gnatlib-$(RTSDIR) 
install-gcc-specs
touch ../stamp-gnatlib1-$(RTSDIR)
 
 # GCC_FOR_TARGET has paths relative to the gcc directory, so we need to adjust
-# for running it from ada/rts
+# for running it from ada/rts.
 
-OSCONS_CC=$(subst ./xgcc,../../xgcc,$(subst -B./, -B../../,$(GCC_FOR_TARGET)))
+GCC_FOR_ADA_RTS=$(subst ./xgcc,../../xgcc,$(subst -B./, 
-B../../,$(GCC_FOR_TARGET)))
 
 # The main ada source directory must be on the include path for #include "..."
 # because s-oscons-tmplt.c requires adaint.h, gsocket.h, and any file included
@@ -598,9 +598,9 @@ OSCONS_CC=$(subst ./xgcc,../../xgcc,$(subst -B./, 
-B../../,$(GCC_FOR_TARGET)))
 # ada/types.h does not conflict with a same-named system header (VxWorks
 # has a  header).
 
-OSCONS_CPP=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -E -C \
+OSCONS_CPP=$(GCC_FOR_ADA_RTS) $(GNATLIBCFLAGS_FOR_C) -E -C \
   -DTARGET=\"$(target_noncanonical)\" -iquote $(fsrcpfx)ada 
$(fsrcpfx)ada/s-oscons-tmplt.c > s-oscons-tmplt.i
-OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -S s-oscons-tmplt.i
+OSCONS_EXTRACT=$(GCC_FOR_ADA_RTS) $(GNATLIBCFLAGS_FOR_C) -S s-oscons-tmplt.i
 
 # Note: if you need to build with a non-GNU compiler, you could adapt the
 # following definitions (written for VMS DEC-C)
@@ -629,8 +629,7 @@ gnatlib: ../stamp-gnatlib1-$(RTSDIR) 
../stamp-gnatlib2-$(RTSDIR) $(RTSDIR)/s-osc
test -f $(RTSDIR)/s-oscons.ads || exit 1
 # C files
$(MAKE) -C $(RTSDIR) \
-   CC="`echo \"$(GCC_FOR_TARGET)\" \
-   | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`" \
+   CC="$(GCC_FOR_ADA_RTS)" \
INCLUDES="$(INCLUDES_FOR_SUBDIR) -I./../.." \
 CFLAGS="$(GNATLIBCFLAGS_FOR_C)" \
FORCE_DEBUG_ADAFLAGS="$(FORCE_DEBUG_ADAFLAGS)" \
@@ -638,8 +637,7 @@ gnatlib: ../stamp-gnatlib1-$(RTSDIR) 
../stamp-gnatlib2-$(RTSDIR) $(RTSDIR)/s-osc
-f ../Makefile $(LIBGNAT_OBJS) $(EXTRA_ADALIB_OBJS)
 # Ada files
$(MAKE) -C $(RTSDIR) \
-   CC="`echo \"$(GCC_FOR_TARGET)\" \
-   | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`" \
+   CC="$(GCC_FOR_ADA_RTS)" \
ADA_INCLUDES="" \
 CFLAGS="$(GNATLIBCFLAGS)" \
ADAFLAGS="$(GNATLIBFLAGS)" \
@@ -672,15 +670,13 @@ gnatlib-shared-default:
 LN_S="$(LN_S)" \
  gnatlib
$(RM) $(RTSDIR)/libgna*$(soext)
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` 
-shared $(GNATLIBCFLAGS) \
+   cd $(RTSDIR); $(GCC_FOR_ADA_RTS) -shared $(GNATLIBCFLAGS) \
$(PICFLAG_FOR_TARGET) \
-o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \
$(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(MISCLIB) -lm
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` 
-shared $(GNATLIBCFLAGS) \
+   cd $(RTSDIR); $(GCC_FOR_ADA_RTS) -shared $(GNATLIBCFLAGS) \
$(PICFLAG_FOR_TARGET) \
-o libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_TASKING_OBJS) \
@@ -764,14 +760,12 @@ gnatlib-shared-win32:
$(RM) $(RTSDIR)/libgna*$(soext)
$(CP) $(RTSDIR)/libgnat$(arext) $(RTSDIR)/libgnat_pic$(arext)
$(CP) $(RTSDIR)/libgnarl$(arext) $(RTSDIR)/libgnarl_pic$(arext)
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` 
-shared -shared-libgcc \
+   cd $(RTSDIR); $(GCC_FOR_ADA_RTS) -shared -shared-libgcc \
$(PICFLAG_FOR_TARGET) \
-o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \
$(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) $(MISCLIB)
-   cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
-| sed -e 's

[PATCH] [PR105665] ivopts: check defs of names in base for undefs

[Alexandre Oliva via Gcc-patches]

The patch for PR 100810 tested for undefined SSA_NAMEs appearing
directly in the base expression of the potential IV candidate, but
that's not enough.  The testcase for PR105665 shows an undefined
SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg
in the referenced SSA_NAME.  The variant of that test shows it can be
further removed from the referenced SSA_NAME.

To avoid deep recursion, precompute SSA_NAMEs deemed unsuitable
candidates, so that we can skip them with a flag test.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* tree-ssa-loop-ivopts.cc (mark_ssa_undefs): Precompute
unsuitability of SSA_NAMEs in TREE_VISITED.
(find_ssa_undef): Check the precomputed flag.
(tree_ssa_iv_optimize): Call mark_ssa_undefs.

for  gcc/testsuite/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* gcc.dg/torture/pr105665.c: New.
---
 gcc/testsuite/gcc.dg/torture/pr105665.c |   20 ++
 gcc/tree-ssa-loop-ivopts.cc |   62 ++-
 2 files changed, 80 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr105665.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr105665.c 
b/gcc/testsuite/gcc.dg/torture/pr105665.c
new file mode 100644
index 0..34cfc65843495
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr105665.c
@@ -0,0 +1,20 @@
+/* { dg-do run } */
+
+int a, b, c[1], d[2], *e = c;
+int main() {
+  int f = 0;
+  for (; b < 2; b++) {
+int g;
+if (f)
+  g++, b = 40;
+a = d[b * b];
+for (f = 0; f < 3; f++) {
+  if (e)
+break;
+  g--;
+  if (a)
+a = g;
+}
+  }
+  return 0;
+}
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 81b536f930415..d8200f2a53b21 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -3071,13 +3071,70 @@ get_loop_invariant_expr (struct ivopts_data *data, tree 
inv_expr)
   return *slot;
 }
 
-/* Find the first undefined SSA name in *TP.  */
+/* Mark as TREe_VISITED any SSA_NAMEs that are unsuitable as ivopts
+   candidates for potentially involving undefined behavior.  */
+
+static void
+mark_ssa_undefs (void)
+{
+  auto_vec queue;
+
+  unsigned int i;
+  tree var;
+  FOR_EACH_SSA_NAME (i, var, cfun)
+{
+  if (SSA_NAME_IS_VIRTUAL_OPERAND (var)
+ || ssa_defined_default_def_p (var)
+ || !ssa_undefined_value_p (var, false))
+   TREE_VISITED (var) = false;
+  else
+   {
+ TREE_VISITED (var) = true;
+ queue.safe_push (var);
+ if (dump_file)
+   fprintf (dump_file, "marking _%i as undef\n",
+SSA_NAME_VERSION (var));
+   }
+}
+
+  while (!queue.is_empty ())
+{
+  var = queue.pop ();
+  gimple *stmt;
+  imm_use_iterator iter;
+  FOR_EACH_IMM_USE_STMT (stmt, iter, var)
+   {
+ if (is_gimple_call (stmt) || is_a  (stmt))
+   continue;
+
+ def_operand_p defvar;
+ ssa_op_iter diter;
+ FOR_EACH_PHI_OR_STMT_DEF (defvar, stmt, diter, SSA_OP_DEF)
+   {
+ gcc_checking_assert (is_gimple_assign (stmt)
+  || is_a  (stmt));
+ tree def = DEF_FROM_PTR (defvar);
+ if (TREE_VISITED (def))
+   continue;
+ TREE_VISITED (def) = true;
+ queue.safe_push (def);
+ if (dump_file)
+   fprintf (dump_file, "Marking _%i as undef because of _%i\n",
+SSA_NAME_VERSION (def), SSA_NAME_VERSION (var));
+   }
+   }
+}
+}
+
+/* Return *TP if it is an SSA_NAME marked with TREE_VISITED, i.e., as
+   unsuitable as ivopts candidates for potentially involving undefined
+   behavior.  */
 
 static tree
 find_ssa_undef (tree *tp, int *walk_subtrees, void *)
 {
   if (TREE_CODE (*tp) == SSA_NAME
-  && ssa_undefined_value_p (*tp, false))
+  && TREE_VISITED (*tp))
 return *tp;
   if (!EXPR_P (*tp))
 *walk_subtrees = 0;
@@ -8192,6 +8249,7 @@ tree_ssa_iv_optimize (void)
   auto_bitmap toremove;
 
   tree_ssa_iv_optimize_init (&data);
+  mark_ssa_undefs ();
 
   /* Optimize the loops starting with the innermost ones.  */
   for (auto loop : loops_list (cfun, LI_FROM_INNERMOST))


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[pushed] c++: lambda in concept [PR105652]

[Jason Merrill via Gcc-patches]

We currently check satisfaction in the context of the constrained
declaration (which may be wrong, see PR104111).  When checking C
for S, we currently substitute into the lambda in the context of
S (rather than S, which seems wrong if the above isn't wrong), so
the new closure type thinks its context is S, which confuses debug
output.  For the moment, let's work around all of this by overriding the
context of the closure.

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

PR c++/105652

gcc/cp/ChangeLog:

* pt.cc (tsubst_lambda_expr): Don't let a namespace-scope lambda
instantiate into a class-scope lambda.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda20.C: New test.
---
 gcc/cp/pt.cc   | 17 -
 gcc/testsuite/g++.dg/cpp2a/concepts-lambda20.C | 17 +
 2 files changed, 29 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda20.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 24bbe2f4060..f1f080531a6 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -19740,11 +19740,18 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
 return error_mark_node;
 
   if (LAMBDA_EXPR_EXTRA_SCOPE (t) == NULL_TREE)
-/* A lambda in a default argument outside a class gets no
-   LAMBDA_EXPR_EXTRA_SCOPE, as specified by the ABI.  But
-   tsubst_default_argument calls start_lambda_scope, so we need to
-   specifically ignore it here, and use the global scope.  */
-record_null_lambda_scope (r);
+{
+  /* A lambda in a default argument outside a class gets no
+LAMBDA_EXPR_EXTRA_SCOPE, as specified by the ABI.  But
+tsubst_default_argument calls start_lambda_scope, so we need to
+specifically ignore it here, and use the global scope.  */
+  record_null_lambda_scope (r);
+
+  /* If we're pushed into another scope (PR105652), fix it.  */
+  if (TYPE_NAMESPACE_SCOPE_P (TREE_TYPE (t)))
+   TYPE_CONTEXT (type) = DECL_CONTEXT (TYPE_NAME (type))
+ = TYPE_CONTEXT (TREE_TYPE (t));
+}
   else
 record_lambda_scope (r);
 
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda20.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda20.C
new file mode 100644
index 000..40e5973176e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda20.C
@@ -0,0 +1,17 @@
+// PR c++/105652
+// { dg-do compile { target c++20 } }
+// { dg-additional-options -g }
+
+template
+struct I {};
+
+template
+concept C = [](I) { return true; } (I<0>{});
+
+template
+struct S { };
+
+template
+struct S { constexpr static bool value = true; };
+
+static_assert(S::value);

base-commit: d9176e643f385c3ef3b8c28cbc0468776fd8a14f
-- 
2.27.0

Re: [committed] d: Merge upstream dmd 60bfa0ee7, druntime 94bd5bcb, phobos 3a1cd9a01.

[Iain Buclaw via Gcc-patches]

Excerpts from Rainer Orth's message of Mai 18, 2022 4:40 pm:
> Hi Iain,
> 
>> Upstream dmd has now released v2.100.0, this patch merges in the
>> latest bug fixes since the last sync-up of the release branch, as well
>> as all new feature changes on development branch.
> [...]
>> D runtime changes:
>>
>> - Import druntime v2.100.0.
>>
>> Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
>> committed to mainline.
> 
> this patch broke Solaris bootstrap:
> 

Hi Rainer,

Thanks for the hint. I've sent an upstream patch to remove all
definitions that conflict with core.sys.elf, and checked that
libdruntime bootstraps successfully again.

Will downstream the patch once its in.

Iain.

Re: [ping2][PATCH 0/8][RFC] Support BTF decl_tag and type_tag annotations

[David Faust via Gcc-patches]

On 5/26/22 00:29, Yonghong Song wrote:
> 
> 
> On 5/24/22 10:04 AM, David Faust wrote:
>>
>>
>> On 5/24/22 09:03, Yonghong Song wrote:
>>>
>>>
>>> On 5/24/22 8:53 AM, David Faust wrote:


 On 5/24/22 04:07, Jose E. Marchesi wrote:
>
>> On 5/11/22 11:44 AM, David Faust wrote:
>>>
>>> On 5/10/22 22:05, Yonghong Song wrote:


 On 5/10/22 8:43 PM, Yonghong Song wrote:
>
>
> On 5/6/22 2:18 PM, David Faust wrote:
>>
>>
>> On 5/5/22 16:00, Yonghong Song wrote:
>>>
>>>
>>> On 5/4/22 10:03 AM, David Faust wrote:


 On 5/3/22 15:32, Joseph Myers wrote:
> On Mon, 2 May 2022, David Faust via Gcc-patches wrote:
>
>> Consider the following example:
>>
>>     #define __typetag1 __attribute__((btf_type_tag("tag1")))
>>     #define __typetag2 __attribute__((btf_type_tag("tag2")))
>>     #define __typetag3 __attribute__((btf_type_tag("tag3")))
>>
>>     int __typetag1 * __typetag2 __typetag3 * g;
>>
>> The expected behavior is that 'g' is "a pointer with tags
>> 'tag2' and
>> 'tag3',
>> to a pointer with tag 'tag1' to an int". i.e.:
>
> That's not a correct expectation for either GNU __attribute__ or
> C2x [[]]
> attribute syntax.  In either syntax, __typetag2 __typetag3 should
> apply to
> the type to which g points, not to g or its type, just as if
> you had a
> type qualifier there.  You'd need to put the attributes (or
> qualifier)
> after the *, not before, to make them apply to the pointer
> type.  See
> "Attribute Syntax" in the GCC manual for how the syntax is
> defined for
> GNU
> attributes and deduce in turn, for each subsequence of the tokens
> matching
> the syntax for some kind of declarator, what the type for "T D1"
> would be
> as defined there and in the C standard, as deduced from the type 
> for
> "T D"
> for a sub-declarator D.
>      >> But GCC's attribute parsing produces a variable 'g'
> which is "a
 pointer with
>> tag 'tag1' to a pointer with tags 'tag2' and 'tag3' to an
>> int", i.e.
>
> In GNU syntax, __typetag1 applies to the declaration, whereas in 
> C2x
> syntax it applies to int.  Again, if you wanted it to apply to the
> pointer
> type it would need to go after the * not before.
>
> If you are concerned with the fine details of what construct an
> attribute
> appertains to, I recommend using C2x syntax not GNU syntax.
>

 Joseph, thank you! This is very helpful. My understanding of
 the syntax
 was not correct.

 (Actually, I made a bad mistake in paraphrasing this example from 
 the
 discussion of it in the series cover letter. But, the reason
 why it is
 incorrect is the same.)


 Yonghong, is the specific ordering an expectation in BPF programs 
 or
 other users of the tags?
>>>
>>> This is probably a language writing issue. We are saying tags only
>>> apply to pointer. We probably should say it only apply to pointee.
>>>
>>> $ cat t.c
>>> int const *ptr;
>>>
>>> the llvm ir debuginfo:
>>>
>>> !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 
>>> 64)
>>> !6 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !7)
>>> !7 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
>>>
>>> We could replace 'const' with a tag like below:
>>>
>>> int __attribute__((btf_type_tag("tag"))) *ptr;
>>>
>>> !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 
>>> 64,
>>> annotations: !7)
>>> !6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
>>> !7 = !{!8}
>>> !8 = !{!"btf_type_tag", !"tag"}
>>>
>>> In the above IR, we generate annotations to pointer_type because
>>> we didn't invent a new DI type for encode btf_type_tag. But it is
>>> totally okay to have IR looks like
>>>
>>> !5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 
>>> 64)
>>> !11 = !DIBtfTypeTagType(..., baseType: !6, name: !"Tag")
>>> !6 = !DIBasicTy

Re: [PATCH] Add divide by zero side effect.

[Andrew MacLeod via Gcc-patches]

On 5/27/22 15:33, Andi Kleen wrote:

Andrew MacLeod via Gcc-patches  writes:

diff --git a/gcc/gimple-range-side-effect.cc b/gcc/gimple-range-side-effect.cc
index 2c8c77dc569..548e4bea313 100644
--- a/gcc/gimple-range-side-effect.cc
+++ b/gcc/gimple-range-side-effect.cc
@@ -116,6 +116,23 @@ stmt_side_effects::stmt_side_effects (gimple *s)
  walk_stmt_load_store_ops (s, (void *)this, non_null_loadstore,
  non_null_loadstore);
  
+  if (is_a (s))

+{
+  switch (gimple_assign_rhs_code (s))
+   {
+   case TRUNC_DIV_EXPR:
+   case CEIL_DIV_EXPR:
+   case FLOOR_DIV_EXPR:
+   case ROUND_DIV_EXPR:
+   case EXACT_DIV_EXPR:
+ // Divide means operand 2 is not zero after this stmt.
+ if (gimple_range_ssa_p (gimple_assign_rhs2 (s)))
+   add_nonzero (gimple_assign_rhs2 (s));

Sorry I'm late, but how does this ensure the value is a integer?
I believe for floating point the assumption is not correct because
division by zero doesn't necessarily fault.

-Andi

gimple_range_ssa_p() only returns non-zero when the value is an ssa_name 
whose type is supported by the range calculators... currently only 
integrals values.  When we support floating points we will have to add 
additional logic.


Andrew

Re: [PATCH] Add divide by zero side effect.

[Andi Kleen via Gcc-patches]

Andrew MacLeod via Gcc-patches  writes:
>
> diff --git a/gcc/gimple-range-side-effect.cc b/gcc/gimple-range-side-effect.cc
> index 2c8c77dc569..548e4bea313 100644
> --- a/gcc/gimple-range-side-effect.cc
> +++ b/gcc/gimple-range-side-effect.cc
> @@ -116,6 +116,23 @@ stmt_side_effects::stmt_side_effects (gimple *s)
>  walk_stmt_load_store_ops (s, (void *)this, non_null_loadstore,
> non_null_loadstore);
>  
> +  if (is_a (s))
> +{
> +  switch (gimple_assign_rhs_code (s))
> + {
> + case TRUNC_DIV_EXPR:
> + case CEIL_DIV_EXPR:
> + case FLOOR_DIV_EXPR:
> + case ROUND_DIV_EXPR:
> + case EXACT_DIV_EXPR:
> +   // Divide means operand 2 is not zero after this stmt.
> +   if (gimple_range_ssa_p (gimple_assign_rhs2 (s)))
> + add_nonzero (gimple_assign_rhs2 (s));

Sorry I'm late, but how does this ensure the value is a integer?
I believe for floating point the assumption is not correct because
division by zero doesn't necessarily fault.

-Andi

Re: [committed] amdgcn: Remove LLVM 9 assembler/linker support

[Thomas Schwinge]

Hi Andrew!

On 2022-05-24T16:27:52+0100, Andrew Stubbs  wrote:
> I've committed this patch to set the minimum required LLVM version, for
> the assembler and linker, to 13.0.1. An upgrade from LLVM 9 is a
> prerequisite for the gfx90a support, and 13.0.1 is now the oldest
> version not known to have compatibility issues.
>
> The patch removes all the obsolete feature detection tests from
> configure and adds a new version test. Likewise the version dependencies
> in the backend are removed.

I've not otherwise reviewed your
commit r13-742-g8086230e7ac619c0b0eeb6e15df7975ac214725f
"amdgcn: Remove LLVM 9 assembler/linker support", but happened to notice
that your commit also removed the ARM-target 'HAVE_GAS_ARM_EXTENDED_ARCH'
-- is that intentional; I suppose not?  That had been added by Richard
Earnshaw in commit r12-3725-g4e7a92c0ff3871d955ca8fb133f869b216d7224d
"arm: pass architecture extensions to assembler if supported".


> --- a/gcc/config.in
> +++ b/gcc/config.in

> -/* Define if your Arm assembler permits context-specific feature extensions.
> -   */
> -#ifndef USED_FOR_TARGET
> -#undef HAVE_GAS_ARM_EXTENDED_ARCH
> -#endif
> -
> -

> --- a/gcc/configure
> +++ b/gcc/configure

>  case "$target" in
>amdgcn-* | gcn-*)
> [...]
>  ;;
> -  arm*)
> -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler for 
> assembler for arm accepts context-specific architecture extensions" >&5
> -$as_echo_n "checking assembler for assembler for arm accepts 
> context-specific architecture extensions... " >&6; }
> -if ${gcc_cv_as_arm_option_extensions+:} false; then :
> -  $as_echo_n "(cached) " >&6
> -else
> -  gcc_cv_as_arm_option_extensions=no
> -  if test x$gcc_cv_as != x; then
> -$as_echo '.text
> - .thumb
> - .syntax unified
> - vmov.f32 s0, s1' > conftest.s
> -if { ac_try='$gcc_cv_as $gcc_cv_as_flags -march=armv8.1-m.main+mve -o 
> conftest.o conftest.s >&5'
> -  { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
> -  (eval $ac_try) 2>&5
> -  ac_status=$?
> -  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
> -  test $ac_status = 0; }; }
> -then
> - gcc_cv_as_arm_option_extensions=yes
> -else
> -  echo "configure: failed program was" >&5
> -  cat conftest.s >&5
> -fi
> -rm -f conftest.o conftest.s
> -  fi
> -fi
> -{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
> $gcc_cv_as_arm_option_extensions" >&5
> -$as_echo "$gcc_cv_as_arm_option_extensions" >&6; }
> -if test $gcc_cv_as_arm_option_extensions = yes; then
> -
> -$as_echo "#define HAVE_GAS_ARM_EXTENDED_ARCH 1" >>confdefs.h
> -
> -fi
> -
>  esac

> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac

>  case "$target" in
>amdgcn-* | gcn-*)
> [...]
>  ;;
> -  arm*)
> -gcc_GAS_CHECK_FEATURE([assembler for arm accepts context-specific 
> architecture extensions],
> -  gcc_cv_as_arm_option_extensions,
> -  [-march=armv8.1-m.main+mve],
> -  [.text
> - .thumb
> - .syntax unified
> - vmov.f32 s0, s1],,
> -  [AC_DEFINE(HAVE_GAS_ARM_EXTENDED_ARCH, 1,
> -   [Define if your Arm assembler permits context-specific feature 
> extensions.])])
>  esac


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

[Eric Gallager via Gcc-patches]

On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
 wrote:
>
> Hi fellow hackers,
>
> first of all: I'm not sure if this is the correct mailing list for this
> question, but I did not found a separate one and
> gnu.org/software/libiberty redirects to
> https://gcc.gnu.org/onlinedocs/libiberty.pdf - so I'm here.
> If there's a better place for this: please drop a note.
>
> I've never "worked" with libiberty directly but am sure I'm using it
> quite regularly with various tools including GDB and valgrind.
> Therefore I currently cannot send a patch for the function name
> demangling, but if this is a reasonable thing to add I'd like to work on
> this with someone.
>
> As noted: the first question is: is it reasonable to add support for
> GnuCOBOL?
>
> * How would the demangler know it is to be called? Just "best match"
> (GnuCOBOL modules always have some symbols in it which should be
> available if there is any debugging information in, if that helps)?
> * Giving the work of gcc-cobol which was discussed on this mailing list
> some months ago (not sure about its current state) there possibly will
> be a COBOL support be "integrated" - with possibly different name
> mangling. But still - GnuCOBOL is used "in the wild" (for production
> environments) since years (and will be for many years to come, both
> based on GCC and with other compilers) and the name mangling rules did
> not change.
>

If the plan is to integrate GnuCOBOL into trunk, then I'd say adding
demangling support for it to libiberty would not only be reasonable,
but also a necessary prerequisite for merging the rest of it.

> A second question would be: Is there anyone who would be willing to work
> on this with me?
> Where would "we" or I start?
>
> Thank you for taking the time to read and possibly answer,
> Simon Sobisch
>
> Maintainer GnuCOBOL
>
>

[PATCH] c++: document comp_template_args's default args

[Patrick Palka via Gcc-patches]

In passing, use bool for its return type.

gcc/cp/ChangeLog:

* cp-tree.h (comp_template_args): Change return type to bool.
* pt.cc (comp_template_args): Document default arguments.
Change return type to bool and adjust returns accordingly.
---
 gcc/cp/cp-tree.h |  2 +-
 gcc/cp/pt.cc | 24 +++-
 2 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index d77fd1eb8a9..da8898155e0 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7327,7 +7327,7 @@ extern tree get_template_info 
(const_tree);
 extern int template_class_depth(tree);
 extern int is_specialization_of(tree, tree);
 extern bool is_specialization_of_friend(tree, tree);
-extern int comp_template_args  (tree, tree, tree * = NULL,
+extern bool comp_template_args (tree, tree, tree * = NULL,
 tree * = NULL, bool = false);
 extern int template_args_equal  (tree, tree, bool = false);
 extern tree maybe_process_partial_specialization (tree);
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index ec168234325..b5064990857 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -9368,27 +9368,25 @@ template_args_equal (tree ot, tree nt, bool 
partial_order /* = false */)
 }
 }
 
-/* Returns 1 iff the OLDARGS and NEWARGS are in fact identical sets of
-   template arguments.  Returns 0 otherwise, and updates OLDARG_PTR and
+/* Returns true iff the OLDARGS and NEWARGS are in fact identical sets of
+   template arguments.  Returns false otherwise, and updates OLDARG_PTR and
NEWARG_PTR with the offending arguments if they are non-NULL.  */
 
-int
+bool
 comp_template_args (tree oldargs, tree newargs,
-   tree *oldarg_ptr, tree *newarg_ptr,
-   bool partial_order)
+   tree *oldarg_ptr /* = NULL */, tree *newarg_ptr /* = NULL 
*/,
+   bool partial_order /* = false */)
 {
-  int i;
-
   if (oldargs == newargs)
-return 1;
+return true;
 
   if (!oldargs || !newargs)
-return 0;
+return false;
 
   if (TREE_VEC_LENGTH (oldargs) != TREE_VEC_LENGTH (newargs))
-return 0;
+return false;
 
-  for (i = 0; i < TREE_VEC_LENGTH (oldargs); ++i)
+  for (int i = 0; i < TREE_VEC_LENGTH (oldargs); ++i)
 {
   tree nt = TREE_VEC_ELT (newargs, i);
   tree ot = TREE_VEC_ELT (oldargs, i);
@@ -9399,10 +9397,10 @@ comp_template_args (tree oldargs, tree newargs,
*oldarg_ptr = ot;
  if (newarg_ptr != NULL)
*newarg_ptr = nt;
- return 0;
+ return false;
}
 }
-  return 1;
+  return true;
 }
 
 inline bool
-- 
2.36.1.195.g8ddf593a25

[PATCH] c++: use current_template_constraints more

[Patrick Palka via Gcc-patches]

gcc/cp/ChangeLog:

* decl.cc (grokvardecl): Use current_template_constraints.
(xref_tag): Likewise.
* semantics.cc (finish_template_template_parm): Likewise.
---
 gcc/cp/decl.cc  | 13 +++--
 gcc/cp/semantics.cc |  3 +--
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 892e4a4b19b..26428ca7122 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -10789,9 +10789,7 @@ grokvardecl (tree type,
   else if (flag_concepts
   && current_template_depth > template_class_depth (scope))
 {
-  tree reqs = TEMPLATE_PARMS_CONSTRAINTS (current_template_parms);
-  tree ci = build_constraints (reqs, NULL_TREE);
-
+  tree ci = current_template_constraints ();
   set_constraints (decl, ci);
 }
 
@@ -15852,13 +15850,8 @@ xref_tag (enum tag_types tag_code, tree name,
 {
   /* Check that we aren't trying to overload a class with different
  constraints.  */
-  tree constr = NULL_TREE;
-  if (current_template_parms)
-{
-  tree reqs = TEMPLATE_PARMS_CONSTRAINTS (current_template_parms);
-  constr = build_constraints (reqs, NULL_TREE);
-}
- if (!redeclare_class_template (t, current_template_parms, constr))
+ if (!redeclare_class_template (t, current_template_parms,
+current_template_constraints ()))
return error_mark_node;
 }
   else if (!processing_template_decl
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index cd7a2818feb..efdeb9318a7 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -3387,8 +3387,7 @@ finish_template_template_parm (tree aggr, tree identifier)
 
   /* Associate the constraints with the underlying declaration,
  not the template.  */
-  tree reqs = TEMPLATE_PARMS_CONSTRAINTS (current_template_parms);
-  tree constr = build_constraints (reqs, NULL_TREE);
+  tree constr = current_template_constraints ();
   set_constraints (decl, constr);
 
   end_template_decl ();
-- 
2.36.1.195.g8ddf593a25

[PATCH] c++: don't substitute TEMPLATE_PARM_CONSTRAINT [PR100374]

[Patrick Palka via Gcc-patches]

This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of
each template parameter except as necessary for (friend) declaration
matching, like we already do for the overall TEMPLATE_PARMS_CONSTRAINTS
of a template parameter list.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps 12.2?  Also tested on range-v3 and cmcstl2.

PR c++/100374

gcc/cp/ChangeLog:

* pt.cc (tsubst_each_template_parm_constraint): Define.
(tsubst_friend_function): Use it.
(tsubst_friend_class): Use it.
(tsubst_template_parm): Don't substitute TEMPLATE_PARM_CONSTRAINT.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-template-parm11.C: New test.
---
 gcc/cp/pt.cc  | 35 ---
 .../g++.dg/cpp2a/concepts-template-parm11.C   | 16 +
 2 files changed, 47 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-template-parm11.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 24bbe2f4060..ec168234325 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -184,6 +184,7 @@ static int unify_pack_expansion (tree, tree, tree,
 tree, unification_kind_t, bool, bool);
 static tree copy_template_args (tree);
 static tree tsubst_template_parms (tree, tree, tsubst_flags_t);
+static void tsubst_each_template_parm_constraint (tree, tree, tsubst_flags_t);
 tree most_specialized_partial_spec (tree, tsubst_flags_t);
 static tree tsubst_aggr_type (tree, tree, tsubst_flags_t, tree, int);
 static tree tsubst_arg_types (tree, tree, tree, tsubst_flags_t, tree);
@@ -11254,7 +11255,12 @@ tsubst_friend_function (tree decl, tree args)
   tree parms = DECL_TEMPLATE_PARMS (new_friend);
   tree treqs = TEMPLATE_PARMS_CONSTRAINTS (parms);
   treqs = maybe_substitute_reqs_for (treqs, new_friend);
-  TEMPLATE_PARMS_CONSTRAINTS (parms) = treqs;
+  if (treqs != TEMPLATE_PARMS_CONSTRAINTS (parms))
+   {
+ TEMPLATE_PARMS_CONSTRAINTS (parms) = treqs;
+ /* As well as each TEMPLATE_PARM_CONSTRAINT.  */
+ tsubst_each_template_parm_constraint (parms, args, 
tf_warning_or_error);
+   }
 }
 
   /* The mangled name for the NEW_FRIEND is incorrect.  The function
@@ -11500,6 +11506,8 @@ tsubst_friend_class (tree friend_tmpl, tree args)
{
  tree parms = tsubst_template_parms (DECL_TEMPLATE_PARMS (friend_tmpl),
  args, tf_warning_or_error);
+ tsubst_each_template_parm_constraint (parms, args,
+   tf_warning_or_error);
   location_t saved_input_location = input_location;
   input_location = DECL_SOURCE_LOCATION (friend_tmpl);
   tree cons = get_constraints (tmpl);
@@ -11534,6 +11542,8 @@ tsubst_friend_class (tree friend_tmpl, tree args)
   DECL_FRIEND_CONTEXT (friend_tmpl));
  --processing_template_decl;
  set_constraints (tmpl, ci);
+ tsubst_each_template_parm_constraint (DECL_TEMPLATE_PARMS (tmpl),
+   args, tf_warning_or_error);
}
 
  /* Inject this template into the enclosing namspace scope.  */
@@ -13656,7 +13666,6 @@ tsubst_template_parm (tree t, tree args, tsubst_flags_t 
complain)
 
   default_value = TREE_PURPOSE (t);
   parm_decl = TREE_VALUE (t);
-  tree constraint = TEMPLATE_PARM_CONSTRAINTS (t);
 
   parm_decl = tsubst (parm_decl, args, complain, NULL_TREE);
   if (TREE_CODE (parm_decl) == PARM_DECL
@@ -13664,13 +13673,31 @@ tsubst_template_parm (tree t, tree args, 
tsubst_flags_t complain)
 parm_decl = error_mark_node;
   default_value = tsubst_template_arg (default_value, args,
   complain, NULL_TREE);
-  constraint = tsubst_constraint (constraint, args, complain, NULL_TREE);
 
   tree r = build_tree_list (default_value, parm_decl);
-  TEMPLATE_PARM_CONSTRAINTS (r) = constraint;
+  TEMPLATE_PARM_CONSTRAINTS (r) = TEMPLATE_PARM_CONSTRAINTS (t);
   return r;
 }
 
+/* Substitute in-place the TEMPLATE_PARM_CONSTRAINT of each template
+   parameter in PARMS for sake of declaration matching.  */
+
+static void
+tsubst_each_template_parm_constraint (tree parms, tree args,
+ tsubst_flags_t complain)
+{
+  ++processing_template_decl;
+  for (; parms; parms = TREE_CHAIN (parms))
+{
+  tree level = TREE_VALUE (parms);
+  for (tree parm : tree_vec_range (level))
+   TEMPLATE_PARM_CONSTRAINTS (parm)
+ = tsubst_constraint (TEMPLATE_PARM_CONSTRAINTS (parm), args,
+  complain, NULL_TREE);
+}
+  --processing_template_decl;
+}
+
 /* Substitute the ARGS into the indicated aggregate (or enumeration)
type T.  If T is not an aggregate or enumeration type, it is
handled as if by tsubst.  IN_DECL is as for tsubst.  If
diff 

Re: [PATCH 1/7] openmp: Add C support for parsing metadirectives

[Jakub Jelinek via Gcc-patches]

On Fri, Dec 10, 2021 at 05:31:08PM +, Kwok Cheung Yeung wrote:
> This patch adds support for parsing metadirectives in the C parser.
> 
> Metadirectives are represented by a OMP_METADIRECTIVE tree node. It has a
> single operand (accessed by OMP_METADIRECTIVE_CLAUSES) which contains a

I think naming this OMP_METADIRECTIVE_CLAUSES when the operand isn't
a chain of OMP_CLAUSE trees is misleading, I think better would be
OMP_METADIRECTIVE_VARIANTS.

> I have removed support for the 'omp begin metadirective'..'omp end
> metadirective' form of the directive that was originally in the WIP patch.
> According to the spec, the only variant directives that can be used in this
> form must have an 'end ' form (apart from the 'nothing'
> directive), and in C/C++, the only directive that we support with an end
> form is 'declare target', which we currently forbid since it is declarative.

I guess that is fine initially, but eventually we should have support
for parsing of omp begin metadirective and omp end metadirective even
if we just always sorry then.

> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -1390,6 +1390,17 @@ c_parser_skip_to_end_of_block_or_statement (c_parser 
> *parser)
> ++nesting_depth;
> break;
>  
> + case CPP_OPEN_PAREN:
> +   /* Track parentheses in case the statement is a standalone 'for'
> +  statement - we want to skip over the semicolons separating the
> +  operands.  */
> +   nesting_depth++;
> +   break;
> +
> + case CPP_CLOSE_PAREN:
> +   nesting_depth--;
> +   break;
> +
>   case CPP_PRAGMA:
> /* If we see a pragma, consume the whole thing at once.  We
>have some safeguards against consuming pragmas willy-nilly.

I find this hunk very risky, it is used in many places and I'm not convinced
that is the behavior we want everywhere else.
I'd say the options are either to copy the function and add this only to the
copy and use that in metadirective handling, or add a default bool argument
and only do something about nesting_depth if the argument is non-default.
Furthermore, I don't think we want to just blindly decrement nesting_depth,
the CPP_CLOSE_BRACE takes care of never decrementing it below zero.
And, the function uses ++nesting_depth etc. instead of nesting_depth++
so some consistency would be nice.

> @@ -19187,6 +19200,7 @@ c_parser_omp_for_loop (location_t loc, c_parser 
> *parser, enum tree_code code,
>location_t for_loc;
>bool tiling = false;
>bool inscan = false;
> +
>vec *for_block = make_tree_vector ();
>  
>for (cl = clauses; cl; cl = OMP_CLAUSE_CHAIN (cl))

Why?

> @@ -21606,10 +21621,16 @@ c_parser_omp_context_selector (c_parser *parser, 
> tree set, tree parms)
>   {
> mark_exp_read (t);
> t = c_fully_fold (t, false, NULL);
> -   if (!INTEGRAL_TYPE_P (TREE_TYPE (t))
> -   || !tree_fits_shwi_p (t))
> +   if (!metadirective_p
> +   && (!INTEGRAL_TYPE_P (TREE_TYPE (t))
> +   || !tree_fits_shwi_p (t)))
>   error_at (token->location, "property must be "
> -   "constant integer expression");
> +"constant integer expression");
> +   else if (metadirective_p
> +&& !INTEGRAL_TYPE_P (TREE_TYPE (t)))
> + /* Allow non-constant user expressions in metadirectives.  
> */
> + error_at (token->location, "property must be "
> +"integer expression");
> else
>   properties = tree_cons (NULL_TREE, t, properties);
>   }

I don't understand this change.  In OpenMP 5.0, condition selector had to be
constant.  In OpenMP 5.1, it can be non-constant and then it is a dynamic
selector.  But there is no restriction that it must be constant for
declare variant.
I think enabling this is orthogonal to the metadirective support, so either
the initial version shouldn't support dynamic selectors and a follow-up
patch should add support for them for both metadirectives and declare
variant, or the support should be added for both at the same time.

> @@ -22930,6 +22953,368 @@ c_parser_omp_error (c_parser *parser, enum 
> pragma_context context)
>return false;
>  }
>  
> +/* Helper function for c_parser_omp_metadirective.  */
> +
> +static void
> +analyze_metadirective_body (c_parser *parser,
> + vec &tokens,
> + vec &labels)
> +{
> +  int nesting_depth = 0;
> +  int bracket_depth = 0;
> +  bool ignore_label = false;
> +
> +  /* Read in the body tokens to the tokens for each candidate directive.  */
> +  while (1)
> +{
> +  c_token *token = c_parser_peek_token (parser);
> +  bool stop = false;
> +
> +  if (c_parser_next_token_is_keyword (parser, RID_CASE))
> + ignore_label = 

Re: [PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

[Marek Polacek via Gcc-patches]

On Fri, May 27, 2022 at 11:52:12AM -0400, Jason Merrill wrote:
> On 5/26/22 20:33, Marek Polacek wrote:
> > As discussed here:
> > ,
> > type_dependent_expression_p should not be called with a type argument.
> > 
> > I promised I'd add an assert so here it is.  One place needed adjusting,
> > the comment explains why.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR c++/99080
> > 
> > gcc/cp/ChangeLog:
> > 
> > * pt.cc (type_dependent_expression_p): Assert !TYPE_P.
> > * semantics.cc (finish_id_expression_1): Don't call
> > type_dependent_expression_p for a type.
> > ---
> >   gcc/cp/pt.cc| 2 ++
> >   gcc/cp/semantics.cc | 4 +++-
> >   2 files changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 24bbe2f4060..89156cb88b4 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -27727,6 +27727,8 @@ type_dependent_expression_p (tree expression)
> > if (expression == NULL_TREE || expression == error_mark_node)
> >   return false;
> > +  gcc_checking_assert (!TYPE_P (expression));
> > +
> > STRIP_ANY_LOCATION_WRAPPER (expression);
> > /* An unresolved name is always dependent.  */
> > diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> > index cd7a2818feb..7f8502f49b0 100644
> > --- a/gcc/cp/semantics.cc
> > +++ b/gcc/cp/semantics.cc
> > @@ -4141,7 +4141,9 @@ finish_id_expression_1 (tree id_expression,
> >   }
> > else
> >   {
> > -  bool dependent_p = type_dependent_expression_p (decl);
> > +  /* DECL could be e.g. UNBOUND_CLASS_TEMPLATE which is a type which
> > +t_d_e_p doesn't accept.  */
> > +  bool dependent_p = !TYPE_P (decl) && type_dependent_expression_p 
> > (decl);
> 
> Maybe instead we could handle UNBOUND_CLASS_TEMPLATE at a higher level in
> the function, like with an 'else if' before this 'else'?

Maybe, but I think I'd have to duplicate (parts of) this block:

 4227   else if (scope)
 4228 {
 4229   if (TREE_CODE (decl) == SCOPE_REF)
 4230 {
 4231   gcc_assert (same_type_p (scope, TREE_OPERAND (decl, 0)));
 4232   decl = TREE_OPERAND (decl, 1);
 4233 }
 4234
 4235   decl = (adjust_result_of_qualified_name_lookup
 4236   (decl, scope, current_nonlambda_class_type()));
 4237
 4238   cp_warn_deprecated_use_scopes (scope);
 4239
 4240   if (TYPE_P (scope))
 4241 decl = finish_qualified_id_expr (scope,
 4242  decl,
 4243  done,
 4244  address_p,
 4245  template_p,
 4246  template_arg_p,
 4247  tf_warning_or_error);
 4248   else
 4249 decl = convert_from_reference (decl);
 4250 }

Would that be acceptable?  Can't do

  else if (TREE_CODE (decl) == UNBOUND_CLASS_TEMPLATE)
{
  gcc_checking_assert (scope);
  *idk = CP_ID_KIND_QUALIFIED;
  goto do_scope;
}
because that will complain about skipping the initialization of dependent_p.

Here's a patch with the partial duplication, which passes dg.exp:

-- >8 --
As discussed here:
,
type_dependent_expression_p should not be called with a type argument.

I promised I'd add an assert so here it is.  One place needed adjusting.

PR c++/99080

gcc/cp/ChangeLog:

* pt.cc (type_dependent_expression_p): Assert !TYPE_P.
* semantics.cc (finish_id_expression_1): Handle UNBOUND_CLASS_TEMPLATE
specifically.
---
 gcc/cp/pt.cc|  2 ++
 gcc/cp/semantics.cc | 11 +++
 2 files changed, 13 insertions(+)

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 24bbe2f4060..89156cb88b4 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27727,6 +27727,8 @@ type_dependent_expression_p (tree expression)
   if (expression == NULL_TREE || expression == error_mark_node)
 return false;
 
+  gcc_checking_assert (!TYPE_P (expression));
+
   STRIP_ANY_LOCATION_WRAPPER (expression);
 
   /* An unresolved name is always dependent.  */
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index cdc91a38e25..f62b0a4a736 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -4139,6 +4139,17 @@ finish_id_expression_1 (tree id_expression,
}
   return r;
 }
+  else if (TREE_CODE (decl) == UNBOUND_CLASS_TEMPLATE)
+{
+  gcc_checking_assert (scope);
+  *idk = CP_ID_KIND_QUALIFIED;
+  decl = (adjust_result_of_qualified_name_lookup
+ (decl, scope, current_nonlambda_class_type()));
+  cp_warn_deprecated_use_scopes (scope);
+  decl = finish_qualified_id_expr (scope, decl, done, address_p,
+

Re: [PATCH] c++: Fix ICE with -Wmismatched-tags [PR105725]

[Jason Merrill via Gcc-patches]

On 5/27/22 11:46, Marek Polacek wrote:

Here we ICE with -Wmismatched-tags on something like

   template 
   bool B>>;

Specifically, the "class T::foo" bit.  There, class_decl_loc_t::add gets
a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking
TYPE_BEING_DEFINED will crash.  I think it's OK to allow a TYPENAME_TYPE to
slip into that function; we just shouldn't consider the 'class' tag redundant
(which works as a 'typename').  In fact, every other compiler *requires* it.

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


OK.


PR c++/105725

gcc/cp/ChangeLog:

* parser.cc (class_decl_loc_t::add): Check CLASS_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-tags-10.C: New test.
---
  gcc/cp/parser.cc|  5 +++--
  gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C | 10 ++
  2 files changed, 13 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 4b9859543ed..9a9f859974a 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -33666,7 +33666,8 @@ class_decl_loc_t::add (cp_parser *parser, location_t 
key_loc,
bool key_redundant = (!def_p && !decl_p
&& (decl == type_decl
|| TREE_CODE (decl) == TEMPLATE_DECL
-   || TYPE_BEING_DEFINED (type)));
+   || (CLASS_TYPE_P (type)
+   && TYPE_BEING_DEFINED (type;
  
if (key_redundant

&& class_key != class_type
@@ -33704,7 +33705,7 @@ class_decl_loc_t::add (cp_parser *parser, location_t 
key_loc,
}
else
{
- /* TYPE was previously defined in some unknown precompiled hdeader.
+ /* TYPE was previously defined in some unknown precompiled header.
 Simply add a record of its definition at an unknown location and
 proceed below to add a reference to it at the current location.
 (Declarations in precompiled headers that are not definitions
diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C 
b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C
new file mode 100644
index 000..d7e10743bb4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C
@@ -0,0 +1,10 @@
+// PR c++/105725
+// { dg-do compile { target c++14 } }
+// { dg-options "-Wall -Wmismatched-tags" }
+
+template  struct enable_if;
+template  using enable_if_t = typename enable_if::type;
+template  bool is_class_v;
+template  bool B;
+template 
+bool B>>;

base-commit: de57440858591a88e8fd7ba2505ca54546c86021

Re: [PATCH] c-family: fix attribute constructor ICE [PR90658]

[Jason Merrill via Gcc-patches]

On 5/26/22 20:34, Marek Polacek wrote:

Here the C compiler crashes because a FUNCTION_DECL got into
get_priority -> default_conversion, and the C FE's version of d_c
specifically asserts that it doesn't get a FUNCTION_DECL.  All uses
of default_conversion in c-attribs.cc are guarded by != IDENTIFIER_NODE
&& != FUNCTION_DECL, but get_priority was only checking IDENTIFIER_NODE.

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


OK.


PR c/90658

gcc/c-family/ChangeLog:

* c-attribs.cc (get_priority): Check FUNCTION_DECL.

gcc/testsuite/ChangeLog:

* c-c++-common/attr-cdtor-1.c: New test.
---
  gcc/c-family/c-attribs.cc | 2 +-
  gcc/testsuite/c-c++-common/attr-cdtor-1.c | 6 ++
  2 files changed, 7 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/c-c++-common/attr-cdtor-1.c

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 4dc68dbe82a..c8d96723f4c 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -1895,7 +1895,7 @@ get_priority (tree args, bool is_destructor)
  }
  
arg = TREE_VALUE (args);

-  if (TREE_CODE (arg) == IDENTIFIER_NODE)
+  if (TREE_CODE (arg) == IDENTIFIER_NODE || TREE_CODE (arg) == FUNCTION_DECL)
  goto invalid;
if (arg == error_mark_node)
  return DEFAULT_INIT_PRIORITY;
diff --git a/gcc/testsuite/c-c++-common/attr-cdtor-1.c 
b/gcc/testsuite/c-c++-common/attr-cdtor-1.c
new file mode 100644
index 000..ea61336c404
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-cdtor-1.c
@@ -0,0 +1,6 @@
+/* PR c/90658 */
+/* { dg-do compile } */
+
+void f ();
+void g1 () __attribute__ ((constructor(f))); /* { dg-error "priorities must be 
integers" } */
+void g2 () __attribute__ ((destructor(f))); /* { dg-error "priorities must be 
integers" } */

base-commit: 367740bf6d3a6627798b3955e5d85efc7549ef50

Re: [PATCH] c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]

[Jason Merrill via Gcc-patches]

On 5/26/22 20:33, Marek Polacek wrote:

As discussed here:
,
type_dependent_expression_p should not be called with a type argument.

I promised I'd add an assert so here it is.  One place needed adjusting,
the comment explains why.

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

PR c++/99080

gcc/cp/ChangeLog:

* pt.cc (type_dependent_expression_p): Assert !TYPE_P.
* semantics.cc (finish_id_expression_1): Don't call
type_dependent_expression_p for a type.
---
  gcc/cp/pt.cc| 2 ++
  gcc/cp/semantics.cc | 4 +++-
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 24bbe2f4060..89156cb88b4 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27727,6 +27727,8 @@ type_dependent_expression_p (tree expression)
if (expression == NULL_TREE || expression == error_mark_node)
  return false;
  
+  gcc_checking_assert (!TYPE_P (expression));

+
STRIP_ANY_LOCATION_WRAPPER (expression);
  
/* An unresolved name is always dependent.  */

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index cd7a2818feb..7f8502f49b0 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -4141,7 +4141,9 @@ finish_id_expression_1 (tree id_expression,
  }
else
  {
-  bool dependent_p = type_dependent_expression_p (decl);
+  /* DECL could be e.g. UNBOUND_CLASS_TEMPLATE which is a type which
+t_d_e_p doesn't accept.  */
+  bool dependent_p = !TYPE_P (decl) && type_dependent_expression_p (decl);


Maybe instead we could handle UNBOUND_CLASS_TEMPLATE at a higher level 
in the function, like with an 'else if' before this 'else'?



/* If the declaration was explicitly qualified indicate
 that.  The semantics of `A::f(3)' are different than

base-commit: 367740bf6d3a6627798b3955e5d85efc7549ef50

[PATCH] c++: Fix ICE with -Wmismatched-tags [PR105725]

[Marek Polacek via Gcc-patches]

Here we ICE with -Wmismatched-tags on something like

  template 
  bool B>>;

Specifically, the "class T::foo" bit.  There, class_decl_loc_t::add gets
a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking
TYPE_BEING_DEFINED will crash.  I think it's OK to allow a TYPENAME_TYPE to
slip into that function; we just shouldn't consider the 'class' tag redundant
(which works as a 'typename').  In fact, every other compiler *requires* it.

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

PR c++/105725

gcc/cp/ChangeLog:

* parser.cc (class_decl_loc_t::add): Check CLASS_TYPE_P.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wmismatched-tags-10.C: New test.
---
 gcc/cp/parser.cc|  5 +++--
 gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C | 10 ++
 2 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C

diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 4b9859543ed..9a9f859974a 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -33666,7 +33666,8 @@ class_decl_loc_t::add (cp_parser *parser, location_t 
key_loc,
   bool key_redundant = (!def_p && !decl_p
&& (decl == type_decl
|| TREE_CODE (decl) == TEMPLATE_DECL
-   || TYPE_BEING_DEFINED (type)));
+   || (CLASS_TYPE_P (type)
+   && TYPE_BEING_DEFINED (type;
 
   if (key_redundant
   && class_key != class_type
@@ -33704,7 +33705,7 @@ class_decl_loc_t::add (cp_parser *parser, location_t 
key_loc,
}
   else
{
- /* TYPE was previously defined in some unknown precompiled hdeader.
+ /* TYPE was previously defined in some unknown precompiled header.
 Simply add a record of its definition at an unknown location and
 proceed below to add a reference to it at the current location.
 (Declarations in precompiled headers that are not definitions
diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C 
b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C
new file mode 100644
index 000..d7e10743bb4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-10.C
@@ -0,0 +1,10 @@
+// PR c++/105725
+// { dg-do compile { target c++14 } }
+// { dg-options "-Wall -Wmismatched-tags" }
+
+template  struct enable_if;
+template  using enable_if_t = typename enable_if::type;
+template  bool is_class_v;
+template  bool B;
+template 
+bool B>>;

base-commit: de57440858591a88e8fd7ba2505ca54546c86021
-- 
2.36.1

Re: [Patch] OpenMP/Fortran: Add support for enter clause on declare target (was: [committed] openmp: Add support for enter clause on declare target)

[Jakub Jelinek via Gcc-patches]

On Fri, May 27, 2022 at 05:20:08PM +0200, Jakub Jelinek wrote:
> 2) move the
>   else if (n->sym->mark)
> gfc_error_now ("Variable at %L mentioned multiple times in "
>"clauses of the same OMP DECLARE TARGET directive",
>&n->where);
>   diagnostics earlier, above
>   else if (n->sym->attr.omp_declare_target
>&& n->sym->attr.omp_declare_target_link
>&& list != OMP_LIST_LINK)
>   and adjust testsuite if needed

Note, that matches what the C/C++ FEs do, they also first check for clauses
on the same construct and only afterwards do the link vs. to/enter on
separate directives.

Here is an incremental patch I plan to commit after full testing for the
C/C++ FE wording.

2022-05-27  Jakub Jelinek  

gcc/c/
* c-parser.cc (c_parser_omp_declare_target): If OMP_CLAUSE_LINK was
seen first, use "%" or "%" depending on
OMP_CLAUSE_ENTER_TO of the current clause, otherwise use
"% or %" wording.
gcc/cp/
* parser.c (handle_omp_declare_target_clause): If OMP_CLAUSE_LINK was
seen first, use "%" or "%" depending on
OMP_CLAUSE_ENTER_TO of the current clause, otherwise use
"% or %" wording.
gcc/testsuite/
* c-c++-common/gomp/declare-target-2.c: Add further tests for mixing of
link and to/enter clauses on separate directives.

--- gcc/c/c-parser.cc.jj2022-05-26 23:22:30.312850583 +0200
+++ gcc/c/c-parser.cc   2022-05-27 17:28:59.120420300 +0200
@@ -22067,9 +22067,14 @@ c_parser_omp_declare_target (c_parser *p
id = get_identifier ("omp declare target");
   if (at2)
{
- error_at (OMP_CLAUSE_LOCATION (c),
-   "%qD specified both in declare target % and %"
-   " clauses", t);
+ if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_ENTER)
+   error_at (OMP_CLAUSE_LOCATION (c),
+ "%qD specified both in declare target % and %qs"
+ " clauses", t, OMP_CLAUSE_ENTER_TO (c) ? "to" : "enter");
+ else
+   error_at (OMP_CLAUSE_LOCATION (c),
+ "%qD specified both in declare target % and "
+ "% or % clauses", t);
  continue;
}
   if (!at1)
--- gcc/cp/parser.cc.jj 2022-05-26 23:22:30.306850645 +0200
+++ gcc/cp/parser.cc2022-05-27 17:31:19.086980582 +0200
@@ -45991,9 +45991,14 @@ handle_omp_declare_target_clause (tree c
 id = get_identifier ("omp declare target");
   if (at2)
 {
-  error_at (OMP_CLAUSE_LOCATION (c),
-   "%qD specified both in declare target % and %"
-   " clauses", t);
+  if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_ENTER)
+   error_at (OMP_CLAUSE_LOCATION (c),
+ "%qD specified both in declare target % and %qs"
+ " clauses", t, OMP_CLAUSE_ENTER_TO (c) ? "to" : "enter");
+  else
+   error_at (OMP_CLAUSE_LOCATION (c),
+ "%qD specified both in declare target % and "
+ "% or % clauses", t);
   return false;
 }
   if (!at1)
--- gcc/testsuite/c-c++-common/gomp/declare-target-2.c.jj   2022-05-27 
12:31:36.114087022 +0200
+++ gcc/testsuite/c-c++-common/gomp/declare-target-2.c  2022-05-27 
17:38:12.173731493 +0200
@@ -10,7 +10,22 @@ int b;
 #pragma omp declare target enter (b) link (b)  /* { dg-error "appears more 
than once on the same .declare target. directive" } */
 int c;
 #pragma omp declare target (c)
-#pragma omp declare target link (c)/* { dg-error "specified both 
in declare target" } */
+#pragma omp declare target link (c)/* { dg-error "specified both 
in declare target 'link' and 'to' or 'enter' clauses" } */
+int c2;
+#pragma omp declare target to (c2)
+#pragma omp declare target link (c2)   /* { dg-error "specified both 
in declare target 'link' and 'to' or 'enter' clauses" } */
+int c3;
+#pragma omp declare target enter (c3)
+#pragma omp declare target link (c3)   /* { dg-error "specified both 
in declare target 'link' and 'to' or 'enter' clauses" } */
+int c4;
+#pragma omp declare target link (c4)
+#pragma omp declare target (c4)/* { dg-error 
"specified both in declare target 'link' and 'enter' clauses" } */
+int c5;
+#pragma omp declare target link (c5)
+#pragma omp declare target to (c5) /* { dg-error "specified both 
in declare target 'link' and 'to' clauses" } */
+int c6;
+#pragma omp declare target link (c6)
+#pragma omp declare target enter (c6)  /* { dg-error "specified both 
in declare target 'link' and 'enter' clauses" } */
 int foo (void);
 #pragma omp declare target link (foo)  /* { dg-error "is not a 
variable in clause" } */
 struct S;

Jakub

Re: [Patch] OpenMP/Fortran: Add support for enter clause on declare target (was: [committed] openmp: Add support for enter clause on declare target)

[Jakub Jelinek via Gcc-patches]

On Fri, May 27, 2022 at 04:52:17PM +0200, Tobias Burnus wrote:
> This patch adds the Fortran support to the just-committed C/C++ support for 
> the 'enter' clause.
> 
> The 'TO'/'ENTER' usage is first stored in a linked list – and
> then as attribute to the symbol. I am not sure how to handle it best.
> I did went for adding an ENTER_LIST but kept only using the single attribute.
> 
> Result: In one diagnostic, I use 'TO or ENTER clause'  in the other,
> I can properly use 'TO' or 'ENTER' clause.
> 
> This could be kept as is, but to save memory it would be possible
> to drop the ENTER_LIST – or, to improve diagnostic, we could try harder
> (e.g. by re-walking the list or by another gfc_attribute). Preferences?
> If not, I would go for the attached middle way.
> 
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

> OpenMP/Fortran: Add support for enter clause on declare target
> 
> Fortran version to C/C++ commit r13-797-g0ccba4ed8571c18c7015413441e971
> 
> gcc/fortran/ChangeLog:
> 
>   * dump-parse-tree.cc (show_omp_clauses): Handle OMP_LIST_ENTER.
>   * gfortran.h: Add OMP_LIST_ENTER.
>   * openmp.cc (enum omp_mask2, OMP_DECLARE_TARGET_CLAUSES): Add
>   OMP_CLAUSE_ENTER.
>   (gfc_match_omp_clauses, gfc_match_omp_declare_target,
>   resolve_omp_clauses): Handle 'enter' clause.
> 
> libgomp/ChangeLog:
> 
>   * libgomp.texi (OpenMP 5.2): Mark 'enter' clause as supported.
>   * testsuite/libgomp.fortran/declare-target-1.f90: Extend to test
>   explicit 'to' and 'enter' clause.
>   * testsuite/libgomp.fortran/declare-target-2.f90: Update accordingly.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gfortran.dg/gomp/declare-target-2.f90: Add 'enter' clause test.
>   * gfortran.dg/gomp/declare-target-4.f90: Likewise.

Mostly good, but see below.

> -  for (list = OMP_LIST_TO; list != OMP_LIST_NUM;
> -   list = (list == OMP_LIST_TO ? OMP_LIST_LINK : OMP_LIST_NUM))
> +  for (list = OMP_LIST_ENTER; list != OMP_LIST_NUM;
> +   list = (list == OMP_LIST_ENTER
> +? OMP_LIST_TO
> +: (list == OMP_LIST_TO ? OMP_LIST_LINK : OMP_LIST_NUM)))
>  for (n = c->lists[list]; n; n = n->next)
>if (n->sym)
>   {
> @@ -4564,14 +4584,14 @@ gfc_match_omp_declare_target (void)
>  && n->sym->attr.omp_declare_target_link
>  && list != OMP_LIST_LINK)
>   gfc_error_now ("OMP DECLARE TARGET variable at %L previously "
> -"mentioned in LINK clause and later in TO clause",
> -&n->where);
> +"mentioned in LINK clause and later in %s clause",
> +&n->where, list == OMP_LIST_TO ? "TO" : "ENTER");
> else if (n->sym->attr.omp_declare_target
>  && !n->sym->attr.omp_declare_target_link
>  && list == OMP_LIST_LINK)
>   gfc_error_now ("OMP DECLARE TARGET variable at %L previously "
> -"mentioned in TO clause and later in LINK clause",
> -&n->where);
> +"mentioned in TO or ENTER clause and later in "
> +"LINK clause", &n->where);

The wording of the messages "previously mentioned in FOO and later in BAR 
clause"
makes not much sense to me, because we in the Fortran FE don't remember which
clause was specified earlier and which one was later.
The loop is walking first all enter clauses, then all to clauses, then all
link clauses.

Now, if we change the wording so that it complains that a variable is
"mentioned in both FOO and BAR clauses", we could avoid the TO or ENTER
stuff even without some O(n^2) complexity or extra bit somewhere simply
by walking the clauses in the order of TO, LINK, ENTER (or ENTER, LINK, TO)
clauses, wer could be exact.

Though, further thinking about it, this isn't just about the case
where it is on the same declare target, but also on multiple and in that
case previous/later makes sense.

As we don't remember if it was previously TO or ENTER, I'd just suggest:
1) simplify the 2 for cycles, with 3 lists it is too unreadable, so use
   something like:
  static const int to_enter_link_lists[]
= { OMP_LIST_TO, OMP_LIST_ENTER, OMP_LIST_LINK };
  for (int listn = 0; listn < ARRAY_SIZE (to_enter_link_lists)
  && (list = to_enter_link_lists[listn], true); ++listn)
2) move the
  else if (n->sym->mark)
gfc_error_now ("Variable at %L mentioned multiple times in "
   "clauses of the same OMP DECLARE TARGET directive",
   &n->where);
  diagnostics earlier, above
  else if (n->sym->attr.omp_declare_target
   && n->sym->attr.omp_declare_target_

[PATCH] libgfortran: Use `__gthread_t` instead of `pthread_t`

[LIU Hao via Gcc-patches]

The attached patch addresses a build issue when  is not included. 
Please review.


--
Best regards,
LIU Hao
From 7b573e4cdb7c3b666baac4c38046c64a01b6dcb5 Mon Sep 17 00:00:00 2001
From: LIU Hao 
Date: Fri, 27 May 2022 23:12:48 +0800
Subject: [PATCH] libgfortran: Use `__gthread_t` instead of `pthread_t`

It used to cause errors if a thread model other than `posix` was selected,
which looks like a leftover from a79878585a1c5e32bafbc6d1e73f91fd6e4293bf.

2022-05-27  LIU Hao 

libgfortran/
* io/async.h (struct async_unit): Use `__gthread_t` instead
of `pthread_t`.
---
 libgfortran/io/async.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgfortran/io/async.h b/libgfortran/io/async.h
index efd542a45e8..d57722a95e4 100644
--- a/libgfortran/io/async.h
+++ b/libgfortran/io/async.h
@@ -351,7 +351,7 @@ typedef struct async_unit
   struct adv_cond work;
   struct adv_cond emptysignal;
   struct st_parameter_dt *pdt;
-  pthread_t thread;
+  __gthread_t thread;
   struct transfer_queue *head;
   struct transfer_queue *tail;
 
-- 
2.20.1



OpenPGP_signature
Description: OpenPGP digital signature

[Patch] OpenMP/Fortran: Add support for enter clause on declare target (was: [committed] openmp: Add support for enter clause on declare target)

[Tobias Burnus]

This patch adds the Fortran support to the just-committed C/C++ support for the 
'enter' clause.

The 'TO'/'ENTER' usage is first stored in a linked list – and
then as attribute to the symbol. I am not sure how to handle it best.
I did went for adding an ENTER_LIST but kept only using the single attribute.

Result: In one diagnostic, I use 'TO or ENTER clause'  in the other,
I can properly use 'TO' or 'ENTER' clause.

This could be kept as is, but to save memory it would be possible
to drop the ENTER_LIST – or, to improve diagnostic, we could try harder
(e.g. by re-walking the list or by another gfc_attribute). Preferences?
If not, I would go for the attached middle way.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
OpenMP/Fortran: Add support for enter clause on declare target

Fortran version to C/C++ commit r13-797-g0ccba4ed8571c18c7015413441e971

gcc/fortran/ChangeLog:

	* dump-parse-tree.cc (show_omp_clauses): Handle OMP_LIST_ENTER.
	* gfortran.h: Add OMP_LIST_ENTER.
	* openmp.cc (enum omp_mask2, OMP_DECLARE_TARGET_CLAUSES): Add
	OMP_CLAUSE_ENTER.
	(gfc_match_omp_clauses, gfc_match_omp_declare_target,
	resolve_omp_clauses): Handle 'enter' clause.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.2): Mark 'enter' clause as supported.
	* testsuite/libgomp.fortran/declare-target-1.f90: Extend to test
	explicit 'to' and 'enter' clause.
	* testsuite/libgomp.fortran/declare-target-2.f90: Update accordingly.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/declare-target-2.f90: Add 'enter' clause test.
	* gfortran.dg/gomp/declare-target-4.f90: Likewise.

 gcc/fortran/dump-parse-tree.cc |  1 +
 gcc/fortran/gfortran.h |  1 +
 gcc/fortran/openmp.cc  | 59 +++---
 .../gfortran.dg/gomp/declare-target-2.f90  | 18 +--
 .../gfortran.dg/gomp/declare-target-4.f90  |  9 +++-
 libgomp/libgomp.texi   |  2 +-
 .../testsuite/libgomp.fortran/declare-target-1.f90 |  4 +-
 .../testsuite/libgomp.fortran/declare-target-2.f90 | 10 +++-
 8 files changed, 76 insertions(+), 28 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 4e8986bd599..e3affb8bc48 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -1679,6 +1679,7 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
 	  case OMP_LIST_IN_REDUCTION: type = "IN_REDUCTION"; break;
 	  case OMP_LIST_TASK_REDUCTION: type = "TASK_REDUCTION"; break;
 	  case OMP_LIST_DEVICE_RESIDENT: type = "DEVICE_RESIDENT"; break;
+	  case OMP_LIST_ENTER: type = "ENTER"; break;
 	  case OMP_LIST_LINK: type = "LINK"; break;
 	  case OMP_LIST_USE_DEVICE: type = "USE_DEVICE"; break;
 	  case OMP_LIST_CACHE: type = "CACHE"; break;
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 5d970bc1df0..0bac8657790 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1395,6 +1395,7 @@ enum
   OMP_LIST_NONTEMPORAL,
   OMP_LIST_ALLOCATE,
   OMP_LIST_HAS_DEVICE_ADDR,
+  OMP_LIST_ENTER,
   OMP_LIST_NUM /* Must be the last.  */
 };
 
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index efa62b64f2b..66c30ebea51 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -986,6 +986,7 @@ enum omp_mask2
   OMP_CLAUSE_ATTACH,
   OMP_CLAUSE_NOHOST,
   OMP_CLAUSE_HAS_DEVICE_ADDR,  /* OpenMP 5.1  */
+  OMP_CLAUSE_ENTER, /* OpenMP 5.2 */
   /* This must come last.  */
   OMP_MASK2_LAST
 };
@@ -2101,6 +2102,16 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const omp_mask mask,
 		continue;
 	}
 	  break;
+	case 'e':
+	  if ((mask & OMP_CLAUSE_ENTER))
+	{
+	  m = gfc_match_omp_to_link ("enter (", &c->lists[OMP_LIST_ENTER]);
+	  if (m == MATCH_ERROR)
+		goto error;
+	  if (m == MATCH_YES)
+		continue;
+	}
+	  break;
 	case 'f':
 	  if ((mask & OMP_CLAUSE_FAIL)
 	  && (m = gfc_match_dupl_check (c->fail == OMP_MEMORDER_UNSET,
@@ -2921,8 +2932,12 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const omp_mask mask,
 	continue;
 	  if ((mask & OMP_CLAUSE_TO) && (mask & OMP_CLAUSE_LINK))
 	{
-	  if (gfc_match_omp_to_link ("to (", &c->lists[OMP_LIST_TO])
-		  == MATCH_YES)
+	  /* Declare target: 'to' is an alias for 'enter';
+		 'to' is deprecated since 5.2.  */
+	  m = gfc_match_omp_to_link ("to (", &c->lists[OMP_LIST_TO]);
+	  if (m == MATCH_ERROR)
+		goto error;
+	  if (m == MATCH_YES)
 		continue;
 	}
 	  else if ((mask & OMP_CLAUSE_TO)
@@ -3724,7 +3739,8 @@ cleanup:
 #define OMP_ORDERED_CLAUSES \
   (omp_mask (OMP_CLAUSE_THREADS) | OMP_CLAUSE_SIMD)
 #define OMP_DECLARE_TARGET_CLAUSES \
-  (omp_mask (OMP_CLAUSE_TO) | OMP_CLAUSE_LINK | OMP_CLAUSE_DEVICE_TYPE)
+  (omp_mask (OMP_CLAUSE_ENTER) | OMP_

[committed] libstdc++: Mark non-exported function always_inline [PR105671]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk. Backports to gcc-12 and
gcc-11 will be done early next month.

-- >8 --

This new function was added for gcc 11.1 but is not exported from the
shared library. Depending on inlining decisions, its callers might get
inlined but an external definition be needed for this function. That
then fails to link.

Since we can't add the export to the gcc-11 release branch now, mark it
always_inline. We can consider exporting it for gcc-13 if/when we bump
the shared library version (and maybe also for gcc-12 which is currently
at the same version as trunk). For now, the attribute will solve the
problem on all affected branches. The function is small enough that
force-inlining it shouldn't cause problems.

libstdc++-v3/ChangeLog:

PR libstdc++/105671
* include/std/sstream (basic_stringbuf::_M_high_mark): Add
always_inline attribute.
---
 libstdc++-v3/include/std/sstream | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/include/std/sstream b/libstdc++-v3/include/std/sstream
index bb25c2c69a9..bc7d636e702 100644
--- a/libstdc++-v3/include/std/sstream
+++ b/libstdc++-v3/include/std/sstream
@@ -425,6 +425,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   // This might not be the same character as _M_string.end() because
   // basic_stringbuf::overflow might have written to unused capacity
   // in _M_string without updating its length.
+  __attribute__((__always_inline__))
   char_type*
   _M_high_mark() const _GLIBCXX_NOEXCEPT
   {
-- 
2.34.3

Re: [PATCH] c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

[Patrick Palka via Gcc-patches]

On Thu, 26 May 2022, Patrick Palka wrote:

> On Thu, 26 May 2022, Jason Merrill wrote:
> 
> > On 5/26/22 14:57, Patrick Palka wrote:
> > > On Thu, 26 May 2022, Patrick Palka wrote:
> > > 
> > > > Here we expect the calls to BaseClass::baseDevice resolve to the second,
> > > > third and fourth overloads respectively in light of the cv-qualifiers
> > > > of 'this' in each case.  But ever since r12-6075-g2decd2cabe5a4f, the
> > > > calls incorrectly resolve to the first overload at instantiation time.
> > > > 
> > > > This happens because the calls to BaseClass::baseDevice are all deemed
> > > > non-dependent (ever since r7-755-g23cb72663051cd made us ignore the
> > > > dependentness of 'this' when considering the dependence of a non-static
> > > > memfn call), hence we end up checking the call ahead of time, using as
> > > > the object argument a dummy object of type BaseClass.  Since this object
> > > > argument is cv-unqualified, the calls incoherently resolve to the first
> > > > overload of baseDevice.  Before r12-6075, this incorrect result would
> > > > just get silently discarded and we'd end up redoing OR at instantiation
> > > > time using 'this' as the object argument.  But after r12-6075, we now
> > > > reuse this incorrect result at instantiation time.
> > > > 
> > > > This patch fixes this by making finish_call_expr request from
> > > > maybe_dummy_object a cv-qualified object consistent with the cv-quals of
> > > > 'this'.  That way, ahead of time OR using a dummy object will give us
> > > > the right answer and we could safely reuse it at instantiation time.
> > > > 
> > > > NB: r7-755 is also the cause of the related issue PR105742.  Not sure
> > > > if there's a fix that could resolve both PRs at once..
> > > > 
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > for trunk/12?
> > > > 
> > > > PR c++/105637
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * semantics.cc (finish_call_expr): Pass a cv-qualified object
> > > > type to maybe_dummy_object that is consistent with the
> > > > cv-qualifiers of 'this' if available.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > * g++.dg/template/non-dependent23.C: New test.
> > > > ---
> > > >   gcc/cp/semantics.cc   | 15 ---
> > > >   .../g++.dg/template/non-dependent23.C | 25 +++
> > > >   2 files changed, 37 insertions(+), 3 deletions(-)
> > > >   create mode 100644 gcc/testsuite/g++.dg/template/non-dependent23.C
> > > > 
> > > > diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> > > > index cd7a2818feb..1d9348c6cf1 100644
> > > > --- a/gcc/cp/semantics.cc
> > > > +++ b/gcc/cp/semantics.cc
> > > > @@ -2802,16 +2802,25 @@ finish_call_expr (tree fn, vec
> > > > **args, bool disallow_virtual,
> > > > [class.access.base] says that we need to convert 'this' to B* as
> > > > part of the access, so we pass 'B' to maybe_dummy_object.  */
> > > >   +  tree object_type = BINFO_TYPE (BASELINK_ACCESS_BINFO (fn));
> > > > if (DECL_MAYBE_IN_CHARGE_CONSTRUCTOR_P (get_first_fn (fn)))
> > > > {
> > > >   /* A constructor call always uses a dummy object.  (This 
> > > > constructor
> > > >  call which has the form A::A () is actually invalid and we 
> > > > are
> > > >  going to reject it later in build_new_method_call.)  */
> > > > - object = build_dummy_object (BINFO_TYPE (BASELINK_ACCESS_BINFO
> > > > (fn)));
> > > > + object = build_dummy_object (object_type);
> > > > }
> > > > else
> > > > -   object = maybe_dummy_object (BINFO_TYPE (BASELINK_ACCESS_BINFO 
> > > > (fn)),
> > > > -NULL);
> > > > +   {
> > > > + if (current_class_ref)
> > > > +   {
> > > > + /* Make sure that if maybe_dummy_object gives us a dummy 
> > > > object,
> > > > +it'll have the same cv-quals as '*this'.  */
> > > > + int quals = cp_type_quals (TREE_TYPE (current_class_ref));
> > > > + object_type = cp_build_qualified_type (object_type, 
> > > > quals);
> > > > +   }
> > > > + object = maybe_dummy_object (object_type, NULL);
> > > > +   }
> > > >   result = build_new_method_call (object, fn, args, NULL_TREE,
> > > >   (disallow_virtual
> > > 
> > > Drat, this fix doesn't interact well with 'this'-capturing lambdas:
> > > 
> > >  struct BaseClass {
> > >void baseDevice();// #1
> > >void baseDevice() const = delete; // #2
> > >  };
> > > 
> > >  template
> > >  struct TopClass : T {
> > >void failsToCompile() {
> > >  [this] { BaseClass::baseDevice(); }();
> > >}
> > >  };
> > > 
> > >  template struct TopClass;
> > > 
> > > Here after the fix, we'd incorrectly select the const #2 overload at

Re: libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

[Ian Lance Taylor via Gcc-patches]

On Fri, May 27, 2022 at 12:17 AM Simon Sobisch via Gcc-patches
 wrote:
>
> As noted: the first question is: is it reasonable to add support for
> GnuCOBOL?

It seems fine to me to add support for demangling GnuCOBOL symbol
names controlled by a DMGL option (options are defined in
include/demangle.h).


> * How would the demangler know it is to be called? Just "best match"
> (GnuCOBOL modules always have some symbols in it which should be
> available if there is any debugging information in, if that helps)?
> * Giving the work of gcc-cobol which was discussed on this mailing list
> some months ago (not sure about its current state) there possibly will
> be a COBOL support be "integrated" - with possibly different name
> mangling. But still - GnuCOBOL is used "in the wild" (for production
> environments) since years (and will be for many years to come, both
> based on GCC and with other compilers) and the name mangling rules did
> not change.

The demangler doesn't see a list of symbol names, it only sees a
single string at a time.  If GnuCOBOL symbols are to be demangled by
default, then there must be a clear distinction between COBOL names
and other names.  For example, C++ demangled names, with a few minor
exceptions, always start with "_Z".  If there is no such marker then
we would have to require that the names only be demangle with a DMGL
option.  There could be a corresponding command line option for
c++filt.

Ian

Re: [PATCH 7/7] openmp: Add testcases for metadirectives

[Jakub Jelinek via Gcc-patches]

On Fri, Dec 10, 2021 at 05:40:36PM +, Kwok Cheung Yeung wrote:
> This adds testcases for metadirectives.

Let me start with the last patch.

> +++ b/gcc/testsuite/c-c++-common/gomp/metadirective-1.c
> @@ -0,0 +1,29 @@
> +/* { dg-do compile } */
> +
> +#define N 100
> +
> +void f (int a[], int b[], int c[])
> +{
> +  #pragma omp metadirective \
> +  default (teams loop) \
> +  default (parallel loop) /* { dg-error "there can only be one default 
> clause in a metadirective before '\\(' token" } */

I'd prefer consistency, check_no_duplicate_clause prints for similar bugs
too many %qs clauses
so it would be nice if this emitted the same (and the before '\\(' token
part would be nice to avoid as well (i.e. use error rather than parse
error).

> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/metadirective-2.c
> @@ -0,0 +1,74 @@
> +/* { dg-do compile } */
> +
> +#define N 100
> +
> +int main (void)
> +{
> +  int x = 0;
> +  int y = 0;
> +
> +  /* Test implicit default (nothing).  */
> +  #pragma omp metadirective \
> +  when (device={arch("nvptx")}: barrier)
> +x = 1;

I'm not really sure if device={arch("nvptx")} in main is
the best idea for most of such tests.
Because we should be able to decide that right away, main isn't
declare target to (and better shouldn't be) and so when we know host
isn't nvptx and that it won't be offloaded, it is clear it can't be
that arch.
Of course, we need to test such a case too in a few spots, but it would
be nice to have more diversity in the tests.
One possibility is non-main function with declare target to after the
function definition (but one can't then use teams in the metadirectives).
But would be nice to use more variety in selectors, user, implementation, device
with isa or kind, etc. instead of using always the same thing in most of the
tests.

Also it would be nice to cover say a directive which needs loop, a directive
which needs a normal body and say 2 directives which are standalone.

> +++ b/gcc/testsuite/c-c++-common/gomp/metadirective-3.c
> @@ -0,0 +1,31 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-fdump-tree-original" } */
> +/* { dg-additional-options "-fdump-tree-gimple" } */
> +/* { dg-additional-options "-fdump-tree-optimized" } */
> +
> +#define N 100
> +
> +void f (int x[], int y[], int z[])
> +{
> +  int i;
> +
> +  #pragma omp target map(to: x, y) map(from: z)
> +#pragma omp metadirective \
> + when (device={arch("nvptx")}: teams loop) \
> + default (parallel loop)

It would be nice to have many of the tests where all the metadirective
variants are actually possible.  Here the nvptx variant
is quite unlikely, nvptx is rarely tested as host arch,
f is not declare target to and even if it was, teams is not allowed
inside of target regions like that.

> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/gomp/metadirective-4.c
> +
> +  /* TODO: This does not execute a version of f with the default clause
> + active as might be expected.  */

Might be nice to mention that it is correct 5.0 behavior, 5.1 is just
broken in this regard and 5.2 changed the behavior so that parallel loop
is actually invoked.

> +  f (a, 2.71828);

> +++ b/gcc/testsuite/c-c++-common/gomp/metadirective-5.c
> @@ -0,0 +1,24 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-fdump-tree-original" } */
> +
> +#define N 100
> +
> +void f (int a[], int flag)
> +{
> +  int i;
> +  #pragma omp metadirective \
> + when (user={condition(flag)}: \
> + target teams distribute parallel for map(from: a[0:N])) \
> + default (parallel for)
> +  for (i = 0; i < N; i++)
> +a[i] = i;
> +}
> +
> +/* The metadirective should be resolved at parse time.  */

???  How can it?  The above is invalid in OpenMP 5.0 (condition
should be constant expression), it is valid in OpenMP 5.1, but is then
resolved at runtime, certainly not at parse time.

Would be nice to also test user={condition(1)} etc. where it would
be resolved at parse time.
And, please add some tests even with user scores.

> +++ b/gcc/testsuite/c-c++-common/gomp/metadirective-6.c
> @@ -0,0 +1,31 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-fdump-tree-original" } */
> +/* { dg-additional-options "-fdump-tree-gimple" } */
> +
> +#define N 100
> +
> +void bar (int a[], int run_parallel, int run_guided)
> +{
> +  #pragma omp metadirective \
> + when (user={condition(run_parallel)}: parallel)
> +  {
> +int i;
> +#pragma omp metadirective \
> + when (construct={parallel}, user={condition(run_guided)}: \
> +   for schedule(guided)) \
> + when (construct={parallel}: for schedule(static))
> +  for (i = 0; i < N; i++)
> + a[i] = i;
> +   }
> + }
> +
> +/* The outer metadirective should be resolved at parse time.  */
> +/* The inner metadirective should be resolved during Gimplificiation.  */

Again, dynamic condition, so I don't see how this holds, both should be
resolved at runtime.

> +++ b/libgomp/testsuite

Re: [0/9] [middle-end] Add param to vec_perm_const hook to specify mode of input operand

[Richard Biener via Gcc-patches]

On Wed, May 25, 2022 at 10:24 PM Prathamesh Kulkarni
 wrote:
>
> On Thu, 26 May 2022 at 00:37, Richard Biener  
> wrote:
[...]
> > x86 now accepts V4SI V8SI permutes because we don’t ask it correctly and 
> > thus my naive attempt to use the new function API breaks . Not to mention 
> > the VEC_PERM IL is still rejected. I will wait for the rest of the series 
> > to be approved and pushed.
> Hi,
> I pushed the entire series in ae8decf1d2b8329af59592b4fa78ee8dfab3ba5e
> after it was approved by Richard S.

Thanks.

Maybe I'm doing it wrong but I now see

  indices.new_vector (mask, second_vec.first == -1U ? 1 : 2, nunits);
  bool identity_p = indices.series_p (0, 1, 0, 1);

where nunits is 4 and mask {4, 5, 6, 7}, the number of vectors is 1,
and now indices.series_p (0, 1, 0, 1) returns true despite my input
vector having 8 elements and 'indices' should select the upper half.
That's because the function calls clamp() on the encoding but
clamp() knows nothing about the different nunits of the input vectors.

I suppose vec_perm_indices needs updating to allow for different
nunits of the input vectors as well?

Where else does this change need adjustments to other APIs?

PR101668 has a naiive user of the new capability.  The included
testcase works OK but trying to expand test coverage quickly
runs into wrong-code, like for

typedef int v8si __attribute__((vector_size (32)));
typedef long long v4di __attribute__((vector_size (32)));

void
bar_s32_s64 (v4di * dst, v8si src)
{
  long long tem[8];
  tem[0] = src[4];
  tem[1] = src[5];
  tem[2] = src[6];
  tem[3] = src[7];
  dst[0] = *(v4di *) tem;
}

which I expected to be rejected with -mavx2.

Thanks,
Richard.

> Thanks,
> Prathamesh
> >
> > Richard.
> >
> > > Thanks,
> > > Prathamesh
> > >>
> > >> At least I have a user in the vectorizer ready - allowing more permutes
> > >> from existing vectors (of different sizes now) to be SLP vectorized.
> > >>
> > >> Thanks,
> > >> Richard.
> > >>
> > >>> Thanks,
> > >>> Prathamesh
> > 
> >  Richard

Re: [ping][vect-patterns] Refactor widen_plus/widen_minus as internal_fns

[Richard Biener via Gcc-patches]

On Wed, 25 May 2022, Joel Hutton wrote:

> Ping!
> 
> Just checking there is still interest in this. I'm assuming you've been 
> busy with release.

Can you post an updated patch (after the .cc renaming, and code_helper
now already moved to tree.h).

Thanks,
Richard.

> Joel
> 
> > -Original Message-
> > From: Joel Hutton
> > Sent: 13 April 2022 16:53
> > To: Richard Sandiford 
> > Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> > Subject: [vect-patterns] Refactor widen_plus/widen_minus as internal_fns
> > 
> > Hi all,
> > 
> > These patches refactor the widening patterns in vect-patterns to use
> > internal_fn instead of tree_codes.
> > 
> > Sorry about the delay, some changes to master made it a bit messier.
> > 
> > Bootstrapped and regression tested on aarch64.
> > 
> > Joel
> > 
> > > > diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
> > > > index 854cbcff390..4a8ea67e62f 100644
> > > > --- a/gcc/tree-vect-patterns.c
> > > > +++ b/gcc/tree-vect-patterns.c
> > > > @@ -1245,7 +1245,7 @@ vect_recog_sad_pattern (vec_info *vinfo,
> > > > static gimple *  vect_recog_widen_op_pattern (vec_info *vinfo,
> > > >  stmt_vec_info last_stmt_info, tree 
> > > > *type_out,
> > > > -tree_code orig_code, tree_code wide_code,
> > > > +tree_code orig_code, code_helper
> > > wide_code_or_ifn,
> > >
> > > I think it'd be better to keep the original ?wide_code? name and try
> > > to remove as many places as possible in which switching based on
> > > tree_code or internal_fn is necessary.  The recent gimple-match.h
> > > patches should help with that, but more routines might be needed.
> > 
> > Done.
> > 
> > > > @@ -1309,8 +1310,16 @@ vect_recog_widen_op_pattern (vec_info
> > *vinfo,
> > > >2, oprnd, half_type, unprom, vectype);
> > > >
> > > >tree var = vect_recog_temp_ssa_var (itype, NULL);
> > > > -  gimple *pattern_stmt = gimple_build_assign (var, wide_code,
> > > > - oprnd[0], oprnd[1]);
> > > > +  gimple *pattern_stmt;
> > > > +  if (wide_code_or_ifn.is_tree_code ())
> > > > +pattern_stmt = gimple_build_assign (var, wide_code_or_ifn,
> > > > +   oprnd[0], oprnd[1]);
> > > > +  else
> > > > +{
> > > > +  internal_fn fn = as_internal_fn ((combined_fn) wide_code_or_ifn);
> > > > +  pattern_stmt = gimple_build_call_internal (fn, 2, oprnd[0], 
> > > > oprnd[1]);
> > > > +  gimple_call_set_lhs (pattern_stmt, var);
> > > > +}
> > >
> > > For example, I think we should hide this inside a new:
> > >
> > >   gimple_build (var, wide_code, oprnd[0], oprnd[1]);
> > >
> > > that works directly on code_helper, similarly to the new code_helper
> > > gimple_build interfaces.
> > 
> > Done.
> > 
> > > > @@ -4513,14 +4513,16 @@ vect_gen_widened_results_half (vec_info
> > > *vinfo, enum tree_code code,
> > > >tree new_temp;
> > > >
> > > >/* Generate half of the widened result:  */
> > > > -  gcc_assert (op_type == TREE_CODE_LENGTH (code));
> > > >if (op_type != binary_op)
> > > >  vec_oprnd1 = NULL;
> > > > -  new_stmt = gimple_build_assign (vec_dest, code, vec_oprnd0,
> > > vec_oprnd1);
> > > > +  if (ch.is_tree_code ())
> > > > +new_stmt = gimple_build_assign (vec_dest, ch, vec_oprnd0,
> > > vec_oprnd1);
> > > > +  else
> > > > +new_stmt = gimple_build_call_internal (as_internal_fn
> > > > + ((combined_fn)
> > > ch),
> > > > +  2, vec_oprnd0, vec_oprnd1);
> > >
> > > Similarly here.  I guess the combined_fn/internal_fn path will also
> > > need to cope with null trailing operands, for consistency with the 
> > > tree_code
> > one.
> > >
> > 
> > Done.
> > 
> > > > @@ -4744,31 +4747,28 @@ vectorizable_conversion (vec_info *vinfo,
> > > >&& ! vec_stmt)
> > > >  return false;
> > > >
> > > > -  gassign *stmt = dyn_cast  (stmt_info->stmt);
> > > > -  if (!stmt)
> > > > +  gimple* stmt = stmt_info->stmt;
> > > > +  if (!(is_gimple_assign (stmt) || is_gimple_call (stmt)))
> > > >  return false;
> > > >
> > > > -  if (TREE_CODE (gimple_assign_lhs (stmt)) != SSA_NAME)
> > > > -return false;
> > > > +  if (is_gimple_assign (stmt))
> > > > +  {
> > > > +code_or_ifn = gimple_assign_rhs_code (stmt);  }  else
> > > > +code_or_ifn = gimple_call_combined_fn (stmt);
> > >
> > > It might be possible to use gimple_extract_op here (only recently added).
> > > This would also provide the number of operands directly, instead of
> > > needing ?op_type?.  It would also provide an array of operands.
> > >
> > 
> > Done.
> > 
> > > > -  code = gimple_assign_rhs_code (stmt);
> > > > -  if (!CONVERT_EXPR_CODE_P (code)
> > > > -  && code != FIX_TRUNC_EXPR
> > > > -  && code != FLOAT_EXPR
> > > > -  && code != WIDEN_PLUS_EXPR
> > > > -  && code != WIDEN_MINUS_EXPR
> > > > -  && code != WIDEN_MULT_EXPR
> > > > 

[committed] Fortran: Fix OpenMP clause name in error message

[Tobias Burnus]

This fix was part of the submitted patch + reviewed with minor comments
patch:

[PATCH, OpenMP 5.0] More implementation of the requires directive
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563393.html

but that never got revised and applied.

Committed the most obvious parts as obvious, as
r13-800-g8af266501795dd76d05faef498dbd3472a01b305

Tobias

PS: The non-obvious parts need to be a bit revised (collect follow-up
patches, properly filter out requirements not fulfilled from the
available-devices list → cf. glossary of the current, post-5.2 OpenMP
specification git repository) etc.
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 8af266501795dd76d05faef498dbd3472a01b305
Author: Tobias Burnus 
Date:   Fri May 27 13:12:45 2022 +0200

Fortran: Fix OpenMP clause name in error message

gcc/fortran/ChangeLog:

* openmp.cc (gfc_check_omp_requires): Fix clause name in error.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/requires-4.f90: Update dg-error.
* gfortran.dg/gomp/requires-8.f90: Update dg-error.

Co-authored-by: Chung-Lin Tang 
---
 gcc/fortran/openmp.cc | 2 +-
 gcc/testsuite/gfortran.dg/gomp/requires-4.f90 | 2 +-
 gcc/testsuite/gfortran.dg/gomp/requires-8.f90 | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 6172ec27687..efa62b64f2b 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -5272,7 +5272,7 @@ gfc_check_omp_requires (gfc_namespace *ns, int ref_omp_requires)
   if ((ref_omp_requires & OMP_REQ_REVERSE_OFFLOAD)
 	  && !(ns->omp_requires & OMP_REQ_REVERSE_OFFLOAD))
 	gfc_error ("Program unit at %L has OpenMP device constructs/routines "
-		   "but does not set !$OMP REQUIRES REVERSE_OFFSET but other "
+		   "but does not set !$OMP REQUIRES REVERSE_OFFLOAD but other "
 		   "program units do", &ns->proc_name->declared_at);
   if ((ref_omp_requires & OMP_REQ_UNIFIED_ADDRESS)
 	  && !(ns->omp_requires & OMP_REQ_UNIFIED_ADDRESS))
diff --git a/gcc/testsuite/gfortran.dg/gomp/requires-4.f90 b/gcc/testsuite/gfortran.dg/gomp/requires-4.f90
index b17aceb898b..c870a2840d3 100644
--- a/gcc/testsuite/gfortran.dg/gomp/requires-4.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/requires-4.f90
@@ -9,7 +9,7 @@ end module m
 subroutine foo
   !$omp target
   !$omp end target
-! { dg-error "OpenMP device constructs/routines but does not set !.OMP REQUIRES REVERSE_OFFSET but other program units do" "" { target *-*-* } 9 }
+! { dg-error "OpenMP device constructs/routines but does not set !.OMP REQUIRES REVERSE_OFFLOAD but other program units do" "" { target *-*-* } 9 }
 ! { dg-error "OpenMP device constructs/routines but does not set !.OMP REQUIRES UNIFIED_ADDRESS but other program units do" "" { target *-*-* } 9 }
 ! { dg-error "OpenMP device constructs/routines but does not set !.OMP REQUIRES UNIFIED_SHARED_MEMORY but other program units do" "" { target *-*-* } 9 }
 end
diff --git a/gcc/testsuite/gfortran.dg/gomp/requires-8.f90 b/gcc/testsuite/gfortran.dg/gomp/requires-8.f90
index eadfcaf8609..e84d609ad29 100644
--- a/gcc/testsuite/gfortran.dg/gomp/requires-8.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/requires-8.f90
@@ -13,7 +13,7 @@ contains
  end subroutine foo
 end module m
 
-subroutine bar  ! { dg-error "has OpenMP device constructs/routines but does not set !.OMP REQUIRES REVERSE_OFFSET but other program units do" }
+subroutine bar  ! { dg-error "has OpenMP device constructs/routines but does not set !.OMP REQUIRES REVERSE_OFFLOAD but other program units do" }
   !use m
   !$omp requires unified_shared_memory
   !$omp declare target

[PATCH] Avoid shift in get_ref_base_and_extent

[Richard Biener via Gcc-patches]

This avoids one instance of a shift from bytes to bits in
get_ref_base_and_extent by using TYPE_SIZE instead of TYPE_SIZE_UNIT.

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

* tree-dfa.cc (get_ref_base_and_extent): Avoid shift.
---
 gcc/tree-dfa.cc | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-dfa.cc b/gcc/tree-dfa.cc
index 21c82cedb9f..e75e3d605b3 100644
--- a/gcc/tree-dfa.cc
+++ b/gcc/tree-dfa.cc
@@ -453,8 +453,8 @@ get_ref_base_and_extent (tree exp, poly_int64_pod *poffset,
if (!next
|| TREE_CODE (stype) != RECORD_TYPE)
  {
-   tree fsize = DECL_SIZE_UNIT (field);
-   tree ssize = TYPE_SIZE_UNIT (stype);
+   tree fsize = DECL_SIZE (field);
+   tree ssize = TYPE_SIZE (stype);
if (fsize == NULL
|| !poly_int_tree_p (fsize)
|| ssize == NULL
@@ -465,7 +465,6 @@ get_ref_base_and_extent (tree exp, poly_int64_pod *poffset,
poly_offset_int tem
  = (wi::to_poly_offset (ssize)
 - wi::to_poly_offset (fsize));
-   tem <<= LOG2_BITS_PER_UNIT;
tem -= woffset;
maxsize += tem;
  }
-- 
2.35.3

[PING] libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option (was: Proposal to remove '--with-cuda-driver')

[Thomas Schwinge]

Hi!

Ping.


Grüße
 Thomas


On 2022-05-13T14:29:01+0200, I wrote:
> Hi!
>
> On 2022-04-29T15:48:03+0200, I wrote:
>> On 2022-04-06T11:57:57+0200, Tom de Vries  wrote:
>>> On 4/5/22 17:14, Thomas Schwinge wrote:
 Regarding [...]
>
 Now, consider doing a GCC/nvptx offloading build with
 '--with-cuda-driver' [...]
>
>>> Thanks for reminding me, I forgot about this configure option.
>>
>> OK, good.  ;-)
>
> (It also wasn't documented, by the way...)
>
>> [...] we seem to agree that '--with-cuda-driver' is not
>> very useful, and may be removed:
>>
 Already long ago Jakub put in changes to use '--without-cuda-driver' to
 "Allow building GCC with PTX offloading even without CUDA being installed
 (gcc and nvptx-tools patches)": "Especially for distributions it is
 undesirable to need to have proprietary CUDA libraries and headers
 installed when building GCC.", and I understand GNU/Linux distributions
 all use that.  That configuration uses the GCC-provided
 'libgomp/plugin/cuda/cuda.h', 'libgomp/plugin/cuda-lib.def' to manually
 define the CUDA Driver ABI to use, and then 'dlopen("libcuda.so.1")'.
 (Similar to what the libgomp GCN (and before: HSA) plugin is doing, for
 example.)  Quite likely that our group (at work) are the only ones to
 actually use '--with-cuda-driver'?
>>>
>>> Right, I see in my scripts that I don't use --with-cuda-driver, possibly
>>> because of years-ago running into issues when changing drivers forth and
>>> back.
>>>
 My proposal now is: we remove '--with-cuda-driver' (make its use a no-op,
 per standard GNU Autoconf behavior), and offer '--without-cuda-driver'
 only.  This shouldn't cause any user-visible change in behavior, so safe
 without a prior deprecation phase.
>>>
>>> I think the dlopen use-case is the most flexible, and I don't see any
>>> user benefit from using --with-cuda-driver, so I don't see a problem
>>> with removing --with-cuda-driver for the user.
>>
>> ACK, thanks.
>>
>>> I did wonder about keeping it available in some form, say rename to
>>> --maintainer-mode-with-cuda-driver.  This could be useful for debugging
>>> / comparison purposes.  But it would mean having to test it when making
>>> relevant changes, which is maintenance burden for a feature not visible
>>> to the user, so I guess that's not worth it.
>>>
>>> So, I'm fine with removing.
>>
>> Based on the point you made above, I realized that it may be beneficial
>> to "keep the underlying functionality available for the developers":
>> "if you develop CUDA API-level changes in the libgomp nvptx plugin, it's
>> likely to be easier to just use the full CUDA toolkit 'cuda.h' and
>> directly link against libcuda (so that you've got all symbols etc.
>> available), and only once you know what exactly you need, update GCC's
>> 'include/cuda/cuda.h' and 'libgomp/plugin/cuda-lib.def'".  (See the
>> thread "libgomp nvptx plugin: Split 'PLUGIN_NVPTX_DYNAMIC' into
>> 'PLUGIN_NVPTX_INCLUDE_SYSTEM_CUDA_H' and 'PLUGIN_NVPTX_LINK_LIBCUDA'".)
>>
>> Do we agree that it's OK to remove the user-visiable '--with-cuda-driver'
>> etc. options, and do not introduce any new
>> '--enable-maintainer-mode-with-cuda-driver' (or similar) option, and
>> instead let this functionality be available to developers only, via
>> manually editing 'libgomp/plugin/Makefrag.am'?
>>
>> Happy to submit an illustrative patch, if that helps.
>
> Well, given the preparational work that I've put in in the last days,
> attached now actually is the final patch: "libgomp nvptx plugin:
> Remove '--with-cuda-driver=[...]' etc. configuration option".  OK to
> push?
>
>
> Grüße
>  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 68f307775254e468b0aea3209e7e34528fa92bfc Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 12 May 2022 22:46:40 +0200
Subject: [PATCH] libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc.
 configuration option

That means, exposing to the user only the '--without-cuda-driver' behavior:
including the GCC-shipped 'include/cuda/cuda.h' (not system ), and
'dlopen'ing the CUDA Driver library (not linking it).

For development purposes, the libgomp nvptx plugin developer may still manually
override that, to get the previous '--with-cuda-driver' behavior.

	libgomp/
	* plugin/Makefrag.am: Evaluate 'if PLUGIN_NVPTX_DYNAMIC' to true.
	* plugin/configfrag.ac (--with-cuda-driver)
	(--with-cuda-driver-include, --with-cuda-driver-lib)
	(CUDA_DRIVER_INCLUDE, CUDA_DRIVER_LIB, PLUGIN_NVPTX_CPPFLAGS)
	(PLUGIN_NVPTX_LDFLAGS, PLUGIN_NVPTX_LIBS, PLUGIN_NVPTX_DYNAMIC):
	Remove.
	* testsuite/libgomp-test-support.exp.in (cuda_driver_include)
	(cuda_driver_lib): Remove.
	* testsuite/lib/libgomp.exp (libgomp_init): Don't consider these.
	* Makefi

[committed] openmp: Add support for enter clause on declare target

[Jakub Jelinek via Gcc-patches]

Hi!

OpenMP 5.1 and earlier had 2 different uses of to clause, one for target
update construct with one semantics, and one for declare target directive
with a different semantics.
Under the hood we were using OMP_CLAUSE_TO_DECLARE to represent the latter.
OpenMP 5.2 renamed the declare target clause to to enter, the old one is
kept as a deprecated alias.

As we are far from having full OpenMP 5.2 support, this patch adds support
for the enter clause (and renames OMP_CLAUSE_TO_DECLARE to OMP_CLAUSE_ENTER
with a flag to tell the spelling of the clause for better diagnostics),
but doesn't deprecate the to clause on declare target just yet (that
should be done as one of the last steps in 5.2 support).

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2022-05-27  Jakub Jelinek  

gcc/
* tree-core.h (enum omp_clause_code): Rename OMP_CLAUSE_TO_DECLARE
to OMP_CLAUSE_ENTER.
* tree.h (OMP_CLAUSE_ENTER_TO): Define.
* tree.cc (omp_clause_num_ops, omp_clause_code_name): Rename
OMP_CLAUSE_TO_DECLARE to OMP_CLAUSE_ENTER.
* tree-pretty-print.cc (dump_omp_clause): Handle OMP_CLAUSE_ENTER
instead of OMP_CLAUSE_TO_DECLARE, if OMP_CLAUSE_ENTER_TO, print
"to" instead of "enter".
* tree-nested.cc (convert_nonlocal_omp_clauses,
convert_local_omp_clauses): Handle OMP_CLAUSE_ENTER instead of
OMP_CLAUSE_TO_DECLARE.
gcc/c-family/
* c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_ENTER.
gcc/c/
* c-parser.cc (c_parser_omp_clause_name): Parse enter clause.
(c_parser_omp_all_clauses): For to clause on declare target, use
OMP_CLAUSE_ENTER clause with OMP_CLAUSE_ENTER_TO instead of
OMP_CLAUSE_TO_DECLARE clause.  Handle PRAGMA_OMP_CLAUSE_ENTER.
(OMP_DECLARE_TARGET_CLAUSE_MASK): Add enter clause.
(c_parser_omp_declare_target): Use OMP_CLAUSE_ENTER instead of
OMP_CLAUSE_TO_DECLARE.
* c-typeck.cc (c_finish_omp_clauses): Handle OMP_CLAUSE_ENTER instead
of OMP_CLAUSE_TO_DECLARE, to OMP_CLAUSE_ENTER_TO use "to" as clause
name in diagnostics instead of
omp_clause_code_name[OMP_CLAUSE_CODE (c)].
gcc/cp/
* parser.cc (cp_parser_omp_clause_name): Parse enter clause.
(cp_parser_omp_all_clauses): For to clause on declare target, use
OMP_CLAUSE_ENTER clause with OMP_CLAUSE_ENTER_TO instead of
OMP_CLAUSE_TO_DECLARE clause.  Handle PRAGMA_OMP_CLAUSE_ENTER.
(OMP_DECLARE_TARGET_CLAUSE_MASK): Add enter clause.
(cp_parser_omp_declare_target): Use OMP_CLAUSE_ENTER instead of
OMP_CLAUSE_TO_DECLARE.
* semantics.cc (finish_omp_clauses): Handle OMP_CLAUSE_ENTER instead
of OMP_CLAUSE_TO_DECLARE, to OMP_CLAUSE_ENTER_TO use "to" as clause
name in diagnostics instead of
omp_clause_code_name[OMP_CLAUSE_CODE (c)].
gcc/testsuite/
* c-c++-common/gomp/clauses-3.c: Add tests with enter clause instead
of to or modify some existing to clauses to enter.
* c-c++-common/gomp/declare-target-1.c: Likewise.
* c-c++-common/gomp/declare-target-2.c: Likewise.
* c-c++-common/gomp/declare-target-3.c: Likewise.
* g++.dg/gomp/attrs-9.C: Likewise.
* g++.dg/gomp/declare-target-1.C: Likewise.
libgomp/
* testsuite/libgomp.c-c++-common/target-40.c: Modify some existing to
clauses to enter.
* testsuite/libgomp.c/target-41.c: Likewise.

--- gcc/tree-core.h.jj  2022-05-27 11:29:15.787812586 +0200
+++ gcc/tree-core.h 2022-05-27 11:47:00.250820434 +0200
@@ -302,9 +302,9 @@ enum omp_clause_code {
   /* OpenMP clause: uniform (argument-list).  */
   OMP_CLAUSE_UNIFORM,
 
-  /* OpenMP clause: to (extended-list).
- Only when it appears in declare target.  */
-  OMP_CLAUSE_TO_DECLARE,
+  /* OpenMP clause: enter (extended-list).
+ to is a deprecated alias when it appears in declare target.  */
+  OMP_CLAUSE_ENTER,
 
   /* OpenMP clause: link (variable-list).  */
   OMP_CLAUSE_LINK,
--- gcc/tree.h.jj   2022-05-27 11:29:16.026810118 +0200
+++ gcc/tree.h  2022-05-27 11:47:00.246820475 +0200
@@ -1925,6 +1925,10 @@ class auto_suppress_location_wrappers
 #define OMP_CLAUSE_BIND_KIND(NODE) \
   (OMP_CLAUSE_SUBCODE_CHECK (NODE, 
OMP_CLAUSE_BIND)->omp_clause.subcode.bind_kind)
 
+/* True if ENTER clause is spelled as TO.  */
+#define OMP_CLAUSE_ENTER_TO(NODE) \
+  (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_ENTER)->base.public_flag)
+
 #define OMP_CLAUSE_TILE_LIST(NODE) \
   OMP_CLAUSE_OPERAND (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_TILE), 0)
 #define OMP_CLAUSE_TILE_ITERVAR(NODE) \
--- gcc/tree.cc.jj  2022-05-27 11:29:15.954810861 +0200
+++ gcc/tree.cc 2022-05-27 11:47:00.238820558 +0200
@@ -280,7 +280,7 @@ unsigned const char omp_clause_num_ops[]
   1, /* OMP_CLAUSE_DEPEND  */
   1, /* OMP_CLAUSE_NONTEMPORAL  */
   1, /* OMP_CLAUSE_UNIFORM  */
-  1, /* OMP_CLAUSE_TO_DECLARE  */
+  1, /* OMP_CLAUSE_ENTER 

Re: [PATCH] ipa: Check cst type when propagating controled uses info (PR 105639)

[Martin Jambor]

Hi,

On Fri, May 27 2022, Richard Biener wrote:
> On Thu, May 26, 2022 at 4:47 PM Martin Jambor  wrote:
>>
>> Hi,
>>
>> PR 105639 shows that code with type-mismatches can trigger an assert
>> after runnning into a branch that was inteded only for references to
>> variables - as opposed to references to functions.  Fixed by moving
>> the condition from the assert to the guarding if statement.
>>
>> Bootstrapped and tested on x86_64.  OK for trunk and then gcc 12?
>
> OK.  There's the same assert below - I guess that doesn't need the same
> treatment?

Thanks.  The assert below also allows the case when cst is an ADDR_EXPR of
a function.  And the whole reference-counting is initiated only for
these two cases.  So in all other cases the condition

  rdesc->refcount != IPA_UNDESCRIBED_USE

will be false.

Martin

>>
>>
>> gcc/ChangeLog:
>>
>> 2022-05-25  Martin Jambor  
>>
>> PR ipa/105639
>> * ipa-prop.cc (propagate_controlled_uses): Check type of the
>> constant before adding a LOAD reference.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2022-05-25  Martin Jambor  
>>
>> PR ipa/105639
>> * gcc.dg/ipa/pr105639.c: New test.

Re: [PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

[Jan Beulich via Gcc-patches]

On 27.05.2022 10:57, Uros Bizjak wrote:
> On Fri, May 27, 2022 at 10:05 AM Jan Beulich  wrote:
>>
>> It's pretty clear that the operand numbers in the MEM_P() checks are
>> off by one, perhaps due to a copy-and-paste oversight (unlike in most
>> other places here we're dealing with two outputs).
>> ---
>> What I don't understand is why operand 2 is "nonimmediate_operand", not
>> "register_operand" (which afaict would eliminate the need for these
>> MEM_P() checks). This would then also extend to e.g. the subsequent
>> umul3_1 and mul3_1 (and apparently quite a few
>> more).
> 
> Because they are commutative (due to % operand modifier) and reload
> can put memory operand into each operand.
> 
> Patch is OK with the appropriate ChangeLog entry.

Thanks, and yes, I did notice I failed to add a ChangeLog entry right
after sending (being a result of such no longer be required in
binutils, which I work more frequently with), sorry. This is what I
did add already:

gcc/
2022-05-XX  Jan Beulich  

* config/i386/i386.md (bmi2_umul3_1): Correct MEM_P()
arguments.

Jan

Re: [PATCH] fold-const: Fix up -fsanitize=null in C++ [PR105729]

[Richard Biener via Gcc-patches]

On Fri, 27 May 2022, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase triggers a false positive UBSan binding a reference
> to null diagnostics.
> In the FE we instrument conversions from pointer to reference type
> to diagnose at runtime if the operand of such a conversion is 0.
> The problem is that a GENERIC folding folds
> ((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) 
> range_check (x)
> conversion to const struct Bar & by converting to that the first
> operand of the POINTER_PLUS_EXPR.  But that changes when the -fsanitize=null
> binding to reference runtime check occurs.  Without the optimization,
> it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check
> call throws, that means it never triggers in the testcase.
> With the optimization, it checks whether this->data is NULL and it is.
> 
> The following patch avoids that optimization during GENERIC folding when
> -fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to
> REFERENCE_TYPE.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2022-05-27  Jakub Jelinek  
> 
>   PR sanitizer/105729
>   * fold-const.cc (fold_unary_loc): Don't optimize (X &) ((Y *) z + w)
>   to (X &) z + w if -fsanitize=null during GENERIC folding.
> 
>   * g++.dg/ubsan/pr105729.C: New test.
> 
> --- gcc/fold-const.cc.jj  2022-05-13 09:34:23.967147706 +0200
> +++ gcc/fold-const.cc 2022-05-26 17:12:50.145526094 +0200
> @@ -9516,6 +9516,16 @@ fold_unary_loc (location_t loc, enum tre
> > min_align_of_type (TREE_TYPE (TREE_TYPE (arg00)
>   return NULL_TREE;
>  
> +   /* Similarly, avoid this optimization in GENERIC for -fsanitize=null
> +  when type is a reference type and arg00's type is not,
> +  because arg00 could be validly nullptr and if arg01 doesn't return,
> +  we don't want false positive binding of reference to nullptr.  */
> +   if (TREE_CODE (type) == REFERENCE_TYPE
> +   && !in_gimple_form
> +   && sanitize_flags_p (SANITIZE_NULL)
> +   && TREE_CODE (TREE_TYPE (arg00)) != REFERENCE_TYPE)
> + return NULL_TREE;
> +
> arg00 = fold_convert_loc (loc, type, arg00);
> return fold_build_pointer_plus_loc (loc, arg00, arg01);
>   }
> --- gcc/testsuite/g++.dg/ubsan/pr105729.C.jj  2022-05-26 19:54:58.725009300 
> +0200
> +++ gcc/testsuite/g++.dg/ubsan/pr105729.C 2022-05-26 19:56:50.785848337 
> +0200
> @@ -0,0 +1,29 @@
> +// PR sanitizer/105729
> +// { dg-do run }
> +// { dg-options "-fsanitize=null -fno-sanitize-recover=null" }
> +
> +int
> +foo (int x)
> +{
> +  throw 0;
> +}
> +
> +struct S {};
> +struct T {
> +  S *data;
> +  T () : data (0) {}
> +  const S &bar (int x) const { return data[foo (x)]; }
> +};
> +
> +int
> +main ()
> +{
> +  T t;
> +  try
> +{
> +  t.bar (-1);
> +}
> +  catch (...)
> +{
> +}
> +}
> 
>   Jakub
> 
> 

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

Re: [PATCH] Add a bit dislike for separate mem alternative when op is REG_P.

[Alexander Monakov via Gcc-patches]

On Wed, 25 May 2022, liuhongt via Gcc-patches wrote:

> Rigt now, mem_cost for separate mem alternative is 1 * frequency which
> is pretty small and caused the unnecessary SSE spill in the PR, I've tried
> to rework backend cost model, but RA still not happy with that(regress
> somewhere else). I think the root cause of this is cost for separate 'm'
> alternative cost is too small, especially considering that the mov cost
> of gpr are 2(default for REGISTER_MOVE_COST). So this patch increase mem_cost
> to 2*frequency, also increase 1 for reg_class cost when m alternative.

In the PR, the spill happens in the initial basic block of the function, i.e.
the one with the highest frequency.

Also as noted in the PR, swapping the 'unlikely' branch to 'likely' avoids
the spill, even though it does not affect the frequency of the initial basic
block, and makes the block with the use more rarely executed.

Do you have a root cause analysis that explains the above?

Alexander

Re: [gcc r12-6398] [Ada] Reduce runtime dependencies on stage1

[Thomas Schwinge]

Hi!

(Before the GCC 12 release) I had reported that commit
r12-6398-ga6eae6a9bbf83ada3aab7f5a2a74e7024889d237
"[Ada] Reduce runtime dependencies on stage1" has broken GCC/Ada build
with GCC 4.8.  That's unfortunate, as I understand that GCC 4.8 is
generally the prerequisite compiler for GCC.  (..., and I like to do
certain build using that old version, to make sure that this still
works.)  (The issue later also got repoted by Bernd Edlinger in
 "Ada-Bootstrap fails with gcc-4.8.4".)

I thus had suggested a patch to
'Revert parts of "[Ada] Reduce runtime dependencies on stage1"', but:

On 2022-01-18T10:46:48+, Arnaud Charlet via Gcc-patches 
 wrote:
>> Unfortunately it's not OK, these are the most annoying/delicate 
>> dependencies, so
>> we'd rather not reintroduce them. I'll instead update prerequisites to
>> document that GCC 5.1 or later is required to build GNAT.
>
> Now pushed on master:
>
> Update prerequisites for GNAT
>
> * doc/install.texi: Update prerequisites for GNAT
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 54ad7c7..96b4dfc 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -263,7 +263,7 @@ name of the package depends on your distro) or you must 
> build GCC as a
>  @item @anchor{GNAT-prerequisite}GNAT
>
>  In order to build GNAT, the Ada compiler, you need a working GNAT
> -compiler (GCC version 4.7 or later).
> +compiler (GCC version 5.1 or later).
>
>  This includes GNAT tools such as @command{gnatmake} and
>  @command{gnatlink}, since the Ada front end is written in Ada and

I've now tested that, but find that it doesn't work:

[...]
gcc -c -g  -gnatpg -gnatwns -gnata -W -Wall -I- -I. -Iada/generated -Iada 
-I[...]/source-gcc/gcc/ada [...]/source-gcc/gcc/ada/contracts.adb -o 
ada/contracts.o
+===GNAT BUG DETECTED==+
| 5.1.0 (x86_64-unknown-linux-gnu) Assert_Failure sinfo.adb:616|
| Error detected at contracts.adb:2231:22  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

[...]/source-gcc/gcc/ada/contracts.adb
[...]/source-gcc/gcc/ada/contracts.ads
[...]/source-gcc/gcc/ada/types.ads
[...]/source-gcc/gcc/ada/aspects.ads
[...]/source-gcc/gcc/ada/namet.ads
[...]/source-gcc/gcc/ada/alloc.ads
[...]/source-gcc/gcc/ada/hostparm.ads
[...]/source-gcc/gcc/ada/table.ads
ada/snames.ads
[...]/source-gcc/gcc/ada/atree.ads
[...]/source-gcc/gcc/ada/sinfo.ads
[...]/source-gcc/gcc/ada/uintp.ads
[...]/source-gcc/gcc/ada/urealp.ads
ada/sinfo-nodes.ads
ada/seinfo.ads
[...]/source-gcc/gcc/ada/output.ads
[...]/source-gcc/gcc/ada/einfo.ads
[...]/source-gcc/gcc/ada/stand.ads
ada/einfo-entities.ads
[...]/source-gcc/gcc/ada/einfo-utils.ads
[...]/source-gcc/gcc/ada/elists.ads
[...]/source-gcc/gcc/ada/errout.ads
[...]/source-gcc/gcc/ada/err_vars.ads
[...]/source-gcc/gcc/ada/erroutc.ads
[...]/source-gcc/gcc/ada/exp_prag.ads
[...]/source-gcc/gcc/ada/exp_tss.ads
[...]/source-gcc/gcc/ada/exp_util.ads
[...]/source-gcc/gcc/ada/rtsfind.ads
[...]/source-gcc/gcc/ada/freeze.ads
[...]/source-gcc/gcc/ada/lib.ads
ada/gnat.ads
[...]/source-gcc/gcc/ada/nlists.ads
ada/nmake.ads
[...]/source-gcc/gcc/ada/opt.ads
[...]/source-gcc/gcc/ada/sem.ads
[...]/source-gcc/gcc/ada/sem_aux.ads
[...]/source-gcc/gcc/ada/sem_ch6.ads
[...]/source-gcc/gcc/ada/sem_ch8.ads
[...]/source-gcc/gcc/ada/sem_ch12.ads
[...]/source-gcc/gcc/ada/inline.ads
[...]/source-gcc/gcc/ada/warnsw.ads
[...]/source-gcc/gcc/ada/sem_ch13.ads
[...]/source-gcc/gcc/ada/sem_disp.ads
[...]/source-gcc/gcc/ada/sem_prag.ads
[...]/source-gcc/gcc/ada/sem_res.ads
[...]/source-gcc/gcc/ada/sem_type.ads
[...]/source-gcc/gcc/ada/sem_util.ads
[...]/source-gcc/gcc/ada/sinfo-utils.ads
[...]/source-gcc/gcc/ada/sinput.ads
[...]/source-gcc/gcc/ada/casing.ads
[...]/source-gcc/gcc/ada/stringt.ads
[...]/source-gcc/gcc/ada/tbuild.ads

compilation abandoned
make[3]: *** [ada/contracts.o] Error 1
make[3]: Target `all' not remade because of errors.
make[3]: Leaving directory `[...]/build-gcc/g

Re: [PATCH v3 4/5] xtensa: Add setmemsi insn pattern

[Takayuki 'January June' Suwa via Gcc-patches]

On 2022/05/27 12:00, Takayuki 'January June' Suwa via Gcc-patches wrote:

On 2022/05/27 1:57, Max Filippov wrote:

is that something that can be addressed in this patch?


seems hard to resolve, because the RTL-generation pass passes only 68 
bytes in that case:


the culprit is here, but i don't know whether it is known regression or not.

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 7197996cec7..be100dd9946 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -6043,13 +6043,19 @@ store_expr (tree exp, rtx target, int call_param_p,
   if (!can_store_by_pieces (str_copy_len, string_cst_read_str,
(void *) str, MEM_ALIGN (target), false))
goto normal_expr;
-
-  dest_mem = store_by_pieces (target, str_copy_len, 
string_cst_read_str,

- (void *) str, MEM_ALIGN (target), false,
- RETURN_END);
-  clear_storage (adjust_address_1 (dest_mem, BLKmode, 0, 1, 1, 0,
-  exp_len - str_copy_len),
-GEN_INT (exp_len - str_copy_len), BLOCK_OP_NORMAL);
+  if (TREE_STRING_LENGTH (str) == 1 && *TREE_STRING_POINTER (str) == 0)
+   clear_storage (adjust_address_1 (target, BLKmode, 0, 1, 1, 0,
+exp_len),
+  GEN_INT (exp_len), BLOCK_OP_NORMAL);
+  else
+   {
+ dest_mem = store_by_pieces (target, str_copy_len, string_cst_read_str,
+ (void *) str, MEM_ALIGN (target), false,
+ RETURN_END);
+ clear_storage (adjust_address_1 (dest_mem, BLKmode, 0, 1, 1, 0,
+  exp_len - str_copy_len),
+GEN_INT (exp_len - str_copy_len), BLOCK_OP_NORMAL);
+   }
   return NULL_RTX;
 }
   else

Re: [PATCH] x86: {,v}psadbw have commutative source operands

[Uros Bizjak via Gcc-patches]

On Fri, May 27, 2022 at 10:13 AM Jan Beulich  wrote:
>
> Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the
> "absolute difference" aspect of the insns makes their source operands
> commutative.

You will need to expand via ix86_fixup_binary_operands_no_copy, use
register_mmxmem_operand on both input operands and use
ix86_binary_operator insn constraint. Please see many examples w/
commutative operands throughout .md files.

Uros.

> gcc/
> 2022-05-XX  Jan Beulich  
>
> * config/i386/mmx.md (mmx_psadbw): Mark as commutative.
> * config/i386/sse.md (_psadbw): Likewise.
>
> --- a/gcc/config/i386/mmx.md
> +++ b/gcc/config/i386/mmx.md
> @@ -4407,7 +4407,7 @@
>
>  (define_insn "mmx_psadbw"
>[(set (match_operand:V1DI 0 "register_operand" "=y,x,Yw")
> -(unspec:V1DI [(match_operand:V8QI 1 "register_operand" "0,0,Yw")
> +(unspec:V1DI [(match_operand:V8QI 1 "register_operand" "%0,0,Yw")
>   (match_operand:V8QI 2 "register_mmxmem_operand" 
> "ym,x,Yw")]
>  UNSPEC_PSADBW))]
>"(TARGET_MMX || TARGET_MMX_WITH_SSE)
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -19983,7 +19983,7 @@
>  (define_insn "_psadbw"
>[(set (match_operand:VI8_AVX2_AVX512BW 0 "register_operand" "=x,YW")
> (unspec:VI8_AVX2_AVX512BW
> - [(match_operand: 1 "register_operand" "0,YW")
> + [(match_operand: 1 "register_operand" "%0,YW")
>(match_operand: 2 "vector_operand" "xBm,YWm")]
>   UNSPEC_PSADBW))]
>"TARGET_SSE2"
>

Re: [PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

[Uros Bizjak via Gcc-patches]

On Fri, May 27, 2022 at 10:05 AM Jan Beulich  wrote:
>
> It's pretty clear that the operand numbers in the MEM_P() checks are
> off by one, perhaps due to a copy-and-paste oversight (unlike in most
> other places here we're dealing with two outputs).
> ---
> What I don't understand is why operand 2 is "nonimmediate_operand", not
> "register_operand" (which afaict would eliminate the need for these
> MEM_P() checks). This would then also extend to e.g. the subsequent
> umul3_1 and mul3_1 (and apparently quite a few
> more).

Because they are commutative (due to % operand modifier) and reload
can put memory operand into each operand.

Patch is OK with the appropriate ChangeLog entry.

Thanks,
Uros.
>
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -8465,7 +8465,7 @@
> (zero_extend: (match_dup 3)))
> (match_operand:QI 4 "const_int_operand" "n"]
>"TARGET_BMI2 && INTVAL (operands[4]) ==  * BITS_PER_UNIT
> -   && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
> +   && !(MEM_P (operands[2]) && MEM_P (operands[3]))"
>"mulx\t{%3, %0, %1|%1, %0, %3}"
>[(set_attr "type" "imulx")
> (set_attr "prefix" "vex")
>

[PATCH] fold-const: Fix up -fsanitize=null in C++ [PR105729]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase triggers a false positive UBSan binding a reference
to null diagnostics.
In the FE we instrument conversions from pointer to reference type
to diagnose at runtime if the operand of such a conversion is 0.
The problem is that a GENERIC folding folds
((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) 
range_check (x)
conversion to const struct Bar & by converting to that the first
operand of the POINTER_PLUS_EXPR.  But that changes when the -fsanitize=null
binding to reference runtime check occurs.  Without the optimization,
it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check
call throws, that means it never triggers in the testcase.
With the optimization, it checks whether this->data is NULL and it is.

The following patch avoids that optimization during GENERIC folding when
-fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to
REFERENCE_TYPE.

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

2022-05-27  Jakub Jelinek  

PR sanitizer/105729
* fold-const.cc (fold_unary_loc): Don't optimize (X &) ((Y *) z + w)
to (X &) z + w if -fsanitize=null during GENERIC folding.

* g++.dg/ubsan/pr105729.C: New test.

--- gcc/fold-const.cc.jj2022-05-13 09:34:23.967147706 +0200
+++ gcc/fold-const.cc   2022-05-26 17:12:50.145526094 +0200
@@ -9516,6 +9516,16 @@ fold_unary_loc (location_t loc, enum tre
  > min_align_of_type (TREE_TYPE (TREE_TYPE (arg00)
return NULL_TREE;
 
+ /* Similarly, avoid this optimization in GENERIC for -fsanitize=null
+when type is a reference type and arg00's type is not,
+because arg00 could be validly nullptr and if arg01 doesn't return,
+we don't want false positive binding of reference to nullptr.  */
+ if (TREE_CODE (type) == REFERENCE_TYPE
+ && !in_gimple_form
+ && sanitize_flags_p (SANITIZE_NULL)
+ && TREE_CODE (TREE_TYPE (arg00)) != REFERENCE_TYPE)
+   return NULL_TREE;
+
  arg00 = fold_convert_loc (loc, type, arg00);
  return fold_build_pointer_plus_loc (loc, arg00, arg01);
}
--- gcc/testsuite/g++.dg/ubsan/pr105729.C.jj2022-05-26 19:54:58.725009300 
+0200
+++ gcc/testsuite/g++.dg/ubsan/pr105729.C   2022-05-26 19:56:50.785848337 
+0200
@@ -0,0 +1,29 @@
+// PR sanitizer/105729
+// { dg-do run }
+// { dg-options "-fsanitize=null -fno-sanitize-recover=null" }
+
+int
+foo (int x)
+{
+  throw 0;
+}
+
+struct S {};
+struct T {
+  S *data;
+  T () : data (0) {}
+  const S &bar (int x) const { return data[foo (x)]; }
+};
+
+int
+main ()
+{
+  T t;
+  try
+{
+  t.bar (-1);
+}
+  catch (...)
+{
+}
+}

Jakub

[PATCH] libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]

[Jakub Jelinek via Gcc-patches]

Hi!

The first part of the following testcase (m1-m3 macros and its use)
regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows,
the problem isn't new, we can emit a CPP_PADDING token to avoid it from
being adjacent to whatever comes after the __VA_OPT__ (in this case there
is nothing afterwards, true).

In most cases these CPP_PADDING tokens don't matter, all other
callers of cpp_get_token_with_location either ignore CPP_PADDING tokens
completely (e.g. c_lex_with_flags) or they just remember them and
take them into account when printing stuff whether there should be
added whitespace or not (scan_translation_unit + token_streamer::stream).
So, I think we should just ignore CPP_PADDING tokens the same way in
_cpp_parse_expr.

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

2022-05-27  Jakub Jelinek  

PR preprocessor/105732
* expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another
token.

* c-c++-common/cpp/va-opt-10.c: New test.

--- libcpp/expr.cc.jj   2022-01-18 11:59:00.258972399 +0100
+++ libcpp/expr.cc  2022-05-26 15:39:54.348780446 +0200
@@ -1366,6 +1366,10 @@ _cpp_parse_expr (cpp_reader *pfile, bool
op.op = CPP_UMINUS;
  break;
 
+   case CPP_PADDING:
+ lex_count--;
+ continue;
+
default:
  if ((int) op.op <= (int) CPP_EQ || (int) op.op >= (int) CPP_PLUS_EQ)
SYNTAX_ERROR2_AT (op.loc,
--- gcc/testsuite/c-c++-common/cpp/va-opt-10.c.jj   2022-05-26 
15:54:40.279766330 +0200
+++ gcc/testsuite/c-c++-common/cpp/va-opt-10.c  2022-05-26 15:54:24.028928687 
+0200
@@ -0,0 +1,18 @@
+/* PR preprocessor/105732 */
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99" { target c } } */
+/* { dg-options "-std=c++20" { target c++ } } */
+
+#define m1(p1, p2, p3) p3
+#define m2(p1, ...) 1##__VA_OPT__(foo)
+#define m3(...) m1(1, 2, m2)
+#define m4(p1, ...) 1 __VA_OPT__()
+#define m5(...) m1(1, 2, m4)
+#if m3(,)(,)
+#else
+#error
+#endif
+#if m5(,)(,)
+#else
+#error
+#endif

Jakub

[PATCH] x86: {,v}psadbw have commutative source operands

[Jan Beulich via Gcc-patches]

Like noticed for gas as well (binutils-gdb commit c8cad9d389b7), the
"absolute difference" aspect of the insns makes their source operands
commutative.

gcc/
2022-05-XX  Jan Beulich  

* config/i386/mmx.md (mmx_psadbw): Mark as commutative.
* config/i386/sse.md (_psadbw): Likewise.

--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -4407,7 +4407,7 @@
 
 (define_insn "mmx_psadbw"
   [(set (match_operand:V1DI 0 "register_operand" "=y,x,Yw")
-(unspec:V1DI [(match_operand:V8QI 1 "register_operand" "0,0,Yw")
+(unspec:V1DI [(match_operand:V8QI 1 "register_operand" "%0,0,Yw")
  (match_operand:V8QI 2 "register_mmxmem_operand" 
"ym,x,Yw")]
 UNSPEC_PSADBW))]
   "(TARGET_MMX || TARGET_MMX_WITH_SSE)
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -19983,7 +19983,7 @@
 (define_insn "_psadbw"
   [(set (match_operand:VI8_AVX2_AVX512BW 0 "register_operand" "=x,YW")
(unspec:VI8_AVX2_AVX512BW
- [(match_operand: 1 "register_operand" "0,YW")
+ [(match_operand: 1 "register_operand" "%0,YW")
   (match_operand: 2 "vector_operand" "xBm,YWm")]
  UNSPEC_PSADBW))]
   "TARGET_SSE2"

GCC 9 branch is now closed

[Richard Biener via Gcc-patches]

After the GCC 9.5 release the GCC 9 branch is now closed and the
hooks should reject any further pushes to it.

Thanks,
Richard.

[PATCH] x86: correct bmi2_umul3_1's MEM_P() uses

[Jan Beulich via Gcc-patches]

It's pretty clear that the operand numbers in the MEM_P() checks are
off by one, perhaps due to a copy-and-paste oversight (unlike in most
other places here we're dealing with two outputs).
---
What I don't understand is why operand 2 is "nonimmediate_operand", not
"register_operand" (which afaict would eliminate the need for these
MEM_P() checks). This would then also extend to e.g. the subsequent
umul3_1 and mul3_1 (and apparently quite a few
more).

--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -8465,7 +8465,7 @@
(zero_extend: (match_dup 3)))
(match_operand:QI 4 "const_int_operand" "n"]
   "TARGET_BMI2 && INTVAL (operands[4]) ==  * BITS_PER_UNIT
-   && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
+   && !(MEM_P (operands[2]) && MEM_P (operands[3]))"
   "mulx\t{%3, %0, %1|%1, %0, %3}"
   [(set_attr "type" "imulx")
(set_attr "prefix" "vex")

Re: [Patch] libgomp.texi: Add more to-be-implemented OpenMP 5.2 features / [wwwdocs] gcc-13/changes.html - Update OpenMP / projects/gomp - add more to-do items

[Jakub Jelinek via Gcc-patches]

On Fri, May 27, 2022 at 09:41:22AM +0200, Tobias Burnus wrote:
> On 25.05.22 17:55, Tobias Burnus wrote:
> > I had a look at the OpenMP 5.2 changes and found some more,
> > which I think should be listed. Some were rather hidden, two
> > were only documented in the deprecate part.
> 
> Fixes: Remove the last two items – they were already in the list (ups).
> 
> libgomp/libgomp.texi – forgot to update the default-map clause wording;
> now again in sync with the html version.

Ok.

Jakub

libatomic: drop redundant all-multi command

[Jan Beulich via Gcc-patches]

./multilib.am already specifies this same command, and make warns about
the earlier one being ignored when seeing the later one. All that needs
retaining to still satisfy the preceding comment is the extra
dependency.

libatomic/
2022-05-XX  Jan Beulich  

* Makefile.am (all-multi): Drop commands.
* Makefile.in: Update accordingly.

--- a/libatomic/Makefile.am
+++ b/libatomic/Makefile.am
@@ -147,12 +147,11 @@
 libatomic_convenience_la_SOURCES = $(libatomic_la_SOURCES)
 libatomic_convenience_la_LIBADD = $(libatomic_la_LIBADD)
 
-# Override the automake generated all-multi rule to guarantee that all-multi
+# Amend the automake generated all-multi rule to guarantee that all-multi
 # is not run in parallel with the %_.lo rules which generate $(DEPDIR)/*.Ppo
 # makefile fragments to avoid broken *.Ppo getting included into the Makefile
 # when it is reloaded during the build of all-multi.
 all-multi: $(libatomic_la_LIBADD)
-   $(MULTIDO) $(AM_MAKEFLAGS) DO=all multi-do # $(MAKE)
 
 # target overrides
 -include $(tmake_file)
--- a/libatomic/Makefile.in
+++ b/libatomic/Makefile.in
@@ -858,12 +858,11 @@
 %_.lo: Makefile
$(LTCOMPILE) $(M_DEPS) $(M_SIZE) $(M_IFUNC) -c -o $@ $(M_SRC)
 
-# Override the automake generated all-multi rule to guarantee that all-multi
+# Amend the automake generated all-multi rule to guarantee that all-multi
 # is not run in parallel with the %_.lo rules which generate $(DEPDIR)/*.Ppo
 # makefile fragments to avoid broken *.Ppo getting included into the Makefile
 # when it is reloaded during the build of all-multi.
 all-multi: $(libatomic_la_LIBADD)
-   $(MULTIDO) $(AM_MAKEFLAGS) DO=all multi-do # $(MAKE)
 
 # target overrides
 -include $(tmake_file)

Re: [Patch] libgomp.texi: Add more to-be-implemented OpenMP 5.2 features / [wwwdocs] gcc-13/changes.html - Update OpenMP / projects/gomp - add more to-do items

[Tobias Burnus]

On 25.05.22 17:55, Tobias Burnus wrote:

I had a look at the OpenMP 5.2 changes and found some more,
which I think should be listed. Some were rather hidden, two
were only documented in the deprecate part.


Fixes: Remove the last two items – they were already in the list (ups).

libgomp/libgomp.texi – forgot to update the default-map clause wording;
now again in sync with the html version.


OK? Comments?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
libgomp.texi: Add more to-be-implemented OpenMP 5.2 features

libgomp/
	* libgomp.texi (Other new OpenMP 5.1 features): Add
	'begin declare target'.
	(Other new OpenMP 5.2 features): New.

diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi
index 56724687fb4..56aab4494ad 100644
--- a/libgomp/libgomp.texi
+++ b/libgomp/libgomp.texi
@@ -343,6 +343,7 @@ The OpenMP 4.5 specification is fully supported.
 @item Support of structured block sequences in C/C++ @tab Y @tab
 @item @code{unconstrained} and @code{reproducible} modifiers on @code{order}
   clause @tab Y @tab
+@item Support @code{begin/end declare target} syntax in C/C++ @tab N @tab
 @end multitable
 
 
@@ -387,7 +388,8 @@ The OpenMP 4.5 specification is fully supported.
 @item @code{allocate} and @code{firstprivate} clauses on @code{scope}
   @tab N @tab
 @item @code{ompt_callback_work} @tab N @tab
-@item Extended map-type handling of @code{target enter/exit data} @tab N @tab
+@item Default map-type for @code{map} clause in @code{target enter/exit data}
+  @tab N @tab
 @item New @code{doacross} clause as alias for @code{depend} with
   @code{source}/@code{sink} modifier @tab N @tab
 @item Deprecation of @code{depend} with @code{source}/@code{sink} modifier
@@ -395,6 +397,19 @@ The OpenMP 4.5 specification is fully supported.
 @item @code{omp_cur_iteration} keyword @tab N @tab
 @end multitable
 
+@unnumberedsubsec Other new OpenMP 5.2 features
+
+@multitable @columnfractions .60 .10 .25
+@headitem Description @tab Status @tab Comments
+@item For Fortran, optional comma between directive and clause @tab N @tab
+@item Conforming device numbers and @code{omp_initial_device} and
+  @code{omp_invalid_device} enum/PARAMETER @tab N @tab
+@item Initial value of @emph{default-device-var} ICV with
+  @code{OMP_TARGET_OFFLOAD=mandatory} @tab N @tab
+@item @emph{interop_types} in any position of the modifier list for the @code{init} clause
+  of the @code{interop} construct @tab N @tab
+@end multitable
+
 
 @c -
 @c OpenMP Runtime Library Routines
gcc-13/changes.html - Update OpenMP / projects/gomp - add more to-do items

* gcc-13/changes.html (OpenMP): Add 'nowait' with 'taskwait'.
* projects/gomp/index.html: Add one 5.1 and several 5.2 additional
  to-be-implemented features.

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index c2610412..a262087f 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -40,7 +40,8 @@ a work-in-progress.
   
 The following OpenMP 5.1 features have been added: the
 omp_all_memory reserved locator, the inoutset
-modifier to the depend clause and the
+modifier to the depend clause, the nowait
+clause for the taskwait directive and the
 omp_target_is_accessible, omp_target_memcpy_async,
 omp_target_memcpy_rect_async and
 omp_get_mapped_ptr API routines. Fortran now supports
diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html
index 68531a57..8b6dc84f 100644
--- a/htdocs/projects/gomp/index.html
+++ b/htdocs/projects/gomp/index.html
@@ -630,6 +630,11 @@ than listed, depending on resolved corner cases and optimizations.
 GCC 13
 
   
+  
+nowait clause in taskwait directive
+GCC 13
+
+  
   
 target_device trait in OpenMP Context
 No
@@ -690,11 +695,6 @@ than listed, depending on resolved corner cases and optimizations.
 No
 
   
-  
-nowait clause in taskwait directive
-No
-
-  
   
 present argument to defaultmap clause
 No
@@ -725,6 +725,12 @@ than listed, depending on resolved corner cases and optimizations.
 No
 
   
+  
+Support begin/end declare target syntax in C/C++
+No
+
+  
+  
 
 
 
@@ -875,6 +881,26 @@ than listed, depending on resolved corner cases and optimizations.
 No
 
   
+  
+For Fortran, optional comma between directive and clause
+No
+
+  
+  
+Conforming device numbers and omp_initial_device and omp_invalid_device enum/PARAMETER
+No
+
+  
+  
+interop_types in any position of the modifier list for the init clause of the interop construct
+No
+
+  
+  
+Initial value of default-device-var ICV with OMP_TARGET_OFFLOAD=mandatory
+ 

Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

[Richard Biener via Gcc-patches]

On Wed, May 25, 2022 at 9:50 PM Gaius Mulley  wrote:
>
> Richard Biener  writes:
>
> > So is there a reason to have the 'scaffold' separate from the object
> > of hello.mod?
>
> Perhaps the major advantage is flexibility?  But no we can by default
> produce the scaffold within the object of hello.mod (and give users the
> ability to disable scaffold generation should they wish to implement
> their own).
>
> > Is there more than a 1:1 relation between a .mod and the 'scaffold'?
>
> yes there is a 1:1 relation between a .mod and the scaffold.  Although
> the caveat is that the compiler would need to parse every .def and .mod
> imports from the application universe.  Not a major change as gm2 has
> the ability to do whole program (application) compiling, so a minor set
> of changes to ensure that upon compiling the program module that it also
> parses every .def/.mod.
>
> > Why are multiple tools involved here - can the m2 frontend not parse
> > imports, reorder runtime modules and generate the 'scaffold' as
> > GENERIC IL as part of the translation unit of the .mod file?
> > Indirection through emitting C++ source code makes the process a bit
> > awkward IMHO.
>
> indeed the m2 front end can parse imports, reorder and generate the
> scaffold.
>
> > Unfortunately I have no m2 installation around to look at how complex
> > the 'scaffold' is.
>
> the scaffold is really simple for example here it is for hello.mod:
>
>   $ gm2 -c -g -fmakelist hello.mod
>   $ cat hello.lst
> Storage
> SYSTEM
> M2RTS
> RTExceptions
> # libc   11 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/libc.def FOR 'C'
> # SYSTEM   11 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SYSTEM.mod
> # StrIO   11 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StrIO.mod
> # StrLib   10 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StrLib.mod
> # ASCII   10 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/ASCII.mod
> # NumberIO   10 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/NumberIO.mod
> # Indexing   10 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Indexing.mod
> # errno9 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/errno.def
> # termios9 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/termios.def
> # FIO9 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/FIO.mod
> # IO8 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/IO.mod
> # StdIO7 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/StdIO.mod
> # Debug6 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Debug.mod
> # SysStorage5 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SysStorage.mod
> # SysExceptions4 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/SysExceptions.def
> # M2EXCEPTION4 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/M2EXCEPTION.mod
> # Storage4 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/Storage.mod
> # RTExceptions3 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/RTExceptions.mod
> # M2RTS2 
> /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim/M2RTS.mod
> # hello1 hello.mod
> #
> # Initialization order
> #
> StrIO
> StrLib
> ASCII
> NumberIO
> Indexing
> errno
> termios
> FIO
> IO
> StdIO
> Debug
> SysStorage
> SysExceptions
> M2EXCEPTION
> hello
>
>and now to generate the scaffold for a static application:
>
>$ ~/opt/bin/gm2 -fmakeinit -c -g hello.mod
>$ cat hello_m2.cpp
> extern "C" void exit(int);
>
> extern "C" void RTExceptions_DefaultErrorCatch(void);
> extern "C" void _M2_Storage_init (int argc, char *argv[]);
> extern "C" void _M2_Storage_finish (void);
> extern "C" void _M2_SYSTEM_init (int argc, char *argv[]);
> extern "C" void _M2_SYSTEM_finish (void);
> extern "C" void _M2_M2RTS_init (int argc, char *argv[]);
> extern "C" void _M2_M2RTS_finish (void);
> extern "C" void _M2_RTExceptions_init (int argc, char *argv[]);
> extern "C" void _M2_RTExceptions_finish (void);
> extern "C" void _M2_StrIO_init (int argc, char *argv[]);
> extern "C" void _M2_StrIO_finish (void);
> extern "C" void _M2_StrLib_init (int argc, char *argv[]);
> extern "C" void _M2_StrLib_finish (void);
> extern "C" void _M2_ASCII_init (int argc, char *argv[]);
> extern "C" void _M2_ASCII_finish (void);
> extern "C" void _M2_NumberIO_init (int argc, char *argv[]);
> extern "C" void _M2_NumberIO_finish (void);
> extern "C" void _M2_Indexing_init (int argc, char *argv[]);
> extern "C" void _M2_Indexing_finish (void);
> extern "C" void _M2_errno_init (int argc, char *argv[]);
> extern "C" void _M2_errno_finish (void);
> extern "C" void _M2_termios_init (int argc, char *argv[]);
> extern "C" void _M2_termios_finish (void);
> extern "C" void _M2_FIO_init (int argc, char *argv[]);
> extern "C" void _M2_FIO_finish (void);
> extern "C" void _M2_IO_init (int argc, c

libiberty: Would it be reasonable to add support for GnuCOBOL function name demangling?

[Simon Sobisch via Gcc-patches]

Hi fellow hackers,

first of all: I'm not sure if this is the correct mailing list for this 
question, but I did not found a separate one and 
gnu.org/software/libiberty redirects to 
https://gcc.gnu.org/onlinedocs/libiberty.pdf - so I'm here.

If there's a better place for this: please drop a note.

I've never "worked" with libiberty directly but am sure I'm using it 
quite regularly with various tools including GDB and valgrind.
Therefore I currently cannot send a patch for the function name 
demangling, but if this is a reasonable thing to add I'd like to work on 
this with someone.


As noted: the first question is: is it reasonable to add support for 
GnuCOBOL?


* How would the demangler know it is to be called? Just "best match" 
(GnuCOBOL modules always have some symbols in it which should be 
available if there is any debugging information in, if that helps)?
* Giving the work of gcc-cobol which was discussed on this mailing list 
some months ago (not sure about its current state) there possibly will 
be a COBOL support be "integrated" - with possibly different name 
mangling. But still - GnuCOBOL is used "in the wild" (for production 
environments) since years (and will be for many years to come, both 
based on GCC and with other compilers) and the name mangling rules did 
not change.


A second question would be: Is there anyone who would be willing to work 
on this with me?

Where would "we" or I start?

Thank you for taking the time to read and possibly answer,
Simon Sobisch

Maintainer GnuCOBOL




OpenPGP_0x13E96B53C005604E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

vec_perm_const hook -- Fix build failure in ARM backend

[Prathamesh Kulkarni via Gcc-patches]

Hi,
I forgot to adjust prototype for arm_vectorize_vec_perm_const, which,
resulted in following
build error:

# 00:05:33 make[3]: [Makefile:1787:
armv8l-unknown-linux-gnueabihf/bits/largefile-config.h] Error 1
(ignored)
# 00:10:53 
/home/tcwg-buildslave/workspace/tcwg_gnu_4/abe/snapshots/gcc.git~master/gcc/config/arm/arm.cc:299:13:
error: ‘bool arm_vectorize_vec_perm_const(machine_mode, rtx, rtx, rtx,
const vec_perm_indices&)’ declared ‘static’ but never defined
[-Werror=unused-function]
# 00:12:22 make[3]: *** [Makefile:2418: arm.o] Error 1
# 00:23:34 make[2]: *** [Makefile:5005: all-stage2-gcc] Error 2
# 00:23:34 make[1]: *** [Makefile:25739: stage2-bubble] Error 2
# 00:23:34 make: *** [Makefile:1072: all] Error 2

https://gcc.gnu.org/pipermail/gcc-regression/2022-May/076645.html

The attached patch fixes it.
OK to commit ?

Thanks,
Prathamesh
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 70c2d50f0cc..7ecf7b74ffa 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -296,8 +296,8 @@ static int arm_cortex_a5_branch_cost (bool, bool);
 static int arm_cortex_m_branch_cost (bool, bool);
 static int arm_cortex_m7_branch_cost (bool, bool);
 
-static bool arm_vectorize_vec_perm_const (machine_mode, rtx, rtx, rtx,
- const vec_perm_indices &);
+static bool arm_vectorize_vec_perm_const (machine_mode, machine_mode, rtx, rtx,
+ rtx, const vec_perm_indices &);
 
 static bool aarch_macro_fusion_pair_p (rtx_insn*, rtx_insn*);