[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 ();
+  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 

Passing c blocks to pre processor

[Yair Lenga via Gcc]

Hi,

I am trying to define macros that will accept code blocks. This will be used to 
create high level structures (like iterations, etc.). Ideally, I would like to 
do something like (this is simplified example, actual code much more 
application specific):

Foreach(var, low, high, block)

While should translate to:
For (int var=low ; var < high ; var ++) block 

The challnge is the gcc pre processor does not accept blocks. It assume a comma 
terminate a block. For example:
Foreach(foo, 1, 30, { int z=5, y=3, …}) will invoke the macro with 5 arguments: 
(1) foo (2) 1, (3) 30, (4) { int z=5}, (5) y=3,

Is there a way to tell CPP that an argument that start with ‘{‘ should extend 
until the matching ‘}’ ? Similar to the way ‘(‘ in macro arguments will extend 
till matching ‘)’.

Thanks, yair.


Sent from my iPad

[Bug analyzer/105755] New: -Wanalyzer-null-dereference regression compiling Emacs

[eggert at cs dot ucla.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755

Bug ID: 105755
   Summary: -Wanalyzer-null-dereference regression compiling Emacs
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 53047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53047=edit
compile with 'gcc -fanalyzer -O2 -S' to see the false positive

GCC 12.1.1 20220507 (Red Hat 12.1.1-1) on x86-64 has a false positive compiling
the attached program w.i, which is a stripped-down version of GNU Emacs master.
Compile it this way:

gcc -fanalyzer -O2 -S w.i

and it generates the following incorrect output. GCC 11.2 compiles the code
cleanly so this is a regression.

In function ‘PSEUDOVECTORP’,
inlined from ‘SUB_CHAR_TABLE_P’ at w.i:154:10,
inlined from ‘CHAR_TABLE_REF_ASCII’ at w.i:169:28:
w.i:53:56: warning: dereference of NULL ‘*tbl.ascii’ [CWE-476]
[-Wanalyzer-null-dereference]
   52 |   && union vectorlike_header *)
  | 
   53 | ((char *) XLP ((a)) - Lisp_Vectorlike))->size
  | ~~~^~
  ‘word_boundary_p’: events 1-2
|
|  187 | word_boundary_p (Lisp_Object char_script_table, int c1, int c2)
|  | ^~~
|  | |
|  | (1) entry to ‘word_boundary_p’
|  188 | {
|  189 |   return EQ (CHAR_TABLE_REF (char_script_table, c1),
|  |  ~~~
|  |  |
|  |  (2) calling ‘CHAR_TABLE_REF’ from ‘word_boundary_p’
|  190 |  CHAR_TABLE_REF (char_script_table, c2));
|  |  ~~~
|
+--> ‘CHAR_TABLE_REF’: events 3-6
   |
   |  179 | CHAR_TABLE_REF (Lisp_Object ct, int idx)
   |  | ^~
   |  | |
   |  | (3) entry to ‘CHAR_TABLE_REF’
   |  180 | {
   |  181 |   return (ASCII_CHAR_P (idx)
   |  |  ~~~
   |  182 |   ? CHAR_TABLE_REF_ASCII (ct, idx)
   |  |   
   |  | |
   |  | (5) ...to here
   |  | (6) calling ‘CHAR_TABLE_REF_ASCII’ from
‘CHAR_TABLE_REF’
   |  183 |   : char_table_ref (ct, idx));
   |  |   ~~~
   |  |   |
   |  |   (4) following ‘true’ branch...
   |
   +--> ‘CHAR_TABLE_REF_ASCII’: events 7-15
  |
  |  164 | CHAR_TABLE_REF_ASCII (Lisp_Object ct, ptrdiff_t idx)
  |  | ^~~~
  |  | |
  |  | (7) entry to ‘CHAR_TABLE_REF_ASCII’
  |..
  |  169 |   Lisp_Object val = (! SUB_CHAR_TABLE_P
(tbl->ascii) ? tbl->ascii
  |  |
~
  |  170 |  : XSUB_CHAR_TABLE
(tbl->ascii)->contents[idx]);
  |  | 
~~
  |  |  |
  |  |  (8) following ‘false’
branch...
  |  171 |   if (NILP (val))
  |  |  ~
  |  |  |
  |  |  (9) ...to here
  |  |  (10) following ‘true’ branch...
  |  172 | val = tbl->defalt;
  |  | ~
  |  | |
  |  | (11) ...to here
  |  173 |   if (!NILP (val) || NILP (tbl->parent))
  |  |  ~~
  |  |  ||  |
  |  |  ||  (13) ...to here
  |  |  |(14) following ‘true’
branch...
  |  |  (12) following ‘false’ branch (when ‘val’
is NULL)...
  |  174 | return val;
  |  |~~~
  |  ||
  |  |(15) ...to here
  |
   <--+
   |
 ‘CHAR_TABLE_REF’: event 16
   |
   |  182 |   ? CHAR_TABLE_REF_ASCII (ct, idx)
   |  | ^~
  

[Bug c++/105652] [12/13 Regression] ICE: in is_base_type, at dwarf2out.cc:13400 since r12-1937-gc28e1d288ab727de

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105652

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:221acd67ca50f8f069037e034a3250f13d75a9f5

commit r13-806-g221acd67ca50f8f069037e034a3250f13d75a9f5
Author: Jason Merrill 
Date:   Thu May 26 22:43:05 2022 -0400

c++: lambda in concept [PR105652]

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.

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.

[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

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[filip.hejsek at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

--- Comment #1 from Filip Hejsek  ---
Not that i would really understand the machine description files, but the
problem seems to be caused by this instruction definition:

(define_insn_and_split "udivmodsi4"
  [(parallel [(set (match_operand:SI 0 "pseudo_register_operand" "")
   (udiv:SI (match_operand:SI 1 "pseudo_register_operand" "")
   (match_operand:SI 2 "pseudo_register_operand" "")))
  (set (match_operand:SI 3 "pseudo_register_operand" "")
   (umod:SI (match_dup 1) (match_dup 2)))
  (clobber (reg:SI 18))
  (clobber (reg:SI 22))
  (clobber (reg:HI 26))
  (clobber (reg:HI 30))])]
  ""
  "this udivmodsi4 pattern should have been splitted;"
  ""
  [(set (reg:SI 22) (match_dup 1))
   (set (reg:SI 18) (match_dup 2))
   (parallel [(set (reg:SI 18) (udiv:SI (reg:SI 22) (reg:SI 18)))
  (set (reg:SI 22) (umod:SI (reg:SI 22) (reg:SI 18)))
  (clobber (reg:HI 26))
  (clobber (reg:HI 30))])
   (set (match_dup 0) (reg:SI 18))
   (set (match_dup 3) (reg:SI 22))])

Just as in bug 88051, the instruction is missing from the generated switch in
add_clobbers and removing pararllel from the definition fixes the problem. (I
don't understand enough to know if it's the correct fix though.)

There are 4 instructions with parallel in the definition: divmodpsi4,
udivmodpsi4, divmodsi4, udivmodsi4.

[Bug tree-optimization/105665] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22

[aoliva at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105665

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #5 from Alexandre Oliva  ---
Mine.  The problem is that the undef name may appear deep in a chain of phis,
instead of appearing directly in the base expr.

[Bug target/105754] gcc/config/i386/i386.c missing break in get_builtin_code_for_version

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105754

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
   Target Milestone|--- |10.0
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Looks like when parts of r10-2664-ga9fcfec30f70c3 was backported to the GCC 9
branch (in r9-9351-g45d3b8886f2ecb), it didn't include the break.

Anyways GCC 9.5.0 is the last release of GCC 9 series so marking as won't fix.

"This is also the last release from the GCC 9 branch, GCC continues
to be maintained on the GCC 10, GCC 11 and GCC 12 branches and the
development trunk."

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.

[Bug c/105754] New: gcc/config/i386/i386.c missing break in get_builtin_code_for_version

[paulo.santos at anacom dot pt via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105754

Bug ID: 105754
   Summary: gcc/config/i386/i386.c missing break in
get_builtin_code_for_version
   Product: gcc
   Version: 9.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paulo.santos at anacom dot pt
  Target Milestone: ---

Hi, there is a missing break in gcc/config/i386/i386.c (9.4.0, 9.5.0):

(...)
case PROCESSOR_CASCADELAKE:
  arg_str = "cascadelake";
  priority = P_PROC_AVX512F;
  break;
case PROCESSOR_TIGERLAKE:
  arg_str = "tigerlake";
  priority = P_PROC_AVX512F;
case PROCESSOR_BONNELL:
  arg_str = "bonnell";
  priority = P_PROC_SSSE3;
  break;
case PROCESSOR_KNL:
(...)

Fix:

--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -32267,6 +32267,7 @@ get_builtin_code_for_version (tree decl,
case PROCESSOR_TIGERLAKE:
  arg_str = "tigerlake";
  priority = P_PROC_AVX512F;
+ break;
case PROCESSOR_BONNELL:
  arg_str = "bonnell";
  priority = P_PROC_SSSE3;


Thx,
pasan

gcc-11-20220527 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220527 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220527/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 186fcf8b7a7c17a8a17466bc9149b3ca4ca9dd3e

You'll find:

 gcc-11-20220527.tar.xz   Complete GCC

  SHA256=dd2162db1a11ad3761391cf8f2d0d5157f0feeab14dd8c36fbb59d41b93b55f4
  SHA1=9ea959604b616fe99188cb3fd06b3da4a4217508

Diffs from 11-20220520 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug target/105753] New: [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

[filip.hejsek at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753

Bug ID: 105753
   Summary: [avr] ICE: in add_clobbers, at
config/avr/avr-dimode.md:2705
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: filip.hejsek at gmail dot com
  Target Milestone: ---
Target: avr

GCC fails when compiling the following C program for AVR (with at least -O1):

int digit_sum(unsigned long n) {
  int sum = 0;

  do {
int x = n % 10;
n /= 10;
sum += x;
  } while(n);

  return sum;
}

I have tested both GCC 12.1.0 form Arch Linux and a development version (GCC
13.0.0) compiled from git sources.

Here is the compiler output:

$ ~/avr_gcc_install/bin/avr-gcc -c -O1 bug.c
during RTL pass: combine
bug.c: In function ‘digit_sum’:
bug.c:13:1: internal compiler error: in add_clobbers, at
config/avr/avr-dimode.md:2705
   13 | }
  | ^
0x770d30 add_clobbers(rtx_def*, int)
../../gcc/gcc/config/avr/avr-dimode.md:2705
0x1645c94 recog_for_combine_1
../../gcc/gcc/combine.cc:11422
0x164979e recog_for_combine
../../gcc/gcc/combine.cc:11622
0x165aef7 try_combine
../../gcc/gcc/combine.cc:3543
0x165e72f combine_instructions
../../gcc/gcc/combine.cc:1266
0x165e72f rest_of_handle_combine
../../gcc/gcc/combine.cc:14976
0x165e72f execute
../../gcc/gcc/combine.cc:15021
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
$ ~/avr_gcc_install/bin/avr-gcc -v
Using built-in specs.
Reading specs from
/home/filiph/avr_gcc_install/lib/gcc/avr/13.0.0/device-specs/specs-avr2
COLLECT_GCC=/home/filiph/avr_gcc_install/bin/avr-gcc
COLLECT_LTO_WRAPPER=/home/filiph/avr_gcc_install/libexec/gcc/avr/13.0.0/lto-wrapper
Target: avr
Configured with: ../gcc/configure --prefix=/home/filiph/avr_gcc_install
--target=avr --enable-languages=c --with-as=/usr/bin/avr-as --with-gnu-as
--with-ld=/usr/bin/avr-ld --with-gnu-ld
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220525 (experimental) [master -gda2c56ee6] (GCC) 

$ avr-gcc -c -O1 bug.c
during RTL pass: combine
bug.c: In function 'digit_sum':
bug.c:13:1: internal compiler error: in add_clobbers, at
config/avr/avr-dimode.md:2705
   13 | }
  | ^
0x140115b diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x140209d internal_error(char const*, ...)
???:0
0x5bafbc fancy_abort(char const*, int, char const*)
???:0
0x5b1839 add_clobbers(rtx_def*, int) [clone .cold]
???:0
0x1213b97 recog_for_combine_1(rtx_def**, rtx_insn*, rtx_def**)
???:0
0x1215e8e recog_for_combine(rtx_def**, rtx_insn*, rtx_def**)
???:0
0x1228da5 try_combine(rtx_insn*, rtx_insn*, rtx_insn*, rtx_insn*, int*,
rtx_insn*)
???:0
0x122c0a4 (anonymous namespace)::pass_combine::execute(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/12.1.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/12.1.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-12.1.0/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC) 

(This bug seems to be similar to bug 88051, but that one was on i386.)

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111

--- Comment #6 from Jason Merrill  ---
(In reply to Jason Merrill from comment #5)
> An alternative fix for this bug would be to include the evaluation context
> in the satisfaction cache.

...if the evaluation involved access checking of a private or protected member.

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

[kees at outflux dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

--- Comment #11 from Kees Cook  ---
and with a flex array to compare:
https://godbolt.org/z/s9nb4Y7q4

Loop splitting based on constant prefix of an array

[Laleh Beni via Gcc]

GCC compiler is able to understand if the prefix of an array holds
constant/static data and apply compiler optimizations on that partial
constant part of the array, however, it seems that it is not leveraging
this information in all cases.

On understanding the behavior of compiler optimization for partially
constant arrays and especially how the loop splitting pass could have an
influence on the potential constant related optimizations such as constant
folding I am using  the following example:



Considering an array where the prefix of that array is compile-time
constant data, and the rest of the array is runtime data, should the
compiler be able to optimize the calculation for the first part of the
array?

Let's look at the below example:



You can see the code and its assembly here: https://godbolt.org/z/xjxbz431b



#include 

inline int sum(const int array[], size_t len) {

  int res = 0;

  for (size_t i = 0; i < len; i++) {

res += array[i];

  }

  return res;

}

int main(int argc, char** argv)

{

int arr1[6] = {200,2,3, argc, argc+1, argc+2};

return  sum(arr1, 6);

}





In our sum function we are measuring the some of the array elements, where
the first half of it is  static compile-time constants and the second half
are dynamic data.

When we compile this with the "x86-64 GCC 12.1" compiler with "-O3
-std=c++2a " flags, we get the following assembly code:



 main:

mov rax, QWORD PTR .LC0[rip]

mov DWORD PTR [rsp-28], edi

mov DWORD PTR [rsp-32], 3

movqxmm1, QWORD PTR [rsp-32]

mov QWORD PTR [rsp-40], rax

movqxmm0, QWORD PTR [rsp-40]

lea eax, [rdi+1]

add edi, 2

mov DWORD PTR [rsp-24], eax

paddd   xmm0, xmm1

mov DWORD PTR [rsp-20], edi

movqxmm1, QWORD PTR [rsp-24]

paddd   xmm0, xmm1

movdeax, xmm0

pshufd  xmm2, xmm0, 0xe5

movdedx, xmm2

add eax, edx

ret

.LC0:

.long   200

.long   2





However, if we add an “if” condition in the loop for calculating the result
of the sum, the if condition seems to enable the loop splitting pass:



You can see the code and its assembly here:  https://godbolt.org/z/ejecbjMKG



#include 

inline int sum(const int array[], size_t len) {

  int res = 0;

  for (size_t i = 0; i < len; i++) {

if (i < 1)

res += array[i];

else

res += array[i];

  }

  return res;

}

int main(int argc, char** argv)

{

int arr1[6] = {200,2,3, argc, argc+1, argc+2};

return  sum(arr1, 6);

}





we get the following assembly code:



main:

lea eax, [rdi+208+rdi*2]

ret





As you can see the “if” condition has the same calculation for both the
“if” and “else” branch in calculating the sum over the array, however, it
seems that it is triggering the “loop splitting pass” which results in
further optimizations such as constant folding of the whole computation and
resulting in such a smaller and faster assembly code.

My question is, why the compiler is not able to take advantage of
constantans in the prefix of the array in the first place?

Also adding a not necessary “if condition” which is just repeating the same
code for "if" and "else", doesn’t seem to be the best way to hint the
compiler to take advantage of this optimization; so is there another way to
make the compiler aware of this? ( I used the -fsplit-loops flag and it
didn't have any effect for this example.)



As a next step if we use an array that has some constant values in the
prefix but not a compile time constant length such as the following example:

Code link is here: https://godbolt.org/z/3qGqshzn9



#include 

inline int sum(const int array[], size_t len) {

  int res = 0;

  for (size_t i = 0; i < len; i++) {

if (i < 1)

res += array[i];

else

res += array[i];

  }

  return res;

}

int main(int argc, char** argv)

{

size_t len = argc+3;

int arr3[len] = {600,10,1};

for (unsigned int i = 3; i < len; i++) arr3[i] = argc+i;

return sum(arr3, 2);

}



In this case the GCC compiler is not able to apply constant folding on the
first part of the array!

In general is there anyway that the GCC compiler would understand this and
apply constant folding optimizations here?

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

[kees at outflux dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

--- Comment #10 from Kees Cook  ---
Here's a slightly reworked example:
https://godbolt.org/z/EvehMax84

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

[kees at outflux dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

--- Comment #9 from Kees Cook  ---
Just to clarify, __builtin_dynamic_object_size() shouldn't have anything to do
with this. What's needed is something like -fstrict-flex-arrays so that all the
"trailing array is a flex array" assumptions can be killed everywhere in GCC.
Only an _actual_ flex array should be treated as such.

[Bug rtl-optimization/98334] Failure to optimally optimize add loop to mul

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98334

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||roger at nextmovesoftware dot 
com
 Resolution|--- |FIXED

--- Comment #6 from Roger Sayle  ---
This is now fully optimized at the tree level too.
int f (int i, unsigned int n)
{
  int result;
  int _1;

   [local count: 118111600]:
  _1 = (int) n_3(D);
  result_2 = _1 * i_6(D);
  return result_2;

}

Re: Documentation format question

[Andrew MacLeod via Gcc]

On 5/27/22 02:38, Richard Biener wrote:

On Wed, May 25, 2022 at 10:36 PM Andrew MacLeod via Gcc  wrote:

I am going to get to some documentation for ranger and its components
later this cycle.

I use to stick these sorts things on the wiki page, but i find that gets
out of date really quickly.  I could add more comments to the top of
each file, but that doesnt seem very practical for larger architectural
descriptions, nor for APIs/use cases/best practices.   I could use
google docs and turn it into a PDF or some other format, but that isnt
very flexible.

Do we/anyone have any forward looking plans for GCC documentation that I
should consider using?  It would be nice to be able to tie some of it
into source files/classes in some way, but I am unsure of a decent
direction.  It has to be easy to use, or I wont use it :-)  And i
presume many others wouldn't either.  Im not too keep an manually
marking up text either.

The appropriate place for this is the internals manual and thus the
current format in use is texinfo in gcc/doc/

And there is no move to convert it to anything more modern?    Is there 
at least a reasonable tool to be able to generate texinfo from?  
Otherwise the higher level stuff is likely to end up in a wiki page 
where I can just visually do it.


Andrew

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 = 

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

[Bug target/100181] hot-cold partitioned code doesn't assemble

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100181

Thomas Schwinge  changed:

   What|Removed |Added

   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=97827,|
   |https://bugs.llvm.org/show_ |
   |bug.cgi?id=41914,   |
   |https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=93515,|
   |https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=86660 |

--- Comment #14 from Thomas Schwinge  ---
Confirming that this issue has been "resolved" ;-) via the recent commit
r13-742-g8086230e7ac619c0b0eeb6e15df7975ac214725f "amdgcn: Remove LLVM 9
assembler/linker support": "The minimum required LLVM version is now 13.0.1,
and is enforced by configure."; I've thus removed my "[gcn] [WIP] Force-disable
'-freorder-blocks-and-partition' [PR94278]" hack from local trees.

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

[Bug target/99405] Rotate with mask not optimized on x86 for QI/HImode rotates

[roger at nextmovesoftware dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99405

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com
   Target Milestone|--- |12.0
 Status|ASSIGNED|RESOLVED
  Known to work||12.0
 Resolution|--- |FIXED

--- Comment #8 from Roger Sayle  ---
This was fixed for GCC 12.0.  Thanks Jakub.

[Bug c++/100374] Type-constraints of member function templates should not be substituted into during implicit instantiation

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100374

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

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 

[Bug c++/104111] Concept evaluation depends on context where it was first checked

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111

Jason Merrill  changed:

   What|Removed |Added

 Blocks||67491

--- Comment #5 from Jason Merrill  ---
(In reply to Patrick Palka from comment #3)
> > because concept-id evaluation shall not depend on the context.
> 
> One consequence of making this change to concept-id evaluation would be that
> for:
> 
>   template void f() requires (!C);
> 
> during constraint checking for say f(), we no longer evaluate C
> (as part of evaluation of the atomic constraint !C) in the access context
> of f, which seems surprising to me.
> 
> CC'ing Jason for guidance.

This issue was discussed on the CWG mailing list back in 2018, but seems never
to have made it to the issues list.  There was general agreement at the time
that access should be checked in the lexical context of the atomic constraint,
as with other expressions; this does indeed have the consequence that you
mention.  Which means that since we don't have class-scope concepts, any
constraints that need to depend on access control need to be written directly
in the requires-clause rather than through a concept.  Or just give up on
trying to express constraints that depend on access.

An alternative fix for this bug would be to include the evaluation context in
the satisfaction cache.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

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 ,
> + vec )
> +{
> +  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 = true;
> +
> + 

[Bug c++/105752] Template function can access private member

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105752

--- Comment #3 from Jonathan Wakely  ---
And if you never instantiate the function, who cares? It doesn't actually
access the private member, because you never call it. And if you try to, it
doesn't compile.

[Bug c++/105752] Template function can access private member

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105752

--- Comment #2 from Jonathan Wakely  ---
Which is permitted by the standard.

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,
+

[Bug c++/105752] Template function can access private member

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105752

--- Comment #1 from Andrew Pinski  ---
There might already been a dup of this. Gcc does not do access checking until
instantiation time (as you saw) even for non dependent things.

[Bug c++/105752] New: Template function can access private member

[csaba_22 at yahoo dot co.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105752

Bug ID: 105752
   Summary: Template function can access private member
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: csaba_22 at yahoo dot co.uk
  Target Milestone: ---

The following code

class Outer
{
private: //  !
struct Inner
{};
};

template
struct Meow
{
void purr() {
Outer::Inner oi;
}
};

int main()
{
Meow kitty;
//kitty.purr();
}

is compiled by GCC from 4.1.2 to 12.1.0, but is rejected by all clang releases 
 available on godbolt.

https://godbolt.org/z/58Yca6dah

Also mentioned here:
https://stackoverflow.com/questions/28596242/accessing-private-inner-class-type-from-non-member-template-function

If the call to the function is uncommented, then GCC also emits an error.

Visual Studio 2013 update 4 also  emits an  error (allegedly), so this sounds
like a bug.

[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 12.2 and 13.

[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:2c11a9a380e7af333e19d6e576a889646d699b2a

commit r12-8419-g2c11a9a380e7af333e19d6e576a889646d699b2a
Author: Marek Polacek 
Date:   Fri May 27 10:51:30 2022 -0400

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

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.

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.

(cherry picked from commit d822f4bbd714c6595f70cc6dcebecfb6662d)

[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:d822f4bbd714c6595f70cc6dcebecfb6662d

commit r13-803-gd822f4bbd714c6595f70cc6dcebecfb6662d
Author: Marek Polacek 
Date:   Fri May 27 10:51:30 2022 -0400

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

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.

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.

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

[Bug c/90658] [10/11/12/13 Regression] ICE in default_conversion, at c/c-typeck.c:2159

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Marek Polacek  ---
Fixed for GCC 13.

[Bug c/90658] [10/11/12/13 Regression] ICE in default_conversion, at c/c-typeck.c:2159

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90658

--- Comment #10 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:ca4b95069ca7dbf0be3a5aae053631e7a1b20103

commit r13-802-gca4b95069ca7dbf0be3a5aae053631e7a1b20103
Author: Marek Polacek 
Date:   Thu May 26 18:59:44 2022 -0400

c-family: fix attribute constructor ICE [PR90658]

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.

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.

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

[Bug c++/105751] New: std::array comparision does not inline memcmp

[gcc at maxbachmann dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105751

Bug ID: 105751
   Summary: std::array comparision does not inline memcmp
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at maxbachmann dot de
  Target Milestone: ---

On trunk and gcc 12.1, with -O2/-O3 the following array comparison is only
optimized to a memcmp, but not to a direct comparision:

```
bool test(std::array& a, std::array& b)
{
return a == b;
}
```
which is optimized to:
```
test(std::array&, std::array&):
sub rsp, 8
mov edx, 8
callmemcmp
testeax, eax
seteal
add rsp, 8
ret
```

However for a direct memcmp gcc is able to optimize the memcmp to a single 64
bit comparision:
```
bool test(int8_t* a, int8_t* b)
{
return memcmp(a, b, sizeof(int8_t) * 8) == 0;
}
```
which is optimized to
```
test(signed char*, signed char*):
mov rax, QWORD PTR [rsi]
cmp QWORD PTR [rdi], rax
seteal
ret
```

This is optimized to a single comparision both in clang and msvc:
https://godbolt.org/z/99reqf3Yz

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",
>>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

[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104477

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Agree on that.

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",
> ->where);
> +"mentioned in LINK clause and later in %s clause",
> +>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",
> ->where);
> +"mentioned in TO or ENTER clause and later in "
> +"LINK clause", >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",
   >where);
  diagnostics earlier, above
  else if (n->sym->attr.omp_declare_target
   && n->sym->attr.omp_declare_target_link
  

[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

[Bug c++/104477] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104477

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
https://clang.llvm.org/cxx_status.html#cxx23 says

"Clang provides a __reference_binds_to_temporary type trait builtin, with which
the library facility can be partially implemented. Both
__reference_constructs_from_temporary and __reference_converts_from_temporary
builtins should be provided, following the normal cross-vendor convention to
implement traits requiring compiler support directly."

which suggests to me that we should implement two new builtins:
__reference_constructs_from_temporary
__reference_converts_from_temporary
With those in place, I don't think we need __reference_binds_to_temporary.

[Bug sanitizer/105750] Too small red zone size for struct variables.

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105750

--- Comment #2 from Li Shaohua  ---
Yea, I'm aware of that. What makes me confused is for the following code, gcc
generates a larger redone for the struct variable j, i.e., 48 bytes.

https://godbolt.org/z/Wv1djjrqv

$cat b.c
struct a {
  long f;
};
int i;
volatile struct a j[1][6] = {2};
long k() { 
return j[0][6].f; 
}
int main() { 
return k(); 
}
$
$

[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 (", >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 (", >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 (", >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) | 

[Bug sanitizer/105750] Too small red zone size for struct variables.

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105750

--- Comment #1 from Jakub Jelinek  ---
That is completely intentional, you can find similar testcases for any size of
the red zone and infinite red zones aren't possible.  In fact, any growth of
the red zone makes data segments larger, it is always a compromise between what
can be detected and how much memory it uses.

[Bug sanitizer/105750] New: Too small red zone size for struct variables.

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105750

Bug ID: 105750
   Summary: Too small red zone size for struct variables.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, gcc only generates 32 bytes red zone for the struct
variable j, which makes it fail to detect the buffer-overflow in k().

$cat a.c
struct a {
  int b;
  long c[2];
  char d;
  long f;
  char g
};
int i;
volatile struct a j[1][6] = {2};
long k() { 
return j[0][6].f; 
}
int main() { 
return k(); 
}
$
$gcc-trunk -O0 -fsanitize=address -w a.c && ./a.out
$
$

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

[qinzhao at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #7)
> I couldn't work on -fstrict-flex-arrays then, sorry.  I do have it in my
> plan for gcc 13, but I'll admit it's not on the very top of my list of
> things to do this year.  If you or anyone else needs a stronger guarantee of
> this making it into gcc 13 and wants to work on it, I'll be happy to help
> with reviews.
thanks for the info.
will study this a little bit more and hopefully make it into gcc13.

[Bug libstdc++/105671] [11/12 Regression] Unexplained "undefined reference" error

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[11/12/13 Regression]   |[11/12 Regression]
   |Unexplained "undefined  |Unexplained "undefined
   |reference" error|reference" error

--- Comment #6 from Jonathan Wakely  ---
Yes, I verified it using your test program (thanks!) against all affected
branches. It's fixed on trunk, I'll backport the attribute in a couple of
weeks.

[Bug c++/105725] [ICE] segfault with `-Wmismatched-tags`

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105725

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[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

[Bug libstdc++/105671] [11/12/13 Regression] Unexplained "undefined reference" error

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:de57440858591a88e8fd7ba2505ca54546c86021

commit r13-801-gde57440858591a88e8fd7ba2505ca54546c86021
Author: Jonathan Wakely 
Date:   Fri May 27 12:43:18 2022 +0100

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

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.

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 

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

[Bug libstdc++/105671] [11/12/13 Regression] Unexplained "undefined reference" error

[christian.morales.vega at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671

--- Comment #4 from Cristian Morales Vega  ---
I can confirm adding "__attribute__((always_inline))" in _M_high_mark() solves
the issue.

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.

> +++ 

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
> > > > 

[Bug ipa/105140] [10 Regression] ICE: SIGSEGV in fold_convertible_p with conflicting function redeclaration since r10-5112-gfddcfa5b84bf8a06

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.3.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/105163] [10 Regression] ICE: SSA corruption since r0-122928

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.3.1
 Resolution|--- |FIXED
  Known to fail||10.3.0
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug tree-optimization/105173] [10 Regression] ICE: during GIMPLE pass: reassoc: verify_ssa failed (definition in block 2 follows the use) at -Ofast with decimals since r7-950-g8a85cee26eabf5cf

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105173

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail|10.3.1  |10.3.0
  Known to work||10.3.1
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug tree-optimization/105368] [10 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.3.1
 Resolution|--- |FIXED
  Known to fail||10.3.0

--- Comment #11 from Richard Biener  ---
Fixed.

[Bug tree-optimization/105431] ICE: SIGSEGV in powi_as_mults_1 (tree-ssa-math-opts.cc:1512) with -Ofast and __builtin_pow()

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105431

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.3.0, 11.2.0
  Known to work||10.3.1, 11.2.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug ipa/105728] dead store to static var not optimized out

[felix-gcc at fefe dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728

--- Comment #4 from felix-gcc at fefe dot de ---
If you do have a printf that references debug_cnt, it wouldn't be removed,
right?

If you expect unreferenced variables to not be optimized out, you can always
compile without optimizer. For local variables even that doesn't help with
clang already.

OTOH we do have attributes "used" and "unused". They could be extended to
variables.

[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105266

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:5d4f9ef0d2123923f7aae9ebd546a72c7eeb1467

commit r10-10772-g5d4f9ef0d2123923f7aae9ebd546a72c7eeb1467
Author: Kewen Lin 
Date:   Sun Apr 17 21:34:51 2022 -0500

testsuite: Skip pr105250.c for powerpc and s390 [PR105266]

This test case pr105250.c is like its related pr105140.c, which
suffers the error with message like "{AltiVec,vector} argument
passed to unprototyped" on powerpc and s390.  So like commits
r12-8025 and r12-8039, this fix is to add the dg-skip-if for
powerpc*-*-* and s390*-*-*.

gcc/testsuite/ChangeLog:

PR testsuite/105266
* gcc.dg/pr105250.c: Skip for powerpc*-*-* and s390*-*-*.

(cherry picked from commit 021b51814d67bedd8f41ac07edfd05654140c6e5)

[Bug ipa/105250] ICE: in fold_convert_loc, at fold-const.cc:2581 with conflicting function redeclaration

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105250

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:644185d0e42fd93d1f793475a0117d6751fb042e

commit r10-10771-g644185d0e42fd93d1f793475a0117d6751fb042e
Author: Richard Biener 
Date:   Wed Apr 13 08:52:57 2022 +0200

tree-optimization/105250 - adjust fold_convertible_p PR105140 fix

The following reverts the original PR105140 fix and goes for instead
applying the additional fold_convert constraint for VECTOR_TYPE
conversions also to fold_convertible_p.  I did not try sanitizing
all of this at this point.

2022-04-13  Richard Biener  

PR tree-optimization/105250
* fold-const.c (fold_convertible_p): Revert
r12-7979-geaaf77dd85c333, instead check for size equality
of the vector types involved.

* gcc.dg/pr105250.c: New testcase.

(cherry picked from commit 4e892de6774f86540d36385701aa7b0a2bba5155)

[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:1cccf2e43b43d6e75df2257ddc2682dceb9f04ae

commit r10-10770-g1cccf2e43b43d6e75df2257ddc2682dceb9f04ae
Author: Andreas Krebbel 
Date:   Thu Apr 7 07:29:13 2022 +0200

IBM zSystems/testsuite: PR105147: Skip pr105140.c

pr105140.c fails on IBM zSystems with "vector argument passed to
unprototyped function".  s390_invalid_arg_for_unprototyped_fn in
s390.cc is triggered by that.

gcc/testsuite/ChangeLog:

PR target/105147
* gcc.dg/pr105140.c: Skip for s390*-*-*.

(cherry picked from commit 176df4ccb58689aae29511b99d60a448558ede94)

[Bug target/105147] New test case gcc.dg/pr105140.c introduced in r12-7979-geaaf77dd85c333 has excess errors

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:b3157b03a8b83445e6ce48c9d9c6a6b614937691

commit r10-10769-gb3157b03a8b83445e6ce48c9d9c6a6b614937691
Author: Segher Boessenkool 
Date:   Wed Apr 6 15:22:24 2022 +

rs6000/testsuite: Skip pr105140.c

This test fails with error "AltiVec argument passed to unprototyped
function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
from 2005) actually tests for any vector type argument.  It also does
not fail on Darwin, not reflected here though.

2022-04-06  Segher Boessenkool  

gcc/testsuite/
PR target/105147
* gcc.dg/pr105140.c: Skip for powerpc*-*-*.

(cherry picked from commit c65d15d40738f3691ff1a39907a4b93e9fe5c5ae)

[Bug rtl-optimization/94618] [8/9 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
Bug 94618 depends on bug 105559, which changed state.

Bug 105559 Summary: [10 Regression] -g and -O3 cause timeout since 
r12-156-g8d4c374c4419a875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105559

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/105559] [10 Regression] -g and -O3 cause timeout since r12-156-g8d4c374c4419a875

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105559

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.3.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||10.3.1

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug ipa/105140] [10 Regression] ICE: SIGSEGV in fold_convertible_p with conflicting function redeclaration since r10-5112-gfddcfa5b84bf8a06

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:c515adf5d339ad942207d9121cf49e5b6c84093e

commit r10-10768-gc515adf5d339ad942207d9121cf49e5b6c84093e
Author: Richard Biener 
Date:   Mon Apr 4 10:20:05 2022 +0200

middle-end/105140 - fix bogus recursion in fold_convertible_p

fold_convertible_p expects an operand and a type to convert to
but recurses with two vector component types.  Fixed by allowing
types instead of an operand as well.

2022-04-04  Richard Biener  

PR middle-end/105140
* fold-const.c (fold_convertible_p): Allow a TYPE_P arg.

* gcc.dg/pr105140.c: New testcase.

(cherry picked from commit eaaf77dd85c333b116111bb1ae6c080154a4e411)

[Bug tree-optimization/105163] [10 Regression] ICE: SSA corruption since r0-122928

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105163

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:bdfe7e5510b28c3ab8f8cd0fd7f715f2da3af938

commit r10-10767-gbdfe7e5510b28c3ab8f8cd0fd7f715f2da3af938
Author: Richard Biener 
Date:   Wed Apr 6 09:36:38 2022 +0200

tree-optimization/105163 - abnormal SSA coalescing and reassoc

The negate propagation optimizations in reassoc did not look out for
abnormal SSA coalescing issues.  The following fixes that.

2022-04-06  Richard Biener  

PR tree-optimization/105163
* tree-ssa-reassoc.c (repropagate_negates): Avoid propagating
negated abnormals.

* gcc.dg/torture/pr105163.c: New testcase.

(cherry picked from commit 44fe49401725055a740ce47e80561b6932b8cd01)

[Bug tree-optimization/105173] [10 Regression] ICE: during GIMPLE pass: reassoc: verify_ssa failed (definition in block 2 follows the use) at -Ofast with decimals since r7-950-g8a85cee26eabf5cf

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105173

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:84ebfc7558d23c5262d35740d1d495bd0884a58c

commit r10-10766-g84ebfc7558d23c5262d35740d1d495bd0884a58c
Author: Richard Biener 
Date:   Wed Apr 6 11:43:01 2022 +0200

tree-optimization/105173 - fix insertion logic in reassoc

The find_insert_point logic around deciding whether to insert
before or after the found insertion point does not handle
the case of _12 = ..;, _12, 1.0 well.  The following puts the
logic into find_insert_point itself instead.

2022-04-06  Richard Biener  

PR tree-optimization/105173
* tree-ssa-reassoc.c (find_insert_point): Get extra
insert_before output argument and compute it.
(insert_stmt_before_use): Adjust.
(rewrite_expr_tree): Likewise.

* gcc.dg/pr105173.c: New testcase.

(cherry picked from commit e1a5e7562d53a8d2256f754714b06595bea72196)

[Bug tree-optimization/105431] ICE: SIGSEGV in powi_as_mults_1 (tree-ssa-math-opts.cc:1512) with -Ofast and __builtin_pow()

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105431

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:e41fa23451c965516a37282268231933fd948845

commit r10-10765-ge41fa23451c965516a37282268231933fd948845
Author: Richard Biener 
Date:   Fri Apr 29 08:45:48 2022 +0200

tree-optimization/105431 - another overflow in powi handling

This avoids undefined signed overflow when calling powi_as_mults_1.

2022-04-29  Richard Biener  

PR tree-optimization/105431
* tree-ssa-math-opts.c (powi_as_mults_1): Make n unsigned.
(powi_as_mults): Use absu_hwi.
(gimple_expand_builtin_powi): Remove now pointless n != -n
check.

(cherry picked from commit 44b09adb9bad99dd7e3017c5ecefed7f7c9a1590)

[Bug tree-optimization/105368] [10 Regression] ICE: SIGSEGV in powi_lookup_cost (tree-ssa-math-opts.cc:1441) with -Ofast and __builtin_powf()

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105368

--- Comment #10 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:ebe6ffee1aa2d819e4fbdf4130e054a33c274b38

commit r10-10764-gebe6ffee1aa2d819e4fbdf4130e054a33c274b38
Author: Richard Biener 
Date:   Mon Apr 25 10:55:21 2022 +0200

tree-optimization/105368 - avoid overflow in powi_cost

The following avoids undefined signed overflow when computing
the absolute of the exponent in powi_cost.

2022-04-25  Richard Biener  

PR tree-optimization/105368
* tree-ssa-math-opts.c (powi_cost): Use absu_hwi.

(cherry picked from commit f0e170f72f8bfaa2a64e1d09ebdfd48f917420f1)

[Bug rtl-optimization/105559] [10 Regression] -g and -O3 cause timeout since r12-156-g8d4c374c4419a875

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105559

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:6007449a1c3bd116e431fe53d4dfe2d1c67c1076

commit r10-10763-g6007449a1c3bd116e431fe53d4dfe2d1c67c1076
Author: Richard Biener 
Date:   Wed May 11 13:34:37 2022 +0200

rtl-optimization/105559 - avoid quadratic behavior in delete_insn_and_edges

When the insn to delete is a debug insn there's no point in figuring
out whether it might be the last real insn and thus we have to purge
dead edges.

2022-05-11  Richard Biener  

PR rtl-optimization/105559
* cfgrtl.c (delete_insn_and_edges): Only perform search to BB_END
for non-debug insns.

(cherry picked from commit 37a8220fa9188470c677abfef50c1b120c0b6c76)

[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", >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

[Bug ipa/105728] dead store to static var not optimized out

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728

--- Comment #3 from Richard Biener  ---
Btw, any such optimization would be prone to remove 'debug_cnt' in

void foo()
{
  static int debug_cnt = 0;
  debug_cnt++;
  .. stuff ..
}

because here nothing depends on debug_cnt.  For some printf-style
debugging that might be surprising.  It of course already happens for

void foo()
{
  static bool ever_reached = false;
  ever_reached = true;
}

[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.
	* 

[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506

--- Comment #3 from Brecht Sanders  
---
Created attachment 53046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53046=edit
ProcessMonitor filtered on occurrence of "cc1"

[Bug libgomp/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745

--- Comment #10 from Christoph Reiter  ---
lgtm

[Bug c++/105748] gcc ignores the pure attribute

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105748

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-05-27
   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
It works fine with the C frontend so I suspect PRE (which does the transform
there) is confused by the fact that g_value isn't marked as to not throwing.

const int g_value() __attribute__((pure,nothrow));
int bar(int n) {
int s = 0;
for (int i=0; i

[Bug libgomp/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-05-27
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Created attachment 53045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53045=edit
gcc13-pr105745.patch

GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is documented as:
/* Defined if gomp_aligned_alloc doesn't use fallback version
   and free can be used instead of gomp_aligned_free.  */
so the _aligned_malloc/_aligned_free pair doesn't satisfy that.

So my preference is this patch instead.

[Bug rtl-optimization/105747] Scheduler can take a long time on arm-linux sometimes

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105747

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.0

--- Comment #4 from Richard Biener  ---
Confirmed with a cross from x86_64:

 alias stmt walking :   2.47 ( 27%) 
 tree DSE   :   1.52 ( 17%)
 scheduling :   1.36 ( 15%) 
 TOTAL  :   9.15

so it's not only scheduling.  perf (release checking) shows:

Samples: 37K of event 'cycles', Event count (approx.): 41984911906  
Overhead   Samples  Command  Shared Object Symbol   
  26.20%  9765  cc1  cc1   [.] get_ref_base_and_extent
   4.37%  1635  cc1  cc1   [.] find_base_term
   3.75%  1392  cc1  cc1   [.] rank_for_schedule
   3.13%  1168  cc1  cc1   [.] wi::lshift_large
   2.52%   938  cc1  cc1   [.] canonize
   2.36%   876  cc1  cc1   [.] sd_lists_size
   2.27%   844  cc1  cc1   [.]
sd_find_dep_between_no_cache
   1.89%   701  cc1  cc1   [.]
operand_compare::operand_equal_p
   1.80%   671  cc1  cc1   [.] wi::mul_internal
   1.71%   637  cc1  cc1   [.]
simplify_context::simplify_plus_minus
   1.63%   613  cc1  cc1   [.] memrefs_conflict_p

note with a non-optimized compiler and checking enabled (but -fno-checking)
things are much slower.

[Bug ipa/105639] [12/13 Regression] ICE in propagate_controlled_uses, at ipa-prop.cc:4195 since r12-7936-gf6d65e803623c7ba

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105639

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:f571596f8cd8fbad34305b4bec1a813620e0cbf0

commit r13-798-gf571596f8cd8fbad34305b4bec1a813620e0cbf0
Author: Martin Jambor 
Date:   Fri May 27 13:05:40 2022 +0200

ipa: Check cst type when propagating controled uses info

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.

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.

[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 

specs question

[Iain Sandoe]

Hi.

My ‘downstream’ have a situation in which they make use of a directory outside 
of the configured GCC installation - and symlink from there to libraries in the 
actual install tree.

e.g.

/foo/bar/lib:
  libgfortran.dylib -> /gcc/install/path/lib/libgfortran.dylib

Now I want to find a way for them to add an embedded runpath that references 
/foo/bar/lib.

I could add a configure option, that does exactly this job - but then I’d have 
to back port that to every GCC version they are still supporting (not, perhaps, 
the end of the world but much better avoided).

So I was looking at using —with-specs= to add a link-time spec for this:

--with-specs='%{!nodefaultrpaths:%{!r:%:version-compare(>= 10.5 
mmacosx_version_min= -Wl,-rpath,/foo/bar/lib)}}}’

Which works, fine except for PCH jobs which it breaks because the presence of 
an option claimed by the linker causes a link job to be created, even though 
one is not required (similar issue have been seen before).

There is this:
 %{,S:X}  substitutes X, if processing a file which will use spec S.

so I could then do:

--with-specs=‘%{,???:%{!nodefaultrpaths:%{!r:%:version-compare(>= 10.5 
mmacosx_version_min= -Wl,-rpath,/foo/bar/lib)’

but, unfortunately, I cannot seem to figure out what ??? should be  [I tried 
‘l’ (link_spec) ‘link_command’ (*link_command)]

…JFTR also tried
  %{!.h:
   %{!,c-header:

——
any insight would be welcome, usually I muddle through with specs, but this one 
has me stumped.

thanks
Iain

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.

[Bug libstdc++/105671] [11/12/13 Regression] Unexplained "undefined reference" error

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-05-27
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Priority|P3  |P2

--- Comment #3 from Jonathan Wakely  ---
Since we can't add the export to the release branches now, the simplest fix
might be to mark that function always_inline.

[Bug c++/105749] New: Bogus maybe-unitialized when using std::optional, regex and sstream

[hi+gccbugs at yamlcoder dot me via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105749

Bug ID: 105749
   Summary: Bogus maybe-unitialized when using std::optional,
regex and sstream
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hi+gccbugs at yamlcoder dot me
  Target Milestone: ---

Created attachment 53044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53044=edit
t.ii reproducer

Compiling following with -Wall -Werror -Os produces bogus 
maybe-unitialized warning


/tmp/t.cpp: In function ‘void t(const string&)’:
/tmp/t.cpp:12:51: error: ‘*(int*)((char*) +
offsetof(std::optional,std::optional::.std::_Optional_base::))’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   12 | reqb << "Host: " << port.value_or(443) << "\r\n";



Attaching .ii (tar.gz due to attachment limit) file from 11.2.0, but it is also
reproducible on trunk in godbolt: https://godbolt.org/z/ha3vn61n9

Interesting that commenting unrelated parts or changing them slightly makes
warning go away.


#include 
#include 
#include 

void t(const std::string& i) {
const std::regex re("^$"); //removing this works

std::optional port(i.length() > 0 ?
std::make_optional(std::strtol("99", nullptr, 10)) : std::nullopt);

std::ostringstream reqb;
reqb << "GET /" << i << " HTTP/1.1" << "\r\n"; //removing this works
reqb << "Host: " << port.value_or(443) << "\r\n";
}