[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> After my patches for PR 96923  (and PR 100864), we get:
> 
> 
>   _22 = _16 > _17;
> ... (some dead statements that PHI-OPT adds due to match and simplify)
>   _8 = _16 >= _17;
>   _13 = _8 & _22;
> 
> But there is nothing which optimizes the above into just _22 (_16 > _17)
> which I find interesting ...

Now after the patch I have for  106164 we get:
  _13 = _16 > _17;

Which is what we expect.

Note phiopt still should do some cleanup because of match-and-simplify as we
get:
  _3 = _16 < _17;
  _7 = _16 < _17;
  _8 = _16 >= _17;
  _13 = _16 > _17;

Where _3, _7 and _8 are all unused, I have to figure out the best way of doing
that.

[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1

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

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

--- Comment #4 from Andrew Pinski  ---
This is the match.pd code:
(for bitop (bit_and bit_ior)
 (for cmp (tcc_comparison)
  (for ocmp (tcc_comparison)
   (for ncmp (tcc_comparison)
(simplify
 (bitop (cmp:c @0 @1) (ocmp @0 @1))
 (with {
#if GIMPLE
location_t loc = UNKNOWN_LOCATION;
#endif
tree t = combine_comparisons (loc,
  bitop == BIT_IOR_EXPR
   ? TRUTH_ORIF_EXPR : TRUTH_ANDIF_EXPR,
  cmp, ocmp,
  type, @0, @1);
  }
  (switch
   (if (GENERIC && t)
{t;})
   (if (t && CONSTANT_CLASS_P (t))
{t;})
   (if (t && TREE_CODE (t) == ncmp
/* Even though combine_comparisons should
   return this, this is to double check. */
&& operand_equal_p (TREE_OPERAND (t, 0), @0)
&& operand_equal_p (TREE_OPERAND (t, 1), @1))
(ncmp @0 @1)
   )
  )
 )
)
   )
  )
 )
)

I am not a fan of it though, I think we should change combine_comparisons to
return the comparison code or true/false or error out.
The loc is due to combine_comparisons building the tree rather than match. The
same is true of the whole checking of the result. I am going to test this fully
and see if there is anything I need to change (there might be some testcases
which need to be "improved").

Also the whole ncmp for loop is still another issue which is a genmatch change
to allow a non-name to be there but that is so so much harder to fix and there
is already a case like that too.

[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This is done by fold_range_test in fold-const.cc 
> 
> Actually no, it is fold_truth_andor_1. Anyways I am going to fix this one.

That is combine_comparisons.

[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-07-02
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> This is done by fold_range_test in fold-const.cc 

Actually no, it is fold_truth_andor_1. Anyways I am going to fix this one.

[Bug target/106165] incorrect result when using inlined asm implementation of floor() on i686

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
-fexcess-precision=standard (-std=c99 enables -fexcess-precision=standard) or
-mfpmath=sse fixes the issue.

This is not wrong code but rather the way x87 works for GCC.
GCC defaults to using the execess precision of x87 (80bits) and sometimes if
the floating point value is kept on the fpu stack, there is no rounding back to
64bits. And that is exactly what you are seeing here really.

Anyways this is a dup of bug 323.
The reason why it works for the non-inline floor case is because well there is
a rounding step that happens.

The reason why -fexcess-precision=standard works (it is only implemented for
the C front-end) is because there rounding steps are now explict in the IR and
will use the 80bit fpu and then force the rounding back.

The reason why -mfpmath=sse works is instead of using x87, GCC will use the sse
fpu implementation which is 64bit without excess precision.

This is kinda not a bug, just you not understanding fpu and execess precision.

*** This bug has been marked as a duplicate of bug 323 ***

[Bug middle-end/323] optimized code gives strange floating point results

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||xeioexception at gmail dot com

--- Comment #224 from Andrew Pinski  ---
*** Bug 106165 has been marked as a duplicate of this bug. ***

[Bug target/106165] incorrect result when using inlined asm implementation of floor() on i686

[xeioexception at gmail dot com via Gcc-bugs]

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

--- Comment #1 from xeioex  ---
TO fix the last confirmations

1) gcc -O2  minified_to_string_radix.i -o 507 -lm && ./507
1e+23.toString(36) = ga894a06ac8
ERROR expected "ga894a06abs"

2) gcc -O1  minified_to_string_radix.i -o 507 -lm && ./507
1e+23.toString(36) = ga894a06abs
OK

3) gcc -O1 -ffast-math minified_to_string_radix.i -o 507 -lm && ./507
1e+23.toString(36) = ga894a06abs
OK

4) gcc -O1 -fstrict-aliasing minified_to_string_radix.i -o 507 -lm && ./507
1e+23.toString(36) = ga894a06abs
OK 

5) removing inlined floor() fixed the issue

6) clang-6.0  -O2  minified_to_string_radix.i -o 507 -lm && ./507
1e+23.toString(36) = ga894a06abs

[Bug c++/106166] New: Improve diagnostic for explicit constructor

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

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

Bug ID: 106166
   Summary: Improve diagnostic for explicit constructor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This is not valid code:

struct E { explicit E(int); };
void
g ()
{
  E e = 1; // error
}

but we only say
q1.C:5:9: error: conversion from ‘int’ to non-scalar type ‘E’ requested
5 |   E e = 1; // error

It would be nice to explain that an explicit constructor is not a candidate in
copy-initialization context.

[Bug c++/91429] Conditional explicit not respected with out-of-line definition

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
Fixed in r11-371-g661232da72d29f.

[Bug c/106165] New: incorrect result when using inlined asm implementation of floor() on i686

[xeioexception at gmail dot com via Gcc-bugs]

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

Bug ID: 106165
   Summary: incorrect result when using inlined asm implementation
of floor() on i686
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xeioexception at gmail dot com
  Target Milestone: ---

$ gcc-11 -v -save-temps -O2 minified_to_string_radix.i -o 507 -lm
Using built-in specs.   
COLLECT_GCC=gcc-11  
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/11/lto-wrapper  
Target: i686-linux-gnu  
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/READM
E.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-11 -
-program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threa
ds=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdc
xx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos
-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-targets=all --enable-multiarch --disable-werror --disabl
e-cet --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=i686
-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix 
Supported LTO compression algorithms: zlib zstd 
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic'
'-march=i686' '-dumpdir' '507-'
 /usr/lib/gcc/i686-linux-gnu/11/cc1 -E -quiet -v -imultiarch i386-linux-gnu
507_mini.c -mtune=generic -march=i686 -O2 -fpch-preprocess -
fasynchronous-unwind-tables -fstack-protector-strong -Wformat -Wformat-security
-o 507-507_mini.i   
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"  
ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/11/include-fixed"   
ignoring nonexistent directory
"/usr/lib/gcc/i686-linux-gnu/11/../../../../i686-linux-gnu/include" 
#include "..." search starts here: 
#include <...> search starts here: 
 /usr/lib/gcc/i686-linux-gnu/11/include
 /usr/local/include
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic'
'-march=i686' '-dumpdir' '507-'
 /usr/lib/gcc/i686-linux-gnu/11/cc1 -fpreprocessed 507-507_mini.i -quiet
-dumpdir 507- -dumpbase 507_mini.c -dumpbase-ext .c -mtune=generic -march=i686
-O2 -version -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -o 507-507_mini.s
GNU C17 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (i686-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 11.1.0-1ubuntu1~18.04.1) version 11.1.0 (i686-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 81b68deb607ea376c8bc5126cafbdd31
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic'
'-march=i686' '-dumpdir' '507-'
 as -v --32 -o 507-507_mini.o 507-507_mini.s
GNU assembler version 2.30 (i686-linux-gnu) using BFD version (GNU Binutils for
Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/11/:/usr/lib/gcc/i686-linux-gnu/11/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/11/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/11/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' '507' '-mtune=generic'
'-march=i686' '-dumpdir' '507.'
 /usr/lib/gcc/i686-linux-gnu/11/collect2 -plugin
/usr/lib/gcc/i686-linux-gnu/11/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/i686-linux-gnu/11/lto-wrapper
-plugin-opt=-fresolution=507.res 

Re: Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

[Jason Merrill via Gcc-patches]

On 7/1/22 18:05, Lewis Hyatt wrote:

On Fri, Jul 1, 2022 at 3:59 PM Jason Merrill  wrote:


On 6/29/22 12:59, Jason Merrill wrote:

On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote:

Hello-

https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49

Would a C++ maintainer have some time to take a look at this patch
please? I feel like the PR is still worth resolving. If this doesn't
seem like a good way, I am happy to try another -- would really
appreciate any feedback. Thanks!


Thanks for your persistence, I'll take a look now.

Incidentally, when pinging it's often useful to ping someone from
MAINTAINERS directly, as well as the list.  I think your last ping got
eaten by some trouble Red Hat email was having at the time.

The cp_token_is_module_directive cleanup is OK.


Thank you very much for the advice and for going through the patch, I
really appreciate it. I went ahead and pushed the small cleanup patch.
I have responses to your comments on the main patch below too.




+  bool skip_this_pragma;


This member seems to be equivalent to
   in_pragma && !should_output_pragmas ()
Maybe it could be a member function instead of a data member?



Yeah, makes sense, although I hope that by implementing your
suggestion below regarding rewinding the tokens for preprocessing,
then this can be removed anyway.


More soon.


Looks good, just a few minor comments:


+  PD_KIND_INVALID,
+  PD_KIND_PUSH,
+  PD_KIND_POP,
+  PD_KIND_IGNORED_ATTRIBUTES,
+  PD_KIND_DIAGNOSTIC,


The PD_KIND_ prefix seems unnecessary for a scoped enum.



Sure, will shorten it to PK_ instead.


+/* When preprocessing only, pragma_lex() is not available, so obtain the tokens
+   directly from libcpp.  */
+static void
+pragma_diagnostic_lex_pp (pragma_diagnostic_data *result)


Hmm, we could make a temporary lexer, but I guess this is short enough
that the duplication is OK.


I see. It would look like a version of pragma_lex() (the one in
c-parser.cc) which took a c_parser* argument so it wouldn't need to
use the global the_parser.


Or creates the_parser itself and feeds it tokens somewhat like 
cp_parser_handle_statement_omp_attributes.



I didn't consider this because I was
starting from Manuel's prototype patch on the PR
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c10), which was
doing the parsing in libcpp itself. Perhaps it would make sense to
move to this approach in the future, if it became necessary sometime
to lex some other pragmas during preprocessing?


Sure.


+/* Similar, for the portion of a diagnostic pragma that was parsed
+   internally and so not seen by our token streamer.  */


Can we rewind after parsing so that the token streamer sees it?



Oh that's an interesting idea. It would avoid some potential issues.
For instance, I have another patch submitted to fix PR55971
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971#c8), which is that
you can't put raw strings containing newlines into a preprocessing
directive. It occurs to me now, once that's applied, then I think a
#pragma GCC diagnostic with such a raw string (useless though it would
be) would not get output correctly by gcc -E with this current patch's
approach. An edge case certainly, but would be nice to get it right
also, and your approach would automatically handle it. I'm going to
explore this now and then follow up with a new version of the patch.


+  if (early && arg)
+{
+  /* This warning is needed because of PR71603 - popping the diagnostic
+state does not currently reset changes to option arguments, only
+changes to the option dispositions.  */
+  warning_at (data.loc_option, OPT_Wpragmas,
+ "a diagnostic pragma attempting to modify a preprocessor"
+ " option argument may not work as expected");
+}


Maybe only warn if we subsequently see a pop?



Right, that makes sense. Changing the option does work just fine until
you try to pop it. But actually this warning was kinda an
afterthought, now I just checked and at the time I wrote it, there was
only one option it could possibly apply to, since it needs to be an
option that's both for libcpp, and taking an argument, which was
-Wnormalized=. In the meantime one more has been added, -Wbidi-chars=.
Rather than add more complicated logic to remember to warn on pop for
these 2 options only, feels like maybe it would be better to either
just fix PR71603 (which I can work on sometime), or add this warning
for all options, not just libcpp options, which I guess means it
should go inside the implementation of pop... So in either case feels
like it's not really relevant to this patch and I'd propose just to
remove it for now, and then address it subsequently?


Sounds good.


+/* Handle #pragma gcc diagnostic, which needs to be done during preprocessing
+   for the case of preprocessing-related diagnostics.  */
+static void

[Bug tree-optimization/106164] (a > b) & (a >= b) does not get optimized until reassoc1

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

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

--- Comment #1 from Andrew Pinski  ---
This is done by fold_range_test in fold-const.cc 

Re: [PATCH]middle-end Add optimized float addsub without needing VEC_PERM_EXPR.

[Jeff Law via Gcc-patches]

On 6/20/2022 5:56 AM, Richard Biener via Gcc-patches wrote:



Note one option would be to emit a multiply with { 1, -1, 1, -1 } on
GIMPLE where then targets could opt-in to handle this via a DFmode
negate via a combine pattern?  Not sure if this can be even done
starting from the vec-perm RTL IL.

FWIW, FP multiply is the same cost as FP add/sub on our target.


I fear whether (neg:V2DF (subreg:V2DF (reg:V4SF))) is a good idea
will heavily depend on the target CPU (not only the ISA).  For RISC-V
for example I think the DF lanes do not overlap with two SF lanes
(so same with gcn I think).
Absolutely.  I've regularly seen introduction of subregs like that 
ultimately result in the SUBREG_REG object getting dumped into memory 
rather than be allocated into a register.  It could well be a problem 
with our port, I haven't started chasing it down yet.


One such case where that came up recently was the addition of something 
like this to simplify-rtx.  Basically in some cases we can turn a 
VEC_SELECT into a SUBREG, so I had this little hack in simplify-rtx that 
I was playing with:

+  /* If we have a VEC_SELECT of a SUBREG try to change the SUBREG so
+    that we eliminate the VEC_SELECT.  */
+  if (GET_CODE (op0) == SUBREG
+ && subreg_lowpart_p (op0)
+ && VECTOR_MODE_P (GET_MODE (op0))
+ && GET_MODE_INNER (GET_MODE (op0)) == mode
+ && XVECLEN (trueop1, 0) == 1
+ && CONST_INT_P (XVECEXP (trueop1, 0, 0)))
+   {
+ return simplify_gen_subreg (mode, SUBREG_REG (op0), GET_MODE 
(SUBREG_REG (op0)), INTVAL (XVECEXP (trueop1, 0, 0)) * 8);

+   }


Seemed like a no-brainer win, but in reality it made things worse pretty 
consistently.


jeff

Re: [PATCH]middle-end Add optimized float addsub without needing VEC_PERM_EXPR.

[Jeff Law via Gcc-patches]

On 6/17/2022 2:33 PM, Andrew Pinski via Gcc-patches wrote:

On Thu, Jun 16, 2022 at 3:59 AM Tamar Christina via Gcc-patches
 wrote:

Hi All,

For IEEE 754 floating point formats we can replace a sequence of alternative
+/- with fneg of a wider type followed by an fadd.  This eliminated the need for
using a permutation.  This patch adds a math.pd rule to recognize and do this
rewriting.

I don't think this is correct. You don't check the format of the
floating point to make sure this is valid (e.g. REAL_MODE_FORMAT's
signbit_rw/signbit_ro field).
Also would just be better if you do the xor in integer mode (using
signbit_rw field for the correct bit)?
And then making sure the target optimizes the xor to the neg
instruction when needed?
Whether or not the xor trick is better or not would be highly target 
dependent.  That seems like it's better left for expansion to figure out 
since we have target costing information at that point.


Jeff

Re: DSE patch RFA: Don't delete trapping insn

[Jeff Law via Gcc-patches]

On 7/1/2022 4:04 PM, Ian Lance Taylor via Gcc-patches wrote:

The DSE pass can delete a dead store even if the instruction can trap.
That is incorrect when using -fnon-call-exceptions
-fno-delete-dead-exceptions.  This led to a bug report against gccgo:
https://go.dev/issue/53012.  However, the bug is not specific to Go.

This patch fixes the problem in a simple way, and includes a C++
testcase.  Bootstrapped and ran C, C++, and Go tests on
x86_64-pc-linux-gnu.

OK for mainline?

OK
jeff

Go patch committe: Use correct init order for multi-value init

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend uses the correct initialization order
for code like

var a = c
var b, c = x.(bool)

The global c is initialized by the preinit of b, but we were missing a
dependency of c on b, so a would be initialized to the zero value of c
rather than the correct value.

Simply adding the dependency of c on b didn't work because the preinit
of b refers to c, so that appeared circular.  So this patch changes
the init order to skip dependencies that only appear on the left hand
side of assignments in preinit blocks.

Doing that didn't work because the write barrier pass can transform "a
= b" into code like "gcWriteBarrier(, b)" that is not obviously a
simple assigment.  So this patch moves the collection of dependencies
to just after lowering, before the write barriers are inserted.

Making those changes permit relaxing the requirement that we don't
warn about self-dependency in preinit blocks, so now we correctly warn
for

var a, b any = b.(bool)

The test case is https://go.dev/cl/415238.

This fixes https://go.dev/issue/53619.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
23361df71a68478dde7c4aa516ba69f199556a2c
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 65f64e0fbfb..7b1d3011fff 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-ac438edc5335f69c95df9342f43712ad2f61ad66
+6479d5976c5d848ec6f5843041275723a6b0
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/go.cc b/gcc/go/gofrontend/go.cc
index 404cb124549..1512770af29 100644
--- a/gcc/go/gofrontend/go.cc
+++ b/gcc/go/gofrontend/go.cc
@@ -146,6 +146,9 @@ go_parse_input_files(const char** filenames, unsigned int 
filename_count,
   if (only_check_syntax)
 return;
 
+  // Record global variable initializer dependencies.
+  ::gogo->record_global_init_refs();
+
   // Do simple deadcode elimination.
   ::gogo->remove_deadcode();
 
diff --git a/gcc/go/gofrontend/gogo.cc b/gcc/go/gofrontend/gogo.cc
index 67b91fab4ca..9197eef3e38 100644
--- a/gcc/go/gofrontend/gogo.cc
+++ b/gcc/go/gofrontend/gogo.cc
@@ -1086,8 +1086,8 @@ class Find_vars : public Traverse
 
  public:
   Find_vars()
-: Traverse(traverse_expressions),
-  vars_(), seen_objects_()
+: Traverse(traverse_expressions | traverse_statements),
+  vars_(), seen_objects_(), lhs_is_ref_(false)
   { }
 
   // An iterator through the variables found, after the traversal.
@@ -1104,11 +1104,16 @@ class Find_vars : public Traverse
   int
   expression(Expression**);
 
+  int
+  statement(Block*, size_t* index, Statement*);
+
  private:
   // Accumulated variables.
   Vars vars_;
   // Objects we have already seen.
   Seen_objects seen_objects_;
+  // Whether an assignment to a variable counts as a reference.
+  bool lhs_is_ref_;
 };
 
 // Collect global variables referenced by EXPR.  Look through function
@@ -1164,7 +1169,11 @@ Find_vars::expression(Expression** pexpr)
  if (ins.second)
{
  // This is the first time we have seen this name.
- if (f->func_value()->block()->traverse(this) == TRAVERSE_EXIT)
+ bool hold = this->lhs_is_ref_;
+ this->lhs_is_ref_ = true;
+ int r = f->func_value()->block()->traverse(this);
+ this->lhs_is_ref_ = hold;
+ if (r == TRAVERSE_EXIT)
return TRAVERSE_EXIT;
}
}
@@ -1192,6 +1201,29 @@ Find_vars::expression(Expression** pexpr)
   return TRAVERSE_CONTINUE;
 }
 
+// Check a statement while searching for variables.  This is where we
+// skip variables on the left hand side of assigments if appropriate.
+
+int
+Find_vars::statement(Block*, size_t*, Statement* s)
+{
+  if (this->lhs_is_ref_)
+return TRAVERSE_CONTINUE;
+  Assignment_statement* as = s->assignment_statement();
+  if (as == NULL)
+return TRAVERSE_CONTINUE;
+
+  // Only traverse subexpressions of the LHS.
+  if (as->lhs()->traverse_subexpressions(this) == TRAVERSE_EXIT)
+return TRAVERSE_EXIT;
+
+  Expression* rhs = as->rhs();
+  if (Expression::traverse(, this) == TRAVERSE_EXIT)
+return TRAVERSE_EXIT;
+
+  return TRAVERSE_SKIP_COMPONENTS;
+}
+
 // Return true if EXPR, PREINIT, or DEP refers to VAR.
 
 static bool
@@ -1230,11 +1262,11 @@ class Var_init
 {
  public:
   Var_init()
-: var_(NULL), init_(NULL), refs_(NULL), dep_count_(0)
+: var_(NULL), init_(NULL), dep_count_(0)
   { }
 
   Var_init(Named_object* var, Bstatement* init)
-: var_(var), init_(init), refs_(NULL), dep_count_(0)
+: var_(var), init_(init), dep_count_(0)
   { }
 
   // Return the variable.
@@ -1247,19 +1279,6 @@ class Var_init
   init() const
   { return this->init_; }
 
-  // Add a reference.
-  void
-  add_ref(Named_object* var);
-
-  // The variables which this variable's initializers refer to.
-  const std::vector*
-  refs()
-  { return this->refs_; }
-
- 

Re: [PATCH] c++: generic targs and identity substitution [PR105956]

[Jason Merrill via Gcc-patches]

On 6/29/22 13:42, Patrick Palka wrote:

In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic
DECL_TI_ARGS corresponds to an identity mapping of the given arguments,
and hence its safe to always elide such substitution.  But this PR
demonstrates that such a substitution isn't always the identity mapping,
in particular when there's an ARGUMENT_PACK_SELECT argument, which gets
handled specially during substitution:

   * when substituting an APS into a template parameter, we strip the
 APS to its underlying argument;
   * and when substituting an APS into a pack expansion, we strip the
 APS to its underlying argument pack.


Ah, right.  For instance, in variadic96.C we have

10  template < typename... T >
11  struct derived
12: public base< T, derived< T... > >...

so when substituting into the base-specifier, we're approaching it from 
the outside in, so when we get to the inner T... we need some way to 
find the T pack again.  It might be possible to remove the need for APS 
by substituting inner pack expansions before outer ones, which could 
improve worst-case complexity, but I don't know how relevant that is in 
real code; I imagine most inner pack expansions are as simple as this one.



In this testcase, when expanding the pack expansion pattern (idx + Ns)...
with Ns={0,1}, we specialize idx twice, first with Ns=APS<0,{0,1}> and
then Ns=APS<1,{0,1}>.  The DECL_TI_ARGS of idx are the generic template
arguments of the enclosing class template impl, so before r13-1045,
we'd substitute into its DECL_TI_ARGS which gave Ns={0,1} as desired.
But after r13-1045, we elide this substitution and end up attempting to
hash the original Ns argument, an APS, which ICEs.

So this patch partially reverts this part of r13-1045.  I considered
using preserve_args in this case instead, but that'd break the
static_assert in the testcase because preserve_args always strips APS to
its underlying argument, but here we want to strip it to its underlying
argument pack, so we'd incorrectly end up forming the specializations
impl<0>::idx and impl<1>::idx instead of impl<0,1>::idx.

Although we can't elide the substitution into DECL_TI_ARGS in light of
ARGUMENT_PACK_SELECT, it should still be safe to elide template argument
coercion in the case of a non-template decl, which this patch preserves.

It's unfortunate that we need to remove this optimization just because
it doesn't hold for one special tree code.  So this patch implements a
heuristic in tsubst_template_args to avoid allocating a new TREE_VEC if
the substituted elements are identical to those of a level from ARGS.
It turns out that about 30% of all calls to tsubst_template_args benefit
from this optimization, and it reduces memory usage by about 1.5% for
e.g. stdc++.h (relative to r13-1045).  (This is the maybe_reuse stuff,
the rest of the changes to tsubst_template_args are just drive-by
cleanups.)

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  Patch generated with -w to ignore noisy whitespace changes.

PR c++/105956

gcc/cp/ChangeLog:

* pt.cc (tsubst_template_args): Move variable declarations
closer to their first use.  Replace 'orig_t' with 'r'.  Rename
'need_new' to 'const_subst_p'.  Heuristically detect if the
substituted elements are identical to that of a level from
'args' and avoid allocating a new TREE_VEC if so.
(tsubst_decl) : Revert
r13-1045-gcb7fd1ea85feea change for avoiding substitution into
DECL_TI_ARGS, but still avoid coercion in this case.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic183.C: New test.
---
  gcc/cp/pt.cc | 113 ++-
  gcc/testsuite/g++.dg/cpp0x/variadic183.C |  14 +++
  2 files changed, 85 insertions(+), 42 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic183.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 8672da123f4..7898834faa6 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
   Fixed by: C++20 modules.  */
  
  #include "config.h"

+#define INCLUDE_ALGORITHM // for std::equal
  #include "system.h"
  #include "coretypes.h"
  #include "cp-tree.h"
@@ -13544,17 +13545,22 @@ tsubst_argument_pack (tree orig_arg, tree args, 
tsubst_flags_t complain,
  tree
  tsubst_template_args (tree t, tree args, tsubst_flags_t complain, tree 
in_decl)
  {
-  tree orig_t = t;
-  int len, need_new = 0, i, expanded_len_adjust = 0, out;
-  tree *elts;
-
if (t == error_mark_node)
  return error_mark_node;
  
-  len = TREE_VEC_LENGTH (t);

-  elts = XALLOCAVEC (tree, len);
+  const int len = TREE_VEC_LENGTH (t);
+  tree *elts = XALLOCAVEC (tree, len);
+  int expanded_len_adjust = 0;
  
-  for (i = 0; i < len; i++)

+  /* True iff no element of T was changed by the substitution.  */
+  bool const_subst_p = true;
+
+  /* If MAYBE_REUSE is non-NULL, as an 

[Bug tree-optimization/106163] generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions

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

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

--- Comment #2 from Andrew Pinski  ---
Most likely the code here needs to be changed slightly.
  fprintf_indent (f, indent,
  "if (TREE_SIDE_EFFECTS (captures[%d]))\n",
  i);


Or maybe the code which sets TREE_SIDE_EFFECTS should be fixed ...

[Bug tree-optimization/106164] New: (a > b) & (a >= b) does not get optimized until reassoc1

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

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

Bug ID: 106164
   Summary: (a > b) & (a >= b) does not get optimized until
reassoc1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 105903
  Target Milestone: ---

Take:
```
_Bool f(int a, int b)
{
  _Bool c = a > b;
  _Bool d = a >= b;
  return c & d;
}
```
This does not get optimized until reassoc1.
While:
```
_Bool f(int a, int b)
{
  return (a > b) & (a >= b);
}
```
Gets optimized during folding (not by match though), I have not looked into
what does it though.

I noticed this while working on PR 105903 as there is not a reassoc pass after
phiopt4 so nothing optimizes.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105903
[Bug 105903] Missed optimization for __synth3way

gcc-11-20220701 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220701 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220701/
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 7296a7c9aa35a9731a73e33c29f6bbc488a0c837

You'll find:

 gcc-11-20220701.tar.xz   Complete GCC

  SHA256=23959ffa9dd52d03c04e6522588cf5ad70d144547755ecf2e7a6fab8c58594ed
  SHA1=2ac73375d876fa8daecc56e6c67c0e4fddb18ade

Diffs from 11-20220624 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 tree-optimization/106163] generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions

[ian at airs dot com via Gcc-bugs]

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

--- Comment #1 from Ian Lance Taylor  ---
This was originally reported against gccgo at https://go.dev/issue/53019.

[Bug tree-optimization/106163] New: generic-match does not honor -fnon-call-exceptions -fno-delete-dead-exceptions

[ian at airs dot com via Gcc-bugs]

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

Bug ID: 106163
   Summary: generic-match does not honor -fnon-call-exceptions
-fno-delete-dead-exceptions
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

When using -fnon-call-exceptions -fno-delete-dead-exceptions memory operations
that are not marked TREE_THIS_NOTRAP should not be removed from the execution
path.  However, the generic_simplify function, at least, does not honor this.

This test case, when compiled with -fnon-call-exceptions
-fno-delete-dead-exceptions, should exit with a zero status.  However, it
currently fails, because "i = *p ^ *p;" is simplified to "i = 0;".

// { dg-do run { target { i?86-*-linux* i?86-*-gnu* x86_64-*-linux* } } }
// { dg-additional-options "-fexceptions -fnon-call-exceptions
-fno-delete-dead-exceptions" }

#include 
#include 
#include 

static void
sighandler (int signo, siginfo_t* si, void* uc)
{
  throw (5);
}

struct S { void *p1, *p2; };

struct S v;

__attribute__ ((noinline))
int
dosegv ()
{
  int *p = 0;
  int i __attribute__((unused)) = 0;
  i = *p ^ *p;
  return 0;
}

int main ()
{
  struct sigaction sa;

  memset (, 0, sizeof sa);
  sa.sa_sigaction = sighandler;
  sigaction (SIGSEGV, , NULL);
  sigaction (SIGBUS, , NULL);

  try {
dosegv ();
  }
  catch (int x) {
return (x != 5);
  }

  return 1;
}

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

--- Comment #5 from Andrew Pinski  ---
After my patches for PR 96923  (and PR 100864), we get:


  _22 = _16 > _17;
... (some dead statements that PHI-OPT adds due to match and simplify)
  _8 = _16 >= _17;
  _13 = _8 & _22;

But there is nothing which optimizes the above into just _22 (_16 > _17) which
I find interesting ...

Re: Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

[Lewis Hyatt via Gcc-patches]

On Fri, Jul 1, 2022 at 3:59 PM Jason Merrill  wrote:
>
> On 6/29/22 12:59, Jason Merrill wrote:
> > On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote:
> >> Hello-
> >>
> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49
> >>
> >> Would a C++ maintainer have some time to take a look at this patch
> >> please? I feel like the PR is still worth resolving. If this doesn't
> >> seem like a good way, I am happy to try another -- would really
> >> appreciate any feedback. Thanks!
> >
> > Thanks for your persistence, I'll take a look now.
> >
> > Incidentally, when pinging it's often useful to ping someone from
> > MAINTAINERS directly, as well as the list.  I think your last ping got
> > eaten by some trouble Red Hat email was having at the time.
> >
> > The cp_token_is_module_directive cleanup is OK.

Thank you very much for the advice and for going through the patch, I
really appreciate it. I went ahead and pushed the small cleanup patch.
I have responses to your comments on the main patch below too.

> >
> >> +  bool skip_this_pragma;
> >
> > This member seems to be equivalent to
> >   in_pragma && !should_output_pragmas ()
> > Maybe it could be a member function instead of a data member?
> >

Yeah, makes sense, although I hope that by implementing your
suggestion below regarding rewinding the tokens for preprocessing,
then this can be removed anyway.

> > More soon.
>
> Looks good, just a few minor comments:
>
> > +  PD_KIND_INVALID,
> > +  PD_KIND_PUSH,
> > +  PD_KIND_POP,
> > +  PD_KIND_IGNORED_ATTRIBUTES,
> > +  PD_KIND_DIAGNOSTIC,
>
> The PD_KIND_ prefix seems unnecessary for a scoped enum.
>

Sure, will shorten it to PK_ instead.

> > +/* When preprocessing only, pragma_lex() is not available, so obtain the 
> > tokens
> > +   directly from libcpp.  */
> > +static void
> > +pragma_diagnostic_lex_pp (pragma_diagnostic_data *result)
>
> Hmm, we could make a temporary lexer, but I guess this is short enough
> that the duplication is OK.
>

I see. It would look like a version of pragma_lex() (the one in
c-parser.cc) which took a c_parser* argument so it wouldn't need to
use the global the_parser. I didn't consider this because I was
starting from Manuel's prototype patch on the PR
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c10), which was
doing the parsing in libcpp itself. Perhaps it would make sense to
move to this approach in the future, if it became necessary sometime
to lex some other pragmas during preprocessing?

> > +/* Similar, for the portion of a diagnostic pragma that was parsed
> > +   internally and so not seen by our token streamer.  */
>
> Can we rewind after parsing so that the token streamer sees it?
>

Oh that's an interesting idea. It would avoid some potential issues.
For instance, I have another patch submitted to fix PR55971
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971#c8), which is that
you can't put raw strings containing newlines into a preprocessing
directive. It occurs to me now, once that's applied, then I think a
#pragma GCC diagnostic with such a raw string (useless though it would
be) would not get output correctly by gcc -E with this current patch's
approach. An edge case certainly, but would be nice to get it right
also, and your approach would automatically handle it. I'm going to
explore this now and then follow up with a new version of the patch.

> > +  if (early && arg)
> > +{
> > +  /* This warning is needed because of PR71603 - popping the diagnostic
> > +state does not currently reset changes to option arguments, only
> > +changes to the option dispositions.  */
> > +  warning_at (data.loc_option, OPT_Wpragmas,
> > + "a diagnostic pragma attempting to modify a preprocessor"
> > + " option argument may not work as expected");
> > +}
>
> Maybe only warn if we subsequently see a pop?
>

Right, that makes sense. Changing the option does work just fine until
you try to pop it. But actually this warning was kinda an
afterthought, now I just checked and at the time I wrote it, there was
only one option it could possibly apply to, since it needs to be an
option that's both for libcpp, and taking an argument, which was
-Wnormalized=. In the meantime one more has been added, -Wbidi-chars=.
Rather than add more complicated logic to remember to warn on pop for
these 2 options only, feels like maybe it would be better to either
just fix PR71603 (which I can work on sometime), or add this warning
for all options, not just libcpp options, which I guess means it
should go inside the implementation of pop... So in either case feels
like it's not really relevant to this patch and I'd propose just to
remove it for now, and then address it subsequently?

> > +/* Handle #pragma gcc diagnostic, which needs to be done during 
> > preprocessing
> > +   for the case of preprocessing-related diagnostics.  */
> > 

DSE patch RFA: Don't delete trapping insn

[Ian Lance Taylor via Gcc-patches]

The DSE pass can delete a dead store even if the instruction can trap.
That is incorrect when using -fnon-call-exceptions
-fno-delete-dead-exceptions.  This led to a bug report against gccgo:
https://go.dev/issue/53012.  However, the bug is not specific to Go.

This patch fixes the problem in a simple way, and includes a C++
testcase.  Bootstrapped and ran C, C++, and Go tests on
x86_64-pc-linux-gnu.

OK for mainline?

Ian
From bae426745756896ec0ea27c9e12469c53b88d538 Mon Sep 17 00:00:00 2001
From: Ian Lance Taylor 
Date: Fri, 1 Jul 2022 14:51:45 -0700
Subject: [PATCH] tree-optimization: only DSE trapping insn if
 -fdelete-dead-exceptions

gcc/ChangeLog:

* tree-ssa-dse.cc (dse_optimize_stmt): Only delete a trapping
statement if -fdelete-dead-exceptions.

gcc/testsuite/ChangeLog:

* g++.dg/torture/except-1.C: New test.
---
 gcc/testsuite/g++.dg/torture/except-1.C | 44 +
 gcc/tree-ssa-dse.cc |  3 +-
 2 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/except-1.C

diff --git a/gcc/testsuite/g++.dg/torture/except-1.C 
b/gcc/testsuite/g++.dg/torture/except-1.C
new file mode 100644
index 000..7050a33cc27
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/except-1.C
@@ -0,0 +1,44 @@
+// { dg-do run { target { i?86-*-linux* i?86-*-gnu* x86_64-*-linux* } } }
+// { dg-additional-options "-fexceptions -fnon-call-exceptions 
-fno-delete-dead-exceptions" }
+
+#include 
+#include 
+#include 
+
+static void
+sighandler (int signo, siginfo_t* si, void* uc)
+{
+  throw (5);
+}
+
+struct S { void *p1, *p2; };
+
+struct S v;
+
+__attribute__ ((noinline))
+int
+dosegv ()
+{
+  struct S *p = 0;
+  struct S s __attribute__((unused)) = *p;
+  return 0;
+}
+
+int main ()
+{
+  struct sigaction sa;
+
+  memset (, 0, sizeof sa);
+  sa.sa_sigaction = sighandler;
+  sigaction (SIGSEGV, , NULL);
+  sigaction (SIGBUS, , NULL);
+
+  try {
+dosegv ();
+  }
+  catch (int x) {
+return (x != 5);
+  }
+
+  return 1;
+}
diff --git a/gcc/tree-ssa-dse.cc b/gcc/tree-ssa-dse.cc
index 62efafe384d..8d1739a4510 100644
--- a/gcc/tree-ssa-dse.cc
+++ b/gcc/tree-ssa-dse.cc
@@ -1463,7 +1463,8 @@ dse_optimize_stmt (function *fun, gimple_stmt_iterator 
*gsi, sbitmap live_bytes)
   gimple_call_set_lhs (stmt, NULL_TREE);
   update_stmt (stmt);
 }
-  else
+  else if (!stmt_could_throw_p (fun, stmt)
+  || fun->can_delete_dead_exceptions)
 delete_dead_or_redundant_assignment (gsi, "dead", need_eh_cleanup,
 need_ab_cleanup);
 }
-- 
2.37.0.rc0.161.g10f37bed90-goog

[Bug tree-optimization/105903] Missed optimization for __synth3way

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 53237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53237=edit
testcase

Even though it was included in comment #0, I am attaching it as it easier to
figure out what the testcase was.

[committed] libstdc++: Add missing prerequisite to generated header [PR106162]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.
This should be backported too.

-- >8 --

The ${host_builddir}/largefile-config.h header can't be written until
its parent directory has been created, so it needs to have the creation
of that directory as a prerequisite.

libstdc++-v3/ChangeLog:

PR libstdc++/106162
* include/Makefile.am (largefile-config.h): Add
stamp-${host_alias} prerequisite.
* include/Makefile.in: Regenerate.
---
 libstdc++-v3/include/Makefile.am | 2 +-
 libstdc++-v3/include/Makefile.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index b46def7ff9f..069a16ec769 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1286,7 +1286,7 @@ stamp-float128:
 endif
 
 # This header is not installed, it's only used to build libstdc++ itself.
-${host_builddir}/largefile-config.h: ${CONFIG_HEADER}
+${host_builddir}/largefile-config.h: ${CONFIG_HEADER} stamp-${host_alias}
@rm -f $@.tmp
@-grep 'define _DARWIN_USE_64_BIT_INODE' ${CONFIG_HEADER} >> $@.tmp
@-grep 'define _FILE_OFFSET_BITS' ${CONFIG_HEADER} >> $@.tmp
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index f844008a7c5..36eff73139d 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -1780,7 +1780,7 @@ stamp-host: ${host_headers} ${bits_host_headers} 
${ext_host_headers} ${host_head
 @ENABLE_FLOAT128_FALSE@echo 'undef _GLIBCXX_USE_FLOAT128' > 
stamp-float128
 
 # This header is not installed, it's only used to build libstdc++ itself.
-${host_builddir}/largefile-config.h: ${CONFIG_HEADER}
+${host_builddir}/largefile-config.h: ${CONFIG_HEADER} stamp-${host_alias}
@rm -f $@.tmp
@-grep 'define _DARWIN_USE_64_BIT_INODE' ${CONFIG_HEADER} >> $@.tmp
@-grep 'define _FILE_OFFSET_BITS' ${CONFIG_HEADER} >> $@.tmp
-- 
2.36.1

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.5

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

--- Comment #8 from Jonathan Wakely  ---
Fixed on trunk, but worth backporting to all branches.

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

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

https://gcc.gnu.org/g:8a6ee426c2be3bd4359520e02c00ec60cac2fece

commit r13-1400-g8a6ee426c2be3bd4359520e02c00ec60cac2fece
Author: Jonathan Wakely 
Date:   Fri Jul 1 22:23:43 2022 +0100

libstdc++: Add missing prerequisite to generated header [PR106162]

The ${host_builddir}/largefile-config.h header can't be written until
its parent directory has been created, so it needs to have the creation
of that directory as a prerequisite.

libstdc++-v3/ChangeLog:

PR libstdc++/106162
* include/Makefile.am (largefile-config.h): Add
stamp-${host_alias} prerequisite.
* include/Makefile.in: Regenerate.

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

--- Comment #6 from Sergei Trofimovich  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Sergei Trofimovich from comment #0)
> > There is a race condition when (I speculate) libstdcv++v3 is built in
> > parallel from different 'make' processes. Perhaps for c++98 | c++11 | x++17
> > instances?
> 
> There are no such instances. It is built separately for each multilib, but
> each of those has its own $host_builddir

Aha, TIL!

> Are you 100% sure you didn't actually run multiple make processes yourself,
> e.g by using & instead of && in a shell command?

I was running it from a standard build script. Should be just 'make -j16 -l16'
(with a small caveat: make is built with --shuffle support to reorder what what
is allowed to expose missing depends:
https://savannah.gnu.org/bugs/index.php?62100).

(In reply to Jonathan Wakely from comment #5)
> Created attachment 53236 [details]
> Add missing prerequisite to generated header
> 
> I'm testing this.

Thank you! I'll also give it a go locally and will complain if it fails in a
similar way.

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-07-01

--- Comment #5 from Jonathan Wakely  ---
Created attachment 53236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53236=edit
Add missing prerequisite to generated header

I'm testing this.

[r13-1395 Regression] FAIL: gfortran.dg/check_bits_2.f90 -O1 output pattern test on Linux/x86_64

[skpandey--- via Gcc-patches]

On Linux/x86_64,

f843bea4ca5613cb713f8b9313daa3938f254a05 is the first bad commit
commit f843bea4ca5613cb713f8b9313daa3938f254a05
Author: Uros Bizjak 
Date:   Fri Jul 1 17:25:03 2022 +0200

i386: Use "r" constraint in *andn3_doubleword_bmi

caused

FAIL: gfortran.dg/check_bits_2.f90   -O1  output pattern test

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r13-1395/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=gfortran.dg/check_bits_2.f90 --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [Patch][v5] OpenMP: Move omp requires checks to libgomp

[Tobias Burnus]

Updated version attached – I hope I got everything right, but I start to
get tired, I am not 100% sure.

On 01.07.22 18:55, Jakub Jelinek wrote:

Perhaps you're just lucky and the stack contains '\0' there?

Probably.

Maybe it would be better to simply use different error message for the
0 vs. non-0 case,

Done so.

For mkoffload, the single results are merged - and TARGET_USE is stripped,
such that it is either 0 or a combination of USM/UA/RO

I'd find it clearer if we never stripped that, so that even the library knows.

I have done so – and I concur that the check works then better in
libgomp as well.

Pedantically reading current standard probably yes, but perhaps again
something to be discussed.  The question is what the requires directive
in that case would do, nothing at all as there are no device constructs
etc.?

Isn't there a device construct – which happens to be empty?

In d.c there is.  But in c.c there isn't.
So, the question is if the directive in c.c is just completely ignored
(ok, aside from semantic checking) or if it should mean that if it is
specified there, it must be specified elsewhere where device constructs etc.
are used too.


Good question. The current code follows the wording of the spec and
ignores it. I think that's fine but still feels a bit odd.

Question: If it is not the same, should there just be a message to
stderr (gomp_error) or should libgomp abort (gomp_fatal)?

I'd say gomp_fatal.

Done so - it makes life easier.

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: Move omp requires checks to libgomp

Handle reverse_offload, unified_address, and unified_shared_memory
requirements in libgomp by saving them alongside the offload table.
When the device lto1 runs, it extracts the data for mkoffload. The
latter than passes the value on to GOMP_offload_register_ver.

lto1 (either the host one, with -flto [+ ENABLE_OFFLOADING], or in the
offload-device lto1) also does the the consistency check is done,
erroring out when the 'omp requires' clause use is inconsistent.

For all in-principle supported devices, if a requirement cannot be fulfilled,
the device is excluded from the (supported) devices list. Currently, none of
those requirements are marked as supported for any of the non-host devices.

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_target_data, c_parser_omp_target_update,
	c_parser_omp_target_enter_data, c_parser_omp_target_exit_data): Set
	OMP_REQUIRES_TARGET_USED.
	(c_parser_omp_requires): Remove sorry.

gcc/ChangeLog:

	* config/gcn/mkoffload.cc (process_asm): Write '#include '.
	(process_obj): Pass omp_requires_mask to GOMP_offload_register_ver.
	(main): Ask lto1 to obtain omp_requires_mask and pass it on.
	* config/nvptx/mkoffload.cc (process, main): Likewise.
	* lto-cgraph.cc (omp_requires_to_name): New.
	(input_offload_tables): Save omp_requires_mask.
	(output_offload_tables): Read it, check for consistency,
	save value for mkoffload.
	* omp-low.cc (lower_omp_target): Force output_offloadtables
	call for OMP_REQUIRES_TARGET_USED.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_target_data,
	cp_parser_omp_target_enter_data, cp_parser_omp_target_exit_data,
	cp_parser_omp_target_update): Set OMP_REQUIRES_TARGET_USED.
	(cp_parser_omp_requires): Remove sorry.

gcc/fortran/ChangeLog:

	* openmp.cc (gfc_match_omp_requires): Remove sorry.
	* parse.cc (decode_omp_directive): Don't regard 'declare target'
	as target usage for 'omp requires'; add more flags to
	omp_requires_mask.

include/ChangeLog:

	* gomp-constants.h (GOMP_VERSION): Bump to 2.
	(GOMP_REQUIRES_UNIFIED_ADDRESS, GOMP_REQUIRES_UNIFIED_SHARED_MEMORY,
	GOMP_REQUIRES_REVERSE_OFFLOAD, GOMP_REQUIRES_TARGET_USED):
	New defines.

libgomp/ChangeLog:

	* libgomp-plugin.h (GOMP_OFFLOAD_get_num_devices): Add
	omp_requires_mask arg.
	* plugin/plugin-gcn.c (GOMP_OFFLOAD_get_num_devices): Likewise;
	return -1 when device available but omp_requires_mask != 0.
	* plugin/plugin-nvptx.c (GOMP_OFFLOAD_get_num_devices): Likewise.
	* oacc-host.c (host_get_num_devices, host_openacc_get_property):
	Update call.
	* oacc-init.c (resolve_device, acc_init_1, acc_shutdown_1,
	goacc_attach_host_thread_to_device, acc_get_num_devices,
	acc_set_device_num, get_property_any): Likewise.
	* target.c (omp_requires_mask): New global var.
	(gomp_requires_to_name): New.
	(GOMP_offload_register_ver): Handle passed omp_requires_mask.
	(gomp_target_init): Handle omp_requires_mask.
	* libgomp.texi (OpenMP 5.0): Update requires impl. status.
	(OpenMP 5.1): Add a missed item.
	(OpenMP 5.2): Mark linear-clause change as supported in C/C++.
	* testsuite/libgomp.c-c++-common/requires-1-aux.c: New test.
	* testsuite/libgomp.c-c++-common/requires-1.c: New test.
	* testsuite/libgomp.c-c++-common/requires-2-aux.c: New test.
	* 

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

--- Comment #4 from Jonathan Wakely  ---
The header target is missing a prerequisite of stamp-${host_alias}

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

--- Comment #3 from Jonathan Wakely  ---
I think the errors are actually saying the directory doesn't exist, and are
coming from the three shell commands that redirect to that rule using >> $@.tmp

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Sergei Trofimovich from comment #0)
> There is a race condition when (I speculate) libstdcv++v3 is built in
> parallel from different 'make' processes. Perhaps for c++98 | c++11 | x++17
> instances?

There are no such instances. It is built separately for each multilib, but each
of those has its own $host_builddir

> 
> From libstdc++-v3/include/Makefile.am:
> 
>   # This header is not installed, it's only used to build libstdc++ itself.
>   ${host_builddir}/largefile-config.h: ${CONFIG_HEADER}
> @rm -f $@.tmp
> @-grep 'define _DARWIN_USE_64_BIT_INODE' ${CONFIG_HEADER} >> $@.tmp
> @-grep 'define _FILE_OFFSET_BITS' ${CONFIG_HEADER} >> $@.tmp
> @-grep 'define _LARGE_FILES' ${CONFIG_HEADER} >> $@.tmp
> @mv $@.tmp $@
> 
> As a result 'bits/largefile-config.h' rule gets executed in parallel and

I don't see how that's possible. It's a prerequisite of c++config.h which is
built once per multilib, and parallel make processes will coordinate to only
build the prereq once.

Are you 100% sure you didn't actually run multiple make processes yourself, e.g
by using & instead of && in a shell command?

[Bug tree-optimization/105860] [10/11/12/13 Regression] Miscompilation causing clobbered union contents since r10-918-gc56c86024f8fba0c

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

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

--- Comment #6 from Martin Jambor  ---
I proposed a fix on the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597674.html

[PATCH] tree-sra: Fix union handling in build_reconstructed_reference (PR 105860)

[Martin Jambor]

Hi,

As the testcase in PR 105860 shows, the code that tries to re-use the
handled_component chains in SRA can be horribly confused by unions,
where it thinks it has found a compatible structure under which it can
chain the references, but in fact it found the type it was looking
for elsewhere in a union and generated a write to a completely wrong
part of an aggregate.

I don't remember whether the plan was to support unions at all in
build_reconstructed_reference but it can work, to an extent, if we
make sure that we start the search only outside the outermost union,
which is what the patch does (and the extra testcase verifies).

Bootstrapped and tested on x86_64-linux.  OK for trunk and then for
release branches?

Thanks,

Martin


gcc/ChangeLog:

2022-07-01  Martin Jambor  

PR tree-optimization/105860
* tree-sra.cc (build_reconstructed_reference): Start expr
traversal only just below the outermost union.

gcc/testsuite/ChangeLog:

2022-07-01  Martin Jambor  

PR tree-optimization/105860
* gcc.dg/tree-ssa/alias-access-path-13.c: New test.
* gcc.dg/tree-ssa/pr105860.c: Likewise.
---
 .../gcc.dg/tree-ssa/alias-access-path-13.c| 31 +
 gcc/testsuite/gcc.dg/tree-ssa/pr105860.c  | 63 +++
 gcc/tree-sra.cc   | 13 +++-
 3 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr105860.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c 
b/gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c
new file mode 100644
index 000..e502a97bc75
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/alias-access-path-13.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-fre1" } */
+
+struct inn
+{
+  int val;
+};
+
+union foo
+{
+  struct inn inn;
+  long int baz;
+} *fooptr;
+
+struct bar
+{
+  union foo foo;
+  int val2;
+} *barptr;
+
+int
+test ()
+{
+  union foo foo;
+  foo.inn.val = 0;
+  barptr->val2 = 123;
+  *fooptr = foo;
+  return barptr->val2;
+}
+
+/* { dg-final { scan-tree-dump-times "return 123" 1 "fre1"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr105860.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr105860.c
new file mode 100644
index 000..77bcb4a6739
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr105860.c
@@ -0,0 +1,63 @@
+/* { dg-do run } */
+/* { dg-options "-O1" } */
+
+struct S1  {
+unsigned int _0;
+unsigned int _1;
+} ;
+struct S2  {
+struct S1 _s1;
+unsigned long _x2;
+} ;
+
+struct ufld_type1  {
+unsigned int _u1t;
+struct S2 _s2;
+} ;
+
+struct ufld_type2  {
+unsigned int _u2t;
+struct S1 _s1;
+} ;
+struct parm_type {
+union {
+struct ufld_type1 var_1;
+struct ufld_type2 var_2;
+} U;
+};
+
+struct parm_type  bad_function( struct parm_type arg0 )
+{
+struct parm_type rv;
+struct S2 var4;
+switch( arg0.U.var_2._u2t ) {
+case 4294967041:
+var4._s1 = arg0.U.var_1._s2._s1;
+rv.U.var_1._u1t = 4294967041;
+rv.U.var_1._s2 = var4;
+break;
+case 4294967043:
+rv.U.var_2._u2t = 4294967043;
+rv.U.var_2._s1 = arg0.U.var_2._s1;
+break;
+default:
+break;
+}
+return rv;
+}
+
+int main() {
+struct parm_type val;
+struct parm_type out;
+val.U.var_2._u2t = 4294967043;
+val.U.var_2._s1._0 = 0x01010101;
+val.U.var_2._s1._1 = 0x02020202;
+out = bad_function(val);
+   if (val.U.var_2._u2t != 4294967043)
+ __builtin_abort ();
+if (out.U.var_2._s1._0 != 0x01010101)
+ __builtin_abort ();
+if (val.U.var_2._s1._1 != 0x02020202 )
+ __builtin_abort ();
+   return 0;
+}
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 081c51b58a4..099e8dbe873 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -1667,7 +1667,18 @@ build_ref_for_offset (location_t loc, tree base, 
poly_int64 offset,
 static tree
 build_reconstructed_reference (location_t, tree base, struct access *model)
 {
-  tree expr = model->expr, prev_expr = NULL;
+  tree expr = model->expr;
+  /* We have to make sure to start just below the outermost union.  */
+  tree start_expr = expr;
+  while (handled_component_p (expr))
+{
+  if (TREE_CODE (TREE_TYPE (TREE_OPERAND (expr, 0))) == UNION_TYPE)
+   start_expr = expr;
+  expr = TREE_OPERAND (expr, 0);
+}
+
+  expr = start_expr;
+  tree prev_expr = NULL_TREE;
   while (!types_compatible_p (TREE_TYPE (expr), TREE_TYPE (base)))
 {
   if (!handled_component_p (expr))
-- 
2.36.1

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Aldy Hernandez via Gcc-patches]

BTW, I don't know if it got lost in all my patches, but we already
have an irange allocator that given an irange, returns a chunk of
memory holding a clone of that irange squished into its minimum
representable pairs (see vrange_allocator and friends).  So we won't
ever be storing 255 or something equally absurd like I had proposed
years ago :).  We'll be storing the smallest representable range
inside a trailing_wide_int.

Aldy

On Fri, Jul 1, 2022 at 10:31 PM Aldy Hernandez  wrote:
>
> On Fri, Jul 1, 2022 at 8:53 PM Jakub Jelinek  wrote:
> >
> > On Fri, Jul 01, 2022 at 07:43:28PM +0200, Aldy Hernandez wrote:
> > > You can still say N=255 and things continue to work as they do now, since
> > > m_len[] is still statically determined. The only difference is that 
> > > before,
> > > the size of the structure would be 2+1+255+sizeof(int) whereas now it 
> > > would
> > > be 1 more because of the byte I'm using for num_elements.
> >
> > So, what N do you want to use for SSA_NAME_RANGE_INFO?
> > N=255 wouldn't be very space efficient especially if the common case is a
> > single range or two.
> > For such cases making e.g. m_len not an embedded array, but pointer to
> > somewhere after the HOST_WIDE_INT array in the same allocation would be
> > better.
>
> As I mentioned in my original post, 12.  This means that I'm taking
> the 4 bytes that are left over from the current padding plus 8
> (64-bits).  My trailing wide int structure for SSA_NAME_RANGE_INFO
> will be one word larger than what is currently there.  But we'll be
> able to store up to 5 pairs plus one for the nonzero bits plus one for
> future development (5*2 + 1 + 1 = 12), all without going over the 64
> bit alignment.
>
> This is a theoretical max, in reality as I mentioned, 99% of ranges
> calculated in infinite precision by the ranger fit into 3-4 pairs.
>
> Aldy

Go patch committed: Avoid C++20 keyword requires

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend renames "requires" to "needs" to avoid
the C++20 keyword.  Bootstrapped on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian
9d44418664ec8c3e59365901e3ec02e488d9e01c
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 0d49e9e70c6..65f64e0fbfb 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-548720bca6bff21ebc9aba22249d9ce45bbd90c7
+ac438edc5335f69c95df9342f43712ad2f61ad66
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/gogo.cc b/gcc/go/gofrontend/gogo.cc
index e13df0da22b..67b91fab4ca 100644
--- a/gcc/go/gofrontend/gogo.cc
+++ b/gcc/go/gofrontend/gogo.cc
@@ -5302,16 +5302,16 @@ Gogo::write_c_header()
   Named_object* no = types.front();
   types.pop_front();
 
-  std::vector requires;
+  std::vector needs;
   std::vector declare;
-  if (!no->type_value()->struct_type()->can_write_to_c_header(,
+  if (!no->type_value()->struct_type()->can_write_to_c_header(,
  ))
continue;
 
   bool ok = true;
   for (std::vector::const_iterator pr
-= requires.begin();
-  pr != requires.end() && ok;
+= needs.begin();
+  pr != needs.end() && ok;
   ++pr)
{
  for (std::list::const_iterator pt = types.begin();
@@ -5342,10 +5342,10 @@ Gogo::write_c_header()
  if (*pd == no)
continue;
 
- std::vector drequires;
+ std::vector dneeds;
  std::vector ddeclare;
  if (!(*pd)->type_value()->struct_type()->
- can_write_to_c_header(, ))
+ can_write_to_c_header(, ))
continue;
 
  bool done = false;
diff --git a/gcc/go/gofrontend/types.cc b/gcc/go/gofrontend/types.cc
index e82be6840aa..4995283bb60 100644
--- a/gcc/go/gofrontend/types.cc
+++ b/gcc/go/gofrontend/types.cc
@@ -6967,7 +6967,7 @@ Struct_type::do_import(Import* imp)
 
 bool
 Struct_type::can_write_to_c_header(
-std::vector* requires,
+std::vector* needs,
 std::vector* declare) const
 {
   const Struct_field_list* fields = this->fields_;
@@ -6978,7 +6978,7 @@ Struct_type::can_write_to_c_header(
p != fields->end();
++p)
 {
-  if (!this->can_write_type_to_c_header(p->type(), requires, declare))
+  if (!this->can_write_type_to_c_header(p->type(), needs, declare))
return false;
   if (Gogo::message_name(p->field_name()) == "_")
sinks++;
@@ -6993,7 +6993,7 @@ Struct_type::can_write_to_c_header(
 bool
 Struct_type::can_write_type_to_c_header(
 const Type* t,
-std::vector* requires,
+std::vector* needs,
 std::vector* declare) const
 {
   t = t->forwarded();
@@ -7027,13 +7027,13 @@ Struct_type::can_write_type_to_c_header(
   return true;
 
 case TYPE_STRUCT:
-  return t->struct_type()->can_write_to_c_header(requires, declare);
+  return t->struct_type()->can_write_to_c_header(needs, declare);
 
 case TYPE_ARRAY:
   if (t->is_slice_type())
return true;
   return this->can_write_type_to_c_header(t->array_type()->element_type(),
- requires, declare);
+ needs, declare);
 
 case TYPE_NAMED:
   {
@@ -7049,10 +7049,10 @@ Struct_type::can_write_type_to_c_header(
// We will accept empty struct fields, but not print them.
if (t->struct_type()->total_field_count() == 0)
  return true;
-   requires->push_back(no);
-   return t->struct_type()->can_write_to_c_header(requires, declare);
+   needs->push_back(no);
+   return t->struct_type()->can_write_to_c_header(needs, declare);
  }
-   return this->can_write_type_to_c_header(t->base(), requires, declare);
+   return this->can_write_type_to_c_header(t->base(), needs, declare);
   }
 
 case TYPE_CALL_MULTIPLE_RESULT:
@@ -7150,9 +7150,9 @@ Struct_type::write_field_to_c_header(std::ostream& os, 
const std::string& name,
 
 case TYPE_POINTER:
   {
-   std::vector requires;
+   std::vector needs;
std::vector declare;
-   if (!this->can_write_type_to_c_header(t->points_to(), ,
+   if (!this->can_write_type_to_c_header(t->points_to(), ,
  ))
  os << "void*";
else

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Aldy Hernandez via Gcc-patches]

On Fri, Jul 1, 2022 at 8:53 PM Jakub Jelinek  wrote:
>
> On Fri, Jul 01, 2022 at 07:43:28PM +0200, Aldy Hernandez wrote:
> > You can still say N=255 and things continue to work as they do now, since
> > m_len[] is still statically determined. The only difference is that before,
> > the size of the structure would be 2+1+255+sizeof(int) whereas now it would
> > be 1 more because of the byte I'm using for num_elements.
>
> So, what N do you want to use for SSA_NAME_RANGE_INFO?
> N=255 wouldn't be very space efficient especially if the common case is a
> single range or two.
> For such cases making e.g. m_len not an embedded array, but pointer to
> somewhere after the HOST_WIDE_INT array in the same allocation would be
> better.

As I mentioned in my original post, 12.  This means that I'm taking
the 4 bytes that are left over from the current padding plus 8
(64-bits).  My trailing wide int structure for SSA_NAME_RANGE_INFO
will be one word larger than what is currently there.  But we'll be
able to store up to 5 pairs plus one for the nonzero bits plus one for
future development (5*2 + 1 + 1 = 12), all without going over the 64
bit alignment.

This is a theoretical max, in reality as I mentioned, 99% of ranges
calculated in infinite precision by the ranger fit into 3-4 pairs.

Aldy

Re: [pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]

[Stephan Bergmann via Gcc-patches]

On 6/25/22 00:26, Jason Merrill via Gcc-patches wrote:

This seems like a good warning to have in -Wall, as requested.  But as
pointed out in PR20423, some users want a warning only when a derived
function doesn't override any base function.  So let's put that lesser
version in -Wall (and -Woverloaded-virtual=1) while leaving the semantics
for the existing option the same.


This now causes


$ cat test.cc
struct S1 {};
struct S2: S1 { virtual ~S2(); };
struct S3 { virtual ~S3(); };
struct S4: S2, S3 { virtual ~S4(); };



$ g++ -Woverloaded-virtual -fsyntax-only test.cc
test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
3 | struct S3 { virtual ~S3(); };
  | ^
test.cc:4:29: note:   by ‘virtual S4::~S4()’
4 | struct S4: S2, S3 { virtual ~S4(); };
  | ^
test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
3 | struct S3 { virtual ~S3(); };
  | ^
test.cc:4:29: note:   by ‘virtual S4::~S4()’
4 | struct S4: S2, S3 { virtual ~S4(); };
  | ^
test.cc:3:21: warning: ‘virtual S3::~S3()’ was hidden [-Woverloaded-virtual=]
3 | struct S3 { virtual ~S3(); };
  | ^
test.cc:4:29: note:   by ‘virtual S4::~S4()’
4 | struct S4: S2, S3 { virtual ~S4(); };
  | ^

[Bug fortran/95107] ICE in hash_operand, at fold-const.c:3768

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

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
The issue can be studied by playing with option -fmax-stack-var-size=n.
-fno-automatic corresponds to n=0; using n=64 and higher lets the code compile.
There's something weird going on here.

Re: Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

[Jason Merrill via Gcc-patches]

On 6/29/22 12:59, Jason Merrill wrote:

On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote:

Hello-

https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49

Would a C++ maintainer have some time to take a look at this patch
please? I feel like the PR is still worth resolving. If this doesn't
seem like a good way, I am happy to try another -- would really
appreciate any feedback. Thanks!


Thanks for your persistence, I'll take a look now.

Incidentally, when pinging it's often useful to ping someone from 
MAINTAINERS directly, as well as the list.  I think your last ping got 
eaten by some trouble Red Hat email was having at the time.


The cp_token_is_module_directive cleanup is OK.


+  bool skip_this_pragma;


This member seems to be equivalent to
  in_pragma && !should_output_pragmas ()
Maybe it could be a member function instead of a data member?

More soon.


Looks good, just a few minor comments:


+  PD_KIND_INVALID,
+  PD_KIND_PUSH,
+  PD_KIND_POP,
+  PD_KIND_IGNORED_ATTRIBUTES,
+  PD_KIND_DIAGNOSTIC,


The PD_KIND_ prefix seems unnecessary for a scoped enum.


+/* When preprocessing only, pragma_lex() is not available, so obtain the tokens
+   directly from libcpp.  */
+static void
+pragma_diagnostic_lex_pp (pragma_diagnostic_data *result)


Hmm, we could make a temporary lexer, but I guess this is short enough 
that the duplication is OK.



+/* Similar, for the portion of a diagnostic pragma that was parsed
+   internally and so not seen by our token streamer.  */


Can we rewind after parsing so that the token streamer sees it?


+  if (early && arg)
+{
+  /* This warning is needed because of PR71603 - popping the diagnostic
+state does not currently reset changes to option arguments, only
+changes to the option dispositions.  */
+  warning_at (data.loc_option, OPT_Wpragmas,
+ "a diagnostic pragma attempting to modify a preprocessor"
+ " option argument may not work as expected");
+}


Maybe only warn if we subsequently see a pop?


+/* Handle #pragma gcc diagnostic, which needs to be done during preprocessing
+   for the case of preprocessing-related diagnostics.  */
+static void
+cp_lexer_handle_early_pragma (cp_lexer *lexer)


Let's mention in the comment that this is called before appending the 
CPP_PRAGMA_EOL to the lexer buffer.


Jason

Re: [PATCH] sanitizer: Fix hwasan related option conflicts [PR106132]

[Jeff Law via Gcc-patches]

On 6/29/2022 6:04 AM, Martin Liška wrote:
Split report_conflicting_sanitizer_options(..., SANITIZE_ADDRESS | 
SANITIZE_HWADDRESS)

call into 2 calls as we don't have any option that would be
address+hwaddress (that conflicts as well).

PR sanitizer/106132

gcc/ChangeLog:

* opts.cc (finish_options): Use 2 calls to
    report_conflicting_sanitizer_options.

gcc/testsuite/ChangeLog:

* c-c++-common/hwasan/arguments-3.c: Cover new ICE.

OK
jeff

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Jakub Jelinek via Gcc-patches]

On Fri, Jul 01, 2022 at 07:43:28PM +0200, Aldy Hernandez wrote:
> You can still say N=255 and things continue to work as they do now, since
> m_len[] is still statically determined. The only difference is that before,
> the size of the structure would be 2+1+255+sizeof(int) whereas now it would
> be 1 more because of the byte I'm using for num_elements.

So, what N do you want to use for SSA_NAME_RANGE_INFO?
N=255 wouldn't be very space efficient especially if the common case is a
single range or two.
For such cases making e.g. m_len not an embedded array, but pointer to
somewhere after the HOST_WIDE_INT array in the same allocation would be
better.

Jakub

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Richard Sandiford via Gcc-patches]

Aldy Hernandez via Gcc-patches  writes:
> Currently global ranges are stored in SSA_NAME_RANGE_INFO as a pair of
> wide_int-like objects along with the nonzero bits.  We frequently lose
> precision when streaming out our higher resolution iranges.  The plan
> was always to store the full irange between passes.  However, as was
> originally discussed eons ago:
>
>   https://gcc.gnu.org/pipermail/gcc-patches/2017-May/475139.html
>
> ...we need a memory efficient way of saving iranges, preferably using
> the trailing_wide_ints idiom.
>
> The problem with doing so is that trailing_wide_ints assume a
> compile-time specified number of elements.  For irange, we need to
> determine the size at run-time.
>
> One solution is to adapt trailing_wide_ints such that N is the maximum
> number of elements allowed, and allow setting the actual number at
> run-time (defaulting to N).  The attached patch does this, while
> requiring no changes to existing users.
>
> It uses a byte to store the number of elements in the
> trailing_wide_ints control word.  The control word is currently a
> 16-bit precision, an 8-bit max-length, and the rest is used for
> m_len[N].  On a 64-bit architecture, this allows for 5 elements in
> m_len without having to use an extra word.  With this patch, m_len[]
> would be smaller by one byte (4) before consuming the padding.  This
> shouldn't be a problem as the only users of trailing_wide_ints use N=2
> for NUM_POLY_INT_COEFFS in aarch64, and N=3 for range_info_def.
>
> For irange, my plan is to use one more word to fit a maximum of 12
> elements (the above 4 plus 8 more).  This would allow for 6 pairs of
> sub-ranges which would be more than adequate for our needs.  In
> previous tests we found that 99% of ranges fit within 3-4 pairs.  More
> precisely, this would allow for 5 pairs, plus the nonzero bits, plus a
> spare wide-int for future development.
>
> Ultimately this means that streaming an irange would consume one more
> word than what we currently do for range_info_def.  IMO this is a nice
> trade-off considering we started storing a slew of wide-ints directly
> ;-).
>
> I'm not above rolling an altogether different approach, but would
> prefer to use the existing trailing infrastructure since it's mostly
> what we need.
>
> Thoughts?
>
> p.s. Tested and benchmarked on x86-64 Linux.  There was no discernible
> performance change in our benchmark suite.

Thanks for the discussion downthread.  I had some of the same questions
as Jakub, but you've answered them :-)

> gcc/ChangeLog:
>
>   * wide-int.h (struct trailing_wide_ints): Add m_num_elements.
>   (trailing_wide_ints::set_precision): Add num_elements argument.
>   (trailing_wide_ints::extra_size): Same.
> ---
>  gcc/wide-int.h | 42 +-
>  1 file changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/gcc/wide-int.h b/gcc/wide-int.h
> index 8041b6104f9..f68ccf0a0c5 100644
> --- a/gcc/wide-int.h
> +++ b/gcc/wide-int.h
> @@ -1373,10 +1373,13 @@ namespace wi
>  : public int_traits  {};
>  }
>  
> -/* An array of N wide_int-like objects that can be put at the end of
> -   a variable-sized structure.  Use extra_size to calculate how many
> -   bytes beyond the sizeof need to be allocated.  Use set_precision
> -   to initialize the structure.  */
> +/* A variable-lengthed array of wide_int-like objects that can be put

s/lengthed/length/

> +   at the end of a variable-sized structure.  The number of objects is
> +   at most N and can be set at runtime by using set_precision().
> +
> +   Use extra_size to calculate how many bytes beyond the
> +   sizeof need to be allocated.  Use set_precision to initialize the
> +   structure.  */
>  template 
>  struct GTY((user)) trailing_wide_ints
>  {
> @@ -1387,6 +1390,9 @@ private:
>/* The shared maximum length of each number.  */
>unsigned char m_max_len;
>  
> +  /* The number of elements.  */
> +  unsigned char m_num_elements;
> +
>/* The current length of each number.
>   Avoid char array so the whole structure is not a typeless storage
>   that will, in turn, turn off TBAA on gimple, trees and RTL.  */
> @@ -1399,12 +1405,15 @@ private:
>  public:
>typedef WIDE_INT_REF_FOR (trailing_wide_int_storage) const_reference;
>  
> -  void set_precision (unsigned int);
> +  void set_precision (unsigned int precision, unsigned int num_elements = N);
>unsigned int get_precision () const { return m_precision; }
> +  unsigned int num_elements () const { return m_num_elements; }
>trailing_wide_int operator [] (unsigned int);
>const_reference operator [] (unsigned int) const;
> -  static size_t extra_size (unsigned int);
> -  size_t extra_size () const { return extra_size (m_precision); }
> +  static size_t extra_size (unsigned int precision,
> + unsigned int num_elements = N);
> +  size_t extra_size () const { return extra_size (m_precision,
> +  

[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132

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

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

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

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

commit r10-10878-gbac42273343bb9a198704900e2118ed4e84cb23a
Author: Harald Anlauf 
Date:   Mon Jun 20 20:59:55 2022 +0200

Fortran: handle explicit-shape specs with constant bounds [PR105954]

gcc/fortran/ChangeLog:

PR fortran/105954
* decl.c (variable_decl): Adjust upper bounds for explicit-shape
specs with constant bound expressions to ensure non-negative
extents.

gcc/testsuite/ChangeLog:

PR fortran/105954
* gfortran.dg/pr105954.f90: New test.

(cherry picked from commit a312407bd715647f7c11b67e0a52effc94d0f15d)

[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132

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

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

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

https://gcc.gnu.org/g:7296a7c9aa35a9731a73e33c29f6bbc488a0c837

commit r11-10103-g7296a7c9aa35a9731a73e33c29f6bbc488a0c837
Author: Harald Anlauf 
Date:   Mon Jun 20 20:59:55 2022 +0200

Fortran: handle explicit-shape specs with constant bounds [PR105954]

gcc/fortran/ChangeLog:

PR fortran/105954
* decl.c (variable_decl): Adjust upper bounds for explicit-shape
specs with constant bound expressions to ensure non-negative
extents.

gcc/testsuite/ChangeLog:

PR fortran/105954
* gfortran.dg/pr105954.f90: New test.

(cherry picked from commit a312407bd715647f7c11b67e0a52effc94d0f15d)

[Bug middle-end/105860] [10/11/12/13 Regression] Miscompilation causing clobbered union contents since r10-918-gc56c86024f8fba0c

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Jambor  ---
Mine.

[Bug libstdc++/106162] libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 53235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53235=edit
build.log.xz

[Bug libstdc++/106162] New: libstdc++v3: bits/largefile-config.h.tmp: No such file or directory race condition

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

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

Bug ID: 106162
   Summary: libstdc++v3: bits/largefile-config.h.tmp: No such file
or directory race condition
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
  Target Milestone: ---

There is a race condition when (I speculate) libstdcv++v3 is built in parallel
from different 'make' processes. Perhaps for c++98 | c++11 | x++17 instances?

>From libstdc++-v3/include/Makefile.am:

  # This header is not installed, it's only used to build libstdc++ itself.
  ${host_builddir}/largefile-config.h: ${CONFIG_HEADER}
@rm -f $@.tmp
@-grep 'define _DARWIN_USE_64_BIT_INODE' ${CONFIG_HEADER} >> $@.tmp
@-grep 'define _FILE_OFFSET_BITS' ${CONFIG_HEADER} >> $@.tmp
@-grep 'define _LARGE_FILES' ${CONFIG_HEADER} >> $@.tmp
@mv $@.tmp $@

As a result 'bits/largefile-config.h' rule gets executed in parallel and
clobbers temporary file on this week's gcc-13 snapshot:

...
make[3]: Entering directory '/build/build/x86_64-w64-mingw32/libstdc++-v3'
Making all in include
make[4]: Entering directory
'/build/build/x86_64-w64-mingw32/libstdc++-v3/include'
echo 1 > stamp-dual-abi
echo 1 > stamp-allocator-new
echo timestamp > stamp-pb
echo 1 > stamp-cxx11-abi
echo 0 > stamp-visibility
echo 1 > stamp-extern-template
echo 0 > stamp-namespace-version
echo 'define _GLIBCXX_USE_FLOAT128 1' > stamp-float128
/nix/store/xsq6y0yn5mbmyazn51c86kz9zkr357xj-bash-5.1-p16/bin/bash: line 1:
x86_64-w64-mingw32/bits/largefile-config.h.tmp: No such file or directory
make[4]: [Makefile:1785: x86_64-w64-mingw32/bits/largefile-config.h] Error 1
(ignored) shuffle=1656692854
/nix/store/xsq6y0yn5mbmyazn51c86kz9zkr357xj-bash-5.1-p16/bin/bash: line 1:
x86_64-w64-mingw32/bits/largefile-config.h.tmp: No such file or directory
make[4]: [Makefile:1786: x86_64-w64-mingw32/bits/largefile-config.h] Error 1
(ignored) shuffle=1656692854
/nix/store/xsq6y0yn5mbmyazn51c86kz9zkr357xj-bash-5.1-p16/bin/bash: line 1:
x86_64-w64-mingw32/bits/largefile-config.h.tmp: No such file or directory
make[4]: [Makefile:1787: x86_64-w64-mingw32/bits/largefile-config.h] Error 1
(ignored) shuffle=1656692854
mv: cannot stat 'x86_64-w64-mingw32/bits/largefile-config.h.tmp': No such file
or directory
make[4]: *** [Makefile:1788: x86_64-w64-mingw32/bits/largefile-config.h] Error
1 shuffle=1656692854
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory
'/build/build/x86_64-w64-mingw32/libstdc++-v3/include'
make[3]: *** [Makefile:576: all-recursive] Error 1 shuffle=1656692854
make[3]: Leaving directory '/build/build/x86_64-w64-mingw32/libstdc++-v3'
make[2]: *** [Makefile:501: all] Error 2 shuffle=1656692854
make[2]: Leaving directory '/build/build/x86_64-w64-mingw32/libstdc++-v3'
make[1]: *** [Makefile:12287: all-target-libstdc++-v3] Error 2
shuffle=1656692854
make[1]: Leaving directory '/build/build'
make: *** [Makefile:1031: all] Error 2 shuffle=1656692854

Note how 'largefile-config.h.tmp: No such file or directory' is reported 3
times.

Will attach full build.log in case it makes the error cause clearer.

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.5
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed for all open branches.  Closing.

Thanks for the report!

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

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

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

commit r10-10877-ge6db08d9183b80b0ada5122fae79412544279f56
Author: Harald Anlauf 
Date:   Tue Jun 21 23:20:18 2022 +0200

Fortran: fix simplification of INDEX(str1,str2) [PR105691]

gcc/fortran/ChangeLog:

PR fortran/105691
* simplify.c (gfc_simplify_index): Replace old simplification
code by the equivalent of the runtime library implementation.  Use
HOST_WIDE_INT instead of int for string index, length variables.

gcc/testsuite/ChangeLog:

PR fortran/105691
* gfortran.dg/index_6.f90: New test.

(cherry picked from commit ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd)

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

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

https://gcc.gnu.org/g:614d9e76b71df6c5ad42f2b9c2a8156e8b3ebd35

commit r11-10102-g614d9e76b71df6c5ad42f2b9c2a8156e8b3ebd35
Author: Harald Anlauf 
Date:   Tue Jun 21 23:20:18 2022 +0200

Fortran: fix simplification of INDEX(str1,str2) [PR105691]

gcc/fortran/ChangeLog:

PR fortran/105691
* simplify.c (gfc_simplify_index): Replace old simplification
code by the equivalent of the runtime library implementation.  Use
HOST_WIDE_INT instead of int for string index, length variables.

gcc/testsuite/ChangeLog:

PR fortran/105691
* gfortran.dg/index_6.f90: New test.

(cherry picked from commit ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd)

[Bug tree-optimization/106126] [13 Regression] tree check fail in useless_type_conversion_p, at gimple-expr.cc:87 since r13-1184-g57424087e82db140

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #20 from David Binderman  ---
(In reply to David Binderman from comment #19)
> I have a third test case. I suspect it is a duplicate of #2, 
> but could I ask you to confirm this, please ?
> 
> It is part of the same package as #2, wxWidgets.

I checked here and all is in order.

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Aldy Hernandez via Gcc-patches]

On Fri, Jul 1, 2022, 18:58 Jakub Jelinek  wrote:

> On Fri, Jul 01, 2022 at 06:47:48PM +0200, Aldy Hernandez wrote:
> > > So, you are looking for something like trailing_wide_ints but where
> that
> > > N is actually a runtime value?  Then e.g. the
> > >   struct {unsigned char len;} m_len[N];
> > > member can't work properly either, because it isn't constant size.
> >
> > What my patch does is store the run-time length in the aforementioned
> > byte, while defaulting to N/MAX.  There is no size difference (or code
> > changes) for existing users.  With my change, set_precision() and
> > extra_size() now take a runtime parameter, but it defaults to N and is
> > inlined, so there is no penalty for existing users.  I benchmarked to
> > make sure :).
>
> So, you still use N = 3 but can sometimes store say 255 wide_ints in there?
> In that case, m_len[N] provides lengths just for the first 3, no?
>

You can still say N=255 and things continue to work as they do now, since
m_len[] is still statically determined. The only difference is that before,
the size of the structure would be 2+1+255+sizeof(int) whereas now it would
be 1 more because of the byte I'm using for num_elements.

The only time this would be an issue would be for say N=253 because the
size of everything except the ints is currently 256 (2+1+253), which is 64
bit aligned, whereas with my patch it would be 257 which takes an
additional word.

This is all theoretical because there are no users of trailing wide ints
greater than 3.

I guess what I'm really doing is changing the semantics of
trailing_wide_ints to trailing_wide_ints and what used to be the
number of elements is determined at run timebut the default is MAX so
everything continues to work the same for the current users.

Does that make sense?

Aldy


> Anyway, you really want feedback from Richard Sandiford IMHO...
>
> Jakub
>
>

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.5

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed for all open branches.  Closing.

Thanks for the report!

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

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

https://gcc.gnu.org/g:1214ebb39cd250fda678ec89c785fcea86888a89

commit r10-10876-g1214ebb39cd250fda678ec89c785fcea86888a89
Author: Harald Anlauf 
Date:   Fri Jun 24 22:21:39 2022 +0200

Fortran: fix checking of arguments to UNPACK when MASK is a variable
[PR105813]

gcc/fortran/ChangeLog:

PR fortran/105813
* check.c (gfc_check_unpack): Try to simplify MASK argument to
UNPACK so that checking of the VECTOR argument can work when MASK
is a variable.

gcc/testsuite/ChangeLog:

PR fortran/105813
* gfortran.dg/unpack_vector_1.f90: New test.

(cherry picked from commit f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40)

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:9902f93edd43853cd958b2e124878865da69a177

commit r11-10101-g9902f93edd43853cd958b2e124878865da69a177
Author: Harald Anlauf 
Date:   Fri Jun 24 22:21:39 2022 +0200

Fortran: fix checking of arguments to UNPACK when MASK is a variable
[PR105813]

gcc/fortran/ChangeLog:

PR fortran/105813
* check.c (gfc_check_unpack): Try to simplify MASK argument to
UNPACK so that checking of the VECTOR argument can work when MASK
is a variable.

gcc/testsuite/ChangeLog:

PR fortran/105813
* gfortran.dg/unpack_vector_1.f90: New test.

(cherry picked from commit f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40)

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Jakub Jelinek via Gcc-patches]

On Fri, Jul 01, 2022 at 06:47:48PM +0200, Aldy Hernandez wrote:
> > So, you are looking for something like trailing_wide_ints but where that
> > N is actually a runtime value?  Then e.g. the
> >   struct {unsigned char len;} m_len[N];
> > member can't work properly either, because it isn't constant size.
> 
> What my patch does is store the run-time length in the aforementioned
> byte, while defaulting to N/MAX.  There is no size difference (or code
> changes) for existing users.  With my change, set_precision() and
> extra_size() now take a runtime parameter, but it defaults to N and is
> inlined, so there is no penalty for existing users.  I benchmarked to
> make sure :).

So, you still use N = 3 but can sometimes store say 255 wide_ints in there?
In that case, m_len[N] provides lengths just for the first 3, no?

Anyway, you really want feedback from Richard Sandiford IMHO...

Jakub

[og12] [committed] Port remaining OG11 patches

[Kwok Cheung Yeung]

Hello

I have committed the following forward-ports from OG11 onto the 
devel/omp/gcc-12 branch to bring OG12 up-to-parity with OG11 again.


12d14a9a255 amdgcn: libgomp plugin USM implementation
687640af27a amdgcn, openmp: Auto-detect USM mode and set HSA_XNACK
cbc3dd01de8 amdgcn: Support XNACK mode
1d4e24c9fb4 Fix gfortran.dg/gomp/num-teams-2.f90

KwokFrom 1d4e24c9fb40d4df7e742d7631a29329d5fb7c84 Mon Sep 17 00:00:00 2001
From: Tobias Burnus 
Date: Mon, 27 Jun 2022 13:26:43 +0200
Subject: [PATCH 1/4] Fix gfortran.dg/gomp/num-teams-2.f90

OG11 contrary to mainline issues an error for resolve_positive_int_expr
(-> OG11 commit a14b3f29681da1d2465e15f98b8cf8d5c64a2c3c). Update
testcase accordingly.

gcc/testsuite/
* gfortran.dg/gomp/num-teams-2.f90: Use dg-error not dg-warning.
---
 gcc/testsuite/ChangeLog.omp|  4 
 gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90 | 12 ++--
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/ChangeLog.omp b/gcc/testsuite/ChangeLog.omp
index 301085fba5d..99ed6f0e467 100644
--- a/gcc/testsuite/ChangeLog.omp
+++ b/gcc/testsuite/ChangeLog.omp
@@ -1,3 +1,7 @@
+2022-06-27  Tobias Burnus  
+
+   * gfortran.dg/gomp/num-teams-2.f90: Use dg-error not dg-warning.
+
 2022-05-12  Jakub Jelinek  
 
Backport from mainline:
diff --git a/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90 
b/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90
index e7814a11a5a..f3031481d4a 100644
--- a/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90
@@ -9,13 +9,13 @@ subroutine foo (i)
   !$omp teams num_teams (6 : 4)! { dg-warning "NUM_TEAMS lower 
bound at .1. larger than upper bound at .2." }
   !$omp end teams
 
-  !$omp teams num_teams (-7)   ! { dg-warning "INTEGER expression of 
NUM_TEAMS clause at .1. must be positive" }
+  !$omp teams num_teams (-7)   ! { dg-error "INTEGER expression of 
NUM_TEAMS clause at .1. must be positive" }
   !$omp end teams
 
-  !$omp teams num_teams (i : -7)   ! { dg-warning "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp teams num_teams (i : -7)   ! { dg-error "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end teams
 
-  !$omp teams num_teams (-7 : 8)   ! { dg-warning "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp teams num_teams (-7 : 8)   ! { dg-error "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end teams
 end
 
@@ -25,13 +25,13 @@ subroutine bar (i)
   !$omp target teams num_teams (6 : 4) ! { dg-warning "NUM_TEAMS lower bound 
at .1. larger than upper bound at .2." }
   !$omp end target teams
 
-  !$omp target teams num_teams (-7)! { dg-warning "INTEGER expression of 
NUM_TEAMS clause at .1. must be positive" }
+  !$omp target teams num_teams (-7)! { dg-error "INTEGER expression of 
NUM_TEAMS clause at .1. must be positive" }
   !$omp end target teams
 
-  !$omp target teams num_teams (i : -7)! { dg-warning "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp target teams num_teams (i : -7)! { dg-error "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end target teams
 
-  !$omp target teams num_teams (-7 : 8)! { dg-warning "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp target teams num_teams (-7 : 8)! { dg-error "INTEGER 
expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end target teams
 end
 end module
-- 
2.25.1

From cbc3dd01de8788587a2b641efcb838058303b5ab Mon Sep 17 00:00:00 2001
From: Andrew Stubbs 
Date: Fri, 10 Jun 2022 15:15:49 +0100
Subject: [PATCH 2/4] amdgcn: Support XNACK mode

The XNACK feature allows memory load instructions to restart safely following
a page-miss interrupt.  This is useful for shared-memory devices, like APUs,
and to implement OpenMP Unified Shared Memory.

To support the feature we must be able to set the appropriate meta-data and
set the load instructions to early-clobber.  When the port supports scheduling
of s_waitcnt instructions there will be further requirements.

gcc/ChangeLog:

* config/gcn/gcn-hsa.h (XNACKOPT): New macro.
(ASM_SPEC): Use XNACKOPT.
* config/gcn/gcn-opts.h (enum sram_ecc_type): Rename to ...
(enum hsaco_attr_type): ... this, and generalize the names.
(TARGET_XNACK): New macro.
* config/gcn/gcn-valu.md (gather_insn_1offset):
Add xnack compatible alternatives.
(gather_insn_2offsets): Likewise.
* config/gcn/gcn.c (gcn_option_override): Permit -mxnack for devices
other than Fiji.
(gcn_expand_epilogue): Remove early-clobber problems.
(output_file_start): Emit xnack attributes.
(gcn_hsa_declare_function_name): Obey -mxnack setting.
* config/gcn/gcn.md 

Re: [Patch][v5] OpenMP: Move omp requires checks to libgomp

[Jakub Jelinek via Gcc-patches]

On Fri, Jul 01, 2022 at 06:31:48PM +0200, Tobias Burnus wrote:
> This is done in openmp.cc during parsing. The merging you quoted (in 
> parse.cc) happens
> after the whole input file has been parsed and resolved. For your test case, 
> the
> following error is shown:
> 
> test.f90:1:15:
> 
> 1 |  subroutine foo
>   |   1
> Error: Program unit at (1) has OpenMP device constructs/routines but does not 
> set !$OMP REQUIRES REVERSE_OFFLOAD but other program units do
> test.f90:6:14:
> 
> 6 | subroutine bar
>   |  1
> Error: Program unit at (1) has OpenMP device constructs/routines but does not 
> set !$OMP REQUIRES UNIFIED_SHARED_MEMORY but other program units do

Great.

> > @@ -1764,6 +1781,20 @@ input_symtab (void)
> > >   }
> > >   }
> > > 
> > > +static void
> > > +omp_requires_to_name (char *buf, size_t size, unsigned int requires_mask)
> > > +{
> > > +  char *end = buf + size, *p = buf;
> > > +  if (requires_mask & GOMP_REQUIRES_UNIFIED_ADDRESS)
> > > +p += snprintf (p, end - p, "unified_address");
> > > +  if (requires_mask & GOMP_REQUIRES_UNIFIED_SHARED_MEMORY)
> > > +p += snprintf (p, end - p, "%sunified_shared_memory",
> > > +   (p == buf ? "" : ", "));
> > > +  if (requires_mask & GOMP_REQUIRES_REVERSE_OFFLOAD)
> > > +p += snprintf (p, end - p, "%sreverse_offload",
> > > +   (p == buf ? "" : ", "));
> > So, what does this print if requires_mask is 0 (or just the target used bit
> > set but not unified_address, unified_shared_memory nor reverse_offload)?
> 
> Well, that's what libgomp/testsuite/libgomp.c-c++-common/requires-2.c (+ 
> *-2-aux.c)
> tests:
> 
> /* { dg-error "OpenMP 'requires' directive with non-identical clauses in 
> multiple compilation units: 'unified_shared_memory' vs. ''" "" { target *-*-* 
> } 0 }  */
> 
> I hope the '' vs. 'unified_shared_memory' is clear - but if you have a better 
> wording.

I must be missing how that works.  Because the buf in the callers is
uninitialized and this function doesn't store there anything if
requires_mask == 0.
Perhaps you're just lucky and the stack contains '\0' there?

> Note that both:
>   no 'omp requires'
> and
>   'omp requires' with other clauses (such as the atomic ones or 
> dynamic_allocators)
> will lead to 0. Thus, if the wording is changed, it should fit for both cases.

Maybe it would be better to simply use different error message for the
0 vs. non-0 case, canonicalized to non-0 vs. 0 order so that it is just
2 messages vs. 3 and wording like
"OpenMP 'requires' directive with '' clauses specified only in some 
compilation units"
note: specified here ...
note: but not here ...

> > > +  if (omp_requires_mask == 0)
> > > +{
> > > +  omp_requires_mask = (omp_requires) val;
> > > +  requires_decl = tmp_decl;
> > > +  requires_fn = file_data->file_name;
> > And similarly here, if some device construct is seen but requires
> > directive isn't, not sure if in this version val would be 0 or something
> > with the TARGET_USED bit set.  In the latter case, only what is printed
> > for no requires or just atomic related requires is a problem, in the former
> > case due to the == 0 check mixing of 0 with non-zero would be ignored
> > but mixing of non-zero with 0 wouldn't be.
> 
> Here: 0 = "unset" in the sense that either TARGET_USE nor USM/UA/RO was
> specified. If any of those is set, we get != 0.

Ok.
> 
> For mkoffload, the single results are merged - and TARGET_USE is stripped,
> such that it is either 0 or a combination of USM/UA/RO

I'd find it clearer if we never stripped that, so that even the library knows.
The details will depend on the resolution of #3240.
Whether say declare target and no device constructs and device related API
calls etc. force it too or not.  If not, you could get 0 even if you are
actually registering something, just not target regions.
If anything that will lead to GOMP_offload_register_ver actually means
TARGET_USED, then it isn't necessary.  But even if it isn't necessary,
e.g. for backwards compatibility with GOMP_VERSION == 1 it will be easier
to have that bit in.  0 will then mean older gcc built library or binary.

> > > +}
> > > +  else if (omp_requires_mask != val && !error_emitted)
> > > +{
> > > +  char buf[64], buf2[64];
> > Perhaps cleaner would be to size the buffers as
> > sizeof ("unified_address,unified_shared_memory,reverse_offload")
> > 64 is more, but just a wild guess and if further clauses are added later,
> > it might be too small.
> 
> I concur – except that ',' should be ', '.
> (Likewise in libgomp/target.c)

Good catch.

> > Is
> > c.c:
> > #pragma omp requires unified_shared_memory
> > d.c:
> > void baz (void) {
> >#pragma omp target
> >;
> > }
> > ok?
> 
> This one is *already* streamed out as it creates a symbol and entry in
> in offload_functions (baz.omp_fn.0).
> 
> The code is rather 

Re: RFA: Another Rust demangler recursion limit

[Jeff Law via Gcc-patches]

On 7/1/2022 9:12 AM, Nick Clifton wrote:

Hi Jeff,

   [I am sending this to your directly since you seem to be the only one
   reviewing these patches].

   Hot on the heels of the fix for the recursion problem in demangle_const
   a binutils user has filed another PoC that exposes a problem in
   demangle_path_maybe_open_generics():

https://sourceware.org/bugzilla/show_bug.cgi?id=29312#c1

   I have redirected them to file a bug report with the gcc system, but in
   the hopes of getting a fix in quickly I am also attaching a patch
   here.  It just does the obvious thing of adding a recursion counter
   and limit to the function.
OK.  And yes, I wish someone else was looking at this stuff.  Rust isn't 
really on my radar right now...


jeff

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Aldy Hernandez via Gcc-patches]

On Fri, Jul 1, 2022 at 4:58 PM Jakub Jelinek  wrote:
>
> On Fri, Jul 01, 2022 at 04:12:55PM +0200, Aldy Hernandez wrote:
> > > --- a/gcc/wide-int.h
> > > +++ b/gcc/wide-int.h
> > > @@ -1373,10 +1373,13 @@ namespace wi
> > >  : public int_traits  {};
> > >  }
> > >
> > > -/* An array of N wide_int-like objects that can be put at the end of
> > > -   a variable-sized structure.  Use extra_size to calculate how many
> > > -   bytes beyond the sizeof need to be allocated.  Use set_precision
> > > -   to initialize the structure.  */
> > > +/* A variable-lengthed array of wide_int-like objects that can be put
> > > +   at the end of a variable-sized structure.  The number of objects is
> > > +   at most N and can be set at runtime by using set_precision().
> > > +
> > > +   Use extra_size to calculate how many bytes beyond the
> > > +   sizeof need to be allocated.  Use set_precision to initialize the
> > > +   structure.  */
> > >  template 
> > >  struct GTY((user)) trailing_wide_ints
> > >  {
> > > @@ -1387,6 +1390,9 @@ private:
> > >/* The shared maximum length of each number.  */
> > >unsigned char m_max_len;
> > >
> > > +  /* The number of elements.  */
> > > +  unsigned char m_num_elements;
>
> IMNSHO you certainly don't want to change like this existing
> trailing_wide_ints, you don't want to grow unnecessarily existing
> trailing_wide_ints users (e.g. const_poly_int_def).

That's precisely what I avoided...touching existing trailing_wide_ints
users.  As I explained, there is no cost to either const_poly_int_def
or range_info_def (though I'm about to nuke the latter).  There is
some padding that is currently used by m_len[N], and I just took a
byte out to represent the run-time length.  That would affect
trailing_wide_int users that have N > 4, but none are.  The use in
const_poly_int_def uses 2 (and range_info_def uses 3):

#define NUM_POLY_INT_COEFFS 2

struct GTY((variable_size)) const_poly_int_def {
  trailing_wide_ints coeffs;
};

>
> My brief understanding of wide-int.h is that in some cases stuff like this
> is implied from template parameters or exact class instantiation and in
> other cases it is present explicitly and class inheritence is used to hide
> that stuff nicely.

Yeah, it took me a while to decipher it, but I did read it :).

>
> So, you are looking for something like trailing_wide_ints but where that
> N is actually a runtime value?  Then e.g. the
>   struct {unsigned char len;} m_len[N];
> member can't work properly either, because it isn't constant size.

What my patch does is store the run-time length in the aforementioned
byte, while defaulting to N/MAX.  There is no size difference (or code
changes) for existing users.  With my change, set_precision() and
extra_size() now take a runtime parameter, but it defaults to N and is
inlined, so there is no penalty for existing users.  I benchmarked to
make sure :).

I could hack up a variable_length_wide_int for what I want, but I'd
end up duplicating a lot of the trailing_wide_int_storage, etc.
Another option would be to stream out the HOST_WIDE_INTs in the
tree_int_cst and reconstruct things myself, but that smells of
reinventing the wheel.

Is there another way of allocating an n-bit wide-int at run-time?  I'm
happy to entertain other alternatives...

Aldy

[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 11.4/12.2/13.

[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:252e9dfee9b1d01e0e44773ad83e0e44f3650945

commit r11-10100-g252e9dfee9b1d01e0e44773ad83e0e44f3650945
Author: Jason Merrill 
Date:   Thu Jun 23 23:14:35 2022 -0400

c++: dependent generic lambda template-id [PR106024]

We were wrongly looking up the generic lambda op() in a dependent scope,
and
then trying to look up its instantiation at substitution time, but lambdas
aren't instantiated, so we crashed.  The fix is to not look into dependent
lambda scopes.

PR c++/106024

gcc/cp/ChangeLog:

* parser.c (cp_parser_lookup_name): Don't look in dependent lambda.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-generic10.C: New test.

Re: [Patch][v5] OpenMP: Move omp requires checks to libgomp

[Tobias Burnus]

On 01.07.22 16:34, Jakub Jelinek wrote:

On Fri, Jul 01, 2022 at 03:06:05PM +0200, Tobias Burnus wrote:
[...]
Will Fortran diagnose:
subroutine foo
!$omp requires unified_shared_memory
!$omp target
!$omp end target
end subroutine foo
subroutine bar
!$omp requires reverse_offload
!$omp target
!$omp end target
end subroutine bar

or just merge it from the different namespaces?


This is done in openmp.cc during parsing. The merging you quoted (in parse.cc) 
happens
after the whole input file has been parsed and resolved. For your test case, the
following error is shown:

test.f90:1:15:

1 |  subroutine foo
  |   1
Error: Program unit at (1) has OpenMP device constructs/routines but does not 
set !$OMP REQUIRES REVERSE_OFFLOAD but other program units do
test.f90:6:14:

6 | subroutine bar
  |  1
Error: Program unit at (1) has OpenMP device constructs/routines but does not 
set !$OMP REQUIRES UNIFIED_SHARED_MEMORY but other program units do



@@ -1764,6 +1781,20 @@ input_symtab (void)

  }
  }

+static void
+omp_requires_to_name (char *buf, size_t size, unsigned int requires_mask)
+{
+  char *end = buf + size, *p = buf;
+  if (requires_mask & GOMP_REQUIRES_UNIFIED_ADDRESS)
+p += snprintf (p, end - p, "unified_address");
+  if (requires_mask & GOMP_REQUIRES_UNIFIED_SHARED_MEMORY)
+p += snprintf (p, end - p, "%sunified_shared_memory",
+   (p == buf ? "" : ", "));
+  if (requires_mask & GOMP_REQUIRES_REVERSE_OFFLOAD)
+p += snprintf (p, end - p, "%sreverse_offload",
+   (p == buf ? "" : ", "));

So, what does this print if requires_mask is 0 (or just the target used bit
set but not unified_address, unified_shared_memory nor reverse_offload)?


Well, that's what libgomp/testsuite/libgomp.c-c++-common/requires-2.c (+ 
*-2-aux.c)
tests:

/* { dg-error "OpenMP 'requires' directive with non-identical clauses in multiple compilation 
units: 'unified_shared_memory' vs. ''" "" { target *-*-* } 0 }  */

I hope the '' vs. 'unified_shared_memory' is clear - but if you have a better 
wording.

Note that both:
  no 'omp requires'
and
  'omp requires' with other clauses (such as the atomic ones or 
dynamic_allocators)
will lead to 0. Thus, if the wording is changed, it should fit for both cases.


@@ -1810,6 +1847,54 @@ input_offload_tables (bool do_force_output)
  may be no refs to var_decl in offload LTO mode.  */
   if (do_force_output)
 varpool_node::get (var_decl)->force_output = 1;
+  tmp_decl = var_decl;
+}
+  else if (tag == LTO_symtab_edge)
+{
+  static bool error_emitted = false;
+  HOST_WIDE_INT val = streamer_read_hwi (ib);
+
+  if (omp_requires_mask == 0)
+{
+  omp_requires_mask = (omp_requires) val;
+  requires_decl = tmp_decl;
+  requires_fn = file_data->file_name;

And similarly here, if some device construct is seen but requires
directive isn't, not sure if in this version val would be 0 or something
with the TARGET_USED bit set.  In the latter case, only what is printed
for no requires or just atomic related requires is a problem, in the former
case due to the == 0 check mixing of 0 with non-zero would be ignored
but mixing of non-zero with 0 wouldn't be.


Here: 0 = "unset" in the sense that either TARGET_USE nor USM/UA/RO was
specified. If any of those is set, we get != 0.

For mkoffload, the single results are merged - and TARGET_USE is stripped,
such that it is either 0 or a combination of USM/UA/RO


+}
+  else if (omp_requires_mask != val && !error_emitted)
+{
+  char buf[64], buf2[64];

Perhaps cleaner would be to size the buffers as
sizeof ("unified_address,unified_shared_memory,reverse_offload")
64 is more, but just a wild guess and if further clauses are added later,
it might be too small.


I concur – except that ',' should be ', '.
(Likewise in libgomp/target.c)


@@ -1821,6 +1906,18 @@ input_offload_tables (bool do_force_output)

lto_destroy_simple_input_block (file_data, LTO_section_offload_table,
   ib, data, len);
  }
+#ifdef ACCEL_COMPILER
+  char *omp_requires_file = getenv ("GCC_OFFLOAD_OMP_REQUIRES_FILE");
+  if (omp_requires_file == NULL || omp_requires_file[0] == '\0')
+fatal_error (input_location, "GCC_OFFLOAD_OMP_REQUIRES_FILE unset");
+  FILE *f = fopen (omp_requires_file, "wb");
+  if (!f)
+fatal_error (input_location, "Cannot open omp_requires file %qs",
+ omp_requires_file);
+  uint32_t req_mask = omp_requires_mask & ~OMP_REQUIRES_TARGET_USED;

Perhaps it is better to also store the TARGET_USED bit and on the library
side completely ignore values of 0.


For the compiler side, we need to distinguish no requires vs. some
requires when checking multiple TU (to distinguish it from TU which do
not use target constructs).

But for libgomp only the result counts: no 

[Bug c++/100252] [10/11/12 Regression] Internal compiler error during template instantiation

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

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

Bug 105550 Summary: Missing copy elision with conditional operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105550

   What|Removed |Added

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

[Bug c++/105550] Missing copy elision with conditional operator

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/105550] Missing copy elision with conditional operator

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

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

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

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

commit r13-1397-gecd11acacd6be57af930fa617d7c31ecb40e7f74
Author: Marek Polacek 
Date:   Wed May 25 18:11:31 2022 -0400

c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]

In this problem, we are failing to properly perform copy elision with
a conditional operator, so this:

  constexpr A a = true ? A{} : A{};

fails with:

  error: 'A{((const A*)(&))}' is not a constant expression

The whole initializer is

  TARGET_EXPR }> : TARGET_EXPR }>>

where the outermost TARGET_EXPR is elided, but not the nested ones.
Then we end up replacing the PLACEHOLDER_EXPRs with the temporaries the
TARGET_EXPRs represent, which is precisely what should *not* happen with
copy elision.

I've tried the approach of tweaking ctx->object, but I ran into gazillion
problems with that.  I thought that I would let
cxx_eval_constant_expression
/TARGET_EXPR create a new object only when ctx->object was null, then
adjust setting of ctx->object in places like cxx_bind_parameters_in_call
and cxx_eval_component_reference but that failed completely.  Sometimes
ctx->object has to be reset, sometimes it cannot be reset, 'this' needed
special handling, etc.  I gave up.

Instead, this patch strips TARGET_EXPRs from the operands of ?: like
we do in various other places in constexpr.c.

PR c++/105550

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_conditional_expression): Strip
TARGET_EXPRs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/nsdmi-aggr16.C: Remove FIXME.
* g++.dg/cpp1y/nsdmi-aggr17.C: Remove FIXME.
* g++.dg/cpp0x/constexpr-elision1.C: New test.
* g++.dg/cpp1y/constexpr-elision1.C: New test.

Re: [PATCH 12/12 V2] arm: implement bti injection

[Richard Earnshaw via Gcc-patches]

On 28/06/2022 10:21, Andrea Corallo via Gcc-patches wrote:

Hi all,

second iteration of this patch enabling Branch Target Identification
Armv8.1-M Mechanism [1].

This is achieved by using the bti pass made common with Aarch64.

The pass iterates through the instructions and adds the necessary BTI
instructions at the beginning of every function and at every landing
pads targeted by indirect jumps.

Best Regards

   Andrea

[1]


gcc/ChangeLog

2022-04-07  Andrea Corallo  

* config.gcc (arm*-*-*): Add 'aarch-bti-insert.o' object.
* config/arm/arm-protos.h: Update.
* config/arm/arm.cc (aarch_bti_enabled, aarch_bti_j_insn_p)
(aarch_pac_insn_p, aarch_gen_bti_c, aarch_gen_bti_j): New
functions.
* config/arm/arm.md (bti_nop): New insn.
* config/arm/t-arm (PASSES_EXTRA): Add 'arm-passes.def'.
(aarch-bti-insert.o): New target.
* config/arm/unspecs.md (UNSPEC_BTI_NOP): New unspec.
* config/arm/aarch-bti-insert.cc (rest_of_insert_bti): Update
to verify arch compatibility.

gcc/testsuite/ChangeLog

2022-04-07  Andrea Corallo  

* gcc.target/arm/bti-1.c: New testcase.
* gcc.target/arm/bti-2.c: Likewise.


@@ -104,6 +105,14 @@ rest_of_insert_bti (void)
   rtx_insn *insn;
   basic_block bb;

+#if defined (TARGET_32BIT) || defined (TARGET_THUMB1)

See the comment about errors in response to patch 10.  I'd simply expect 
the gate function to be disabled when we can't support PAC, so we should 
never get here.



+  if (!arm_arch8)
+{
+  error ("This architecture does not support branch protection 
instructions");

+  goto exit;
+}
+#endif
+
...
+
+rtx aarch_gen_bti_c (void)
+{
+  return gen_bti_nop ();
+}
+
+rtx aarch_gen_bti_j (void)
+{
+  return gen_bti_nop ();
+}
+

Function names should start a new line... Thus:

rtx
aarch_gen_bti_c (void)

etc.

+(define_insn "bti_nop"
+  [(unspec_volatile [(const_int 0)] UNSPEC_BTI_NOP)]
+  "TARGET_THUMB2"

This isn't quite right.  We need v8-m.main as the baseline architecture 
for the NOPs to behave as NOPs.


+  "bti"
+  [(set_attr "type" "mov_reg")])
+

How to deal with architectural NOPs is an interesting question.  I think 
really, for the scheduler we need to describe each newly defined NOP 
separately, then in the scheduling descriptions we can handle all 
unimplemented NOPs by grouping them together for that architecture, 
whilst describing more accurately how to handle them on CPUs where they 
acquire a defined behaviour.


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 2021bdf9d2f..004e1dfa8d8 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -353,7 +353,7 @@ arc*-*-*)
;;
 arm*-*-*)
cpu_type=arm
-   extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o"
+	extra_objs="arm-builtins.o arm-mve-builtins.o aarch-common.o 
aarch-bti-insert.o"


--- a/gcc/config/arm/t-arm
+++ b/gcc/config/arm/t-arm
@@ -175,3 +175,13 @@ arm-d.o: $(srcdir)/config/arm/arm-d.cc
 arm-common.o: arm-cpu-cdata.h

 driver-arm.o: arm-native.h
+
+PASSES_EXTRA += $(srcdir)/config/arm/arm-passes.def

See comment on patch 11.  Perhaps the right thing to do is to move the 
hunk that adds arm-passes.def into this patch.

Re: [PATCH] aarch64: Fix pure/const function attributes for intrinsics

[Andrew Carlotti via Gcc-patches]

On Fri, Jul 01, 2022 at 08:42:15AM +0200, Richard Biener wrote:
> On Thu, Jun 30, 2022 at 6:04 PM Andrew Carlotti via Gcc-patches
>  wrote:
> > diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
> > b/gcc/config/aarch64/aarch64-builtins.cc
> > index 
> > e0a741ac663188713e21f457affa57217d074783..877f54aab787862794413259cd36ca0fb7bd49c5
> >  100644
> > --- a/gcc/config/aarch64/aarch64-builtins.cc
> > +++ b/gcc/config/aarch64/aarch64-builtins.cc
> > @@ -1085,9 +1085,9 @@ aarch64_get_attributes (unsigned int f, machine_mode 
> > mode)
> >if (!aarch64_modifies_global_state_p (f, mode))
> >  {
> >if (aarch64_reads_global_state_p (f, mode))
> > -   attrs = aarch64_add_attribute ("pure", attrs);
> > -  else
> > attrs = aarch64_add_attribute ("const", attrs);
> > +  else
> > +   attrs = aarch64_add_attribute ("pure", attrs);
> 
> that looks backwards.  'pure' allows read of global memory while
> 'const' does not.  Is
> aarch64_reads_global_state_p really backwards?

Oh - the thing that's backwards is my understanding of what "pure" and
"const" mean. Their meanings as GCC function attributes seem to be
approximately the opposite way round to their meanings in general usage.

Re: [PATCH 11/12] aarch64: Make bti pass generic so it can be used by the arm backend

[Richard Earnshaw via Gcc-patches]

On 28/04/2022 10:51, Andrea Corallo via Gcc-patches wrote:

Hi all,

this patch splits and restructures the aarch64 bti pass code in order
to have it usable by the arm backend as well.  These changes have no
functional impact.

Best Regards

   Andrea

gcc/Changelog

* config.gcc (aarch64*-*-*): Rename 'aarch64-bti-insert.o' into
'aarch-bti-insert.o'.
* config/aarch64/aarch64-protos.h: Remove 'aarch64_bti_enabled'
proto.
* config/aarch64/aarch64.cc (aarch_bti_enabled): Rename.
(aarch_bti_j_insn_p, aarch_pac_insn_p): New functions.
(aarch64_output_mi_thunk)
(aarch64_print_patchable_function_entry)
(aarch64_file_end_indicate_exec_stack): Update renamed function
calls to renamed functions.
* config/aarch64/t-aarch64 (aarch-bti-insert.o): Update target.
* config/arm/aarch-bti-insert.cc: New file including and
generalizing code from aarch64-bti-insert.cc.
* config/arm/aarch-common-protos.h: Update.
* config/arm/arm-passes.def: New file.



Is this patch fully stand-alone?  It adds arm-passes.def, which adds a 
reference to pass_insert_bti, but that isn't fully wired up until the 
next patch.


R.

Re: [PATCH v2] c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]

[Jason Merrill via Gcc-patches]

On 6/24/22 20:30, Marek Polacek wrote:

On Thu, Jun 02, 2022 at 05:08:54PM -0400, Jason Merrill wrote:

On 5/26/22 11:01, Marek Polacek wrote:

In this problem, we are failing to properly perform copy elision with
a conditional operator, so this:

constexpr A a = true ? A{} : A{};

fails with:

error: 'A{((const A*)(&))}' is not a constant expression

The whole initializer is

TARGET_EXPR }> : TARGET_EXPR }>>

where the outermost TARGET_EXPR is elided, but not the nested ones.
Then we end up replacing the PLACEHOLDER_EXPRs with the temporaries the
TARGET_EXPRs represent, which is precisely what should *not* happen with
copy elision.

I've tried the approach of tweaking ctx->object, but I ran into gazillion
problems with that.  I thought that I would let cxx_eval_constant_expression
/TARGET_EXPR create a new object only when ctx->object was null, then
adjust setting of ctx->object in places like cxx_bind_parameters_in_call
and cxx_eval_component_reference but that failed completely.  Sometimes
ctx->object has to be reset, sometimes it cannot be reset, 'this' needed
special handling, etc.  I gave up.

But now that we have potential_prvalue_result_of, a simple but less

elegant solution is the following.  I thought about setting a flag on
a TARGET_EXPR to avoid adding ctx.full_expr, but a new flag would be
overkill and using TARGET_EXPR_DIRECT_INIT_P broke things.


Sorry it's taken me so long to get back to this.
  

This doesn't seem like a general solution; the same issue would also apply
to ?: of TARGET_EXPR when it's a subexpression rather than the full
expression, like f(true ? A{} : B{}).


You're right.
  

Another simple approach, but more general, would be to routinely strip
TARGET_EXPR from the operands of ?: like we do in various other places in
constexpr.c.


How about this, then?

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


OK.


-- >8 --
In this problem, we are failing to properly perform copy elision with
a conditional operator, so this:

   constexpr A a = true ? A{} : A{};

fails with:

   error: 'A{((const A*)(&))}' is not a constant expression

The whole initializer is

   TARGET_EXPR }> : TARGET_EXPR }>>

where the outermost TARGET_EXPR is elided, but not the nested ones.
Then we end up replacing the PLACEHOLDER_EXPRs with the temporaries the
TARGET_EXPRs represent, which is precisely what should *not* happen with
copy elision.

I've tried the approach of tweaking ctx->object, but I ran into gazillion
problems with that.  I thought that I would let cxx_eval_constant_expression
/TARGET_EXPR create a new object only when ctx->object was null, then
adjust setting of ctx->object in places like cxx_bind_parameters_in_call
and cxx_eval_component_reference but that failed completely.  Sometimes
ctx->object has to be reset, sometimes it cannot be reset, 'this' needed
special handling, etc.  I gave up.

Instead, this patch strips TARGET_EXPRs from the operands of ?: like
we do in various other places in constexpr.c.

PR c++/105550

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_conditional_expression): Strip TARGET_EXPRs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/nsdmi-aggr16.C: Remove FIXME.
* g++.dg/cpp1y/nsdmi-aggr17.C: Remove FIXME.
* g++.dg/cpp0x/constexpr-elision1.C: New test.
* g++.dg/cpp1y/constexpr-elision1.C: New test.
---
  gcc/cp/constexpr.cc   |  7 +++
  .../g++.dg/cpp0x/constexpr-elision1.C | 16 ++
  .../g++.dg/cpp1y/constexpr-elision1.C | 53 +++
  gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr16.C |  5 +-
  gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr17.C |  5 +-
  5 files changed, 80 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-elision1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 0dc94d9445d..5f7fc6f8f0c 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -3507,6 +3507,13 @@ cxx_eval_conditional_expression (const constexpr_ctx 
*ctx, tree t,
  val = TREE_OPERAND (t, 1);
if (TREE_CODE (t) == IF_STMT && !val)
  val = void_node;
+  /* A TARGET_EXPR may be nested inside another TARGET_EXPR, but still
+ serve as the initializer for the same object as the outer TARGET_EXPR,
+ as in
+   A a = true ? A{} : A{};
+ so strip the inner TARGET_EXPR so we don't materialize a temporary.  */
+  if (TREE_CODE (val) == TARGET_EXPR)
+val = TARGET_EXPR_INITIAL (val);
return cxx_eval_constant_expression (ctx, val, lval, non_constant_p,
   overflow_p, jump_target);
  }
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C
new file mode 100644
index 000..9e7b9ec3405
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C
@@ -0,0 +1,16 @@
+// PR c++/105550
+// { dg-do compile { target c++11 

Re: [Patch] OpenMP: Handle tofrom with target enter/exit data

[Jakub Jelinek via Gcc-patches]

On Fri, Jul 01, 2022 at 05:41:27PM +0200, Tobias Burnus wrote:
> --- a/gcc/fortran/dump-parse-tree.cc
> +++ b/gcc/fortran/dump-parse-tree.cc
> @@ -1414,6 +1414,11 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
> case OMP_MAP_TO: fputs ("to:", dumpfile); break;
> case OMP_MAP_FROM: fputs ("from:", dumpfile); break;
> case OMP_MAP_TOFROM: fputs ("tofrom:", dumpfile); break;
> +   case OMP_MAP_ALWAYS_TO: fputs ("always,to:", dumpfile); break;
> +   case OMP_MAP_ALWAYS_FROM: fputs ("always,from:", dumpfile); break;
> +   case OMP_MAP_ALWAYS_TOFROM: fputs ("always,tofrom:", dumpfile); break;
> +   case OMP_MAP_DELETE: fputs ("always,tofrom:", dumpfile); break;
> +   case OMP_MAP_RELEASE: fputs ("always,tofrom:", dumpfile); break;

Pasto in the last 2 lines?

Other than that LGTM.

Jakub

Re: [PATCH 10/12 V2] arm: Implement cortex-M return signing address codegen

[Richard Earnshaw via Gcc-patches]

On 28/06/2022 10:17, Andrea Corallo via Gcc-patches wrote:

Hi all,

second version of this patch enabling address return signature and
verification based on Armv8.1-M Pointer Authentication [1].

To sign the return address, we use the PAC R12, LR, SP instruction
upon function entry.  This is signing LR using SP and storing the
result in R12.  R12 will be pushed into the stack.

During function epilogue R12 will be popped and AUT R12, LR, SP will
be used to verify that the content of LR is still valid before return.

Here an example of PAC instrumented function prologue and epilogue:

void foo (void);

int main()
{
   foo ();
   return 0;
}

Compiled with '-march=armv8.1-m.main -mbranch-protection=pac-ret
-mthumb' translates into:

main:
pac ip, lr, sp
push{r3, r7, ip, lr}
add r7, sp, #0
bl  foo
movsr3, #0
mov r0, r3
pop {r3, r7, ip, lr}
aut ip, lr, sp
bx  lr

The patch also takes care of generating a PACBTI instruction in place
of the sequence BTI+PAC when Branch Target Identification is enabled
contextually.

Ex. the previous example compiled with '-march=armv8.1-m.main
-mbranch-protection=pac-ret+bti -mthumb' translates into:

main:
pacbti  ip, lr, sp
push{r3, r7, ip, lr}
add r7, sp, #0
bl  foo
movsr3, #0
mov r0, r3
pop {r3, r7, ip, lr}
aut ip, lr, sp
bx  lr

As part of previous upstream suggestions a test for varargs has been
added and '-mtpcs-frame' is deemed being incompatible with this return
signing address feature being introduced.

[1] 


gcc/Changelog

* config/arm/arm.c: (arm_compute_frame_layout)
(arm_expand_prologue, thumb2_expand_return, arm_expand_epilogue)
(arm_conditional_register_usage): Update for pac codegen.
(arm_current_function_pac_enabled_p): New function.
* config/arm/arm.md (pac_ip_lr_sp, pacbti_ip_lr_sp, aut_ip_lr_sp):
Add new patterns.
* config/arm/unspecs.md (UNSPEC_PAC_IP_LR_SP)
(UNSPEC_PACBTI_IP_LR_SP, UNSPEC_AUT_IP_LR_SP): Add unspecs.

gcc/testsuite/Changelog

* gcc.target/arm/pac.h : New file.
* gcc.target/arm/pac-1.c : New test case.
* gcc.target/arm/pac-2.c : Likewise.
* gcc.target/arm/pac-3.c : Likewise.
* gcc.target/arm/pac-4.c : Likewise.
* gcc.target/arm/pac-5.c : Likewise.
* gcc.target/arm/pac-6.c : Likewise.
* gcc.target/arm/pac-7.c : Likewise.
* gcc.target/arm/pac-8.c : Likewise.



@@ -21139,6 +21139,14 @@ arm_compute_save_core_reg_mask (void)

   save_reg_mask |= arm_compute_save_reg0_reg12_mask ();

+  if (arm_current_function_pac_enabled_p ())
+{
+  if (TARGET_TPCS_FRAME
+ || (TARGET_TPCS_LEAF_FRAME && crtl->is_leaf))
+   error ("TPCS incompatible with return address signing.");
+  save_reg_mask |= 1 << IP_REGNUM;
+}
+

This is the wrong place for a test like this as it will be generated 
every time this function is called (which might be more than once per 
compiled function).


However, TPCS frames are only supported for 'thumb-1' code and PACBTI 
needs armv8-m.main (ie Thumb-2), so the test is really pretty pointless 
at the moment.  I think we should just drop the error.


@@ -22302,7 +22310,7 @@ arm_emit_multi_reg_pop (unsigned long 
saved_regs_mask)

 par = emit_insn (par);

   REG_NOTES (par) = dwarf;
-  if (!return_in_pc)
+  if (!return_in_pc && !frame_pointer_needed)
 arm_add_cfa_adjust_cfa_note (par, UNITS_PER_WORD * num_regs,
 stack_pointer_rtx, stack_pointer_rtx);
 }

What's this hunk for?  It doesn't seem related to the PAC changes.  Is 
this some generic bug?  If so, it should be pulled out into a separate 
patch.  If not, it needs some comment as to why we do it this way.


@@ -23352,6 +23360,11 @@ output_probe_stack_range (rtx reg1, rtx reg2)
   return "";
 }

+static bool  aarch_bti_enabled ()
+{
+  return false;
+}
+

GNU style requires the function name to be in the first column:

static bool
aarch_bti_enabled ()
{
  ...

@@ -23431,11 +23444,12 @@ arm_expand_prologue (void)
   /* The static chain register is the same as the IP register.  If it is
  clobbered when creating the frame, we need to save and restore 
it.  */

   clobber_ip = IS_NESTED (func_type)
-  && ((TARGET_APCS_FRAME && frame_pointer_needed && TARGET_ARM)
-  || ((flag_stack_check == STATIC_BUILTIN_STACK_CHECK
-   || flag_stack_clash_protection)
-  && !df_regs_ever_live_p (LR_REGNUM)
-  && arm_r3_live_at_start_p ()));
+&& (((TARGET_APCS_FRAME && frame_pointer_needed && TARGET_ARM)
+|| 

[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-8537-ge748398b3ef6412ef35b85ef6b0893809aeb49cd
Author: Jason Merrill 
Date:   Fri Jul 1 11:02:54 2022 -0400

c++: simpler fix for PR106024

Actually, for release branches let's just avoid the lookup for the lambdas
that are the problematic case and only make the bigger change on trunk.

PR c++/106024

gcc/cp/ChangeLog:

* parser.cc (cp_parser_lookup_name): Limit previous change to
lambdas.

[Patch] OpenMP: Handle tofrom with target enter/exit data

[Tobias Burnus]

Needed a break and some success. Hence, I implemented this useful and simple 
OpenMP 5.2
feature.

OK for trunk?

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: Handle tofrom with target enter/exit data

In 5.2, a map clause can be map-entering or map-exiting,
either containing 'tofrom'. The main reason for this is
permit 'map(x)' with 'omp target enter/exit data',
avoiding to specify 'to:/from:' explicitly. (OpenMP
defaults to 'tofrom'.)

gcc/c/ChangeLog:

	* c-parser.cc (c_parser_omp_target_enter_data,
	c_parser_omp_target_exit_data): Accept tofrom
	map-type modifier but use 'to' / 'from' internally.

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_omp_target_enter_data,
	cp_parser_omp_target_exit_data): Accept tofrom
	map-type modifier but use 'to' / 'from' internally.


gcc/fortran/ChangeLog:

	* dump-parse-tree.cc (show_omp_namelist): For the map-type,
	also handle the always modifer and release/delete.
	* openmp.cc (resolve_omp_clauses): Accept tofrom
	map-type modifier for target enter/exit data,
	but use 'to' / 'from' internally.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.2): Mark target enter/exit data
	with fromto as implemented.

gcc/testsuite/ChangeLog:

	* c-c++-common/gomp/target-data-2.c: New test.
	* c-c++-common/gomp/target-data-3.c: New test.
	* gfortran.dg/gomp/target-data-1.f90: New test.
	* gfortran.dg/gomp/target-data-2.f90: New test.

 gcc/c/c-parser.cc| 22 +++---
 gcc/cp/parser.cc | 22 +++---
 gcc/fortran/dump-parse-tree.cc   |  5 +
 gcc/fortran/openmp.cc| 20 
 gcc/testsuite/c-c++-common/gomp/target-data-2.c  | 20 
 gcc/testsuite/c-c++-common/gomp/target-data-3.c  | 17 +
 gcc/testsuite/gfortran.dg/gomp/target-data-1.f90 | 17 +
 gcc/testsuite/gfortran.dg/gomp/target-data-2.f90 | 14 ++
 libgomp/libgomp.texi |  2 +-
 9 files changed, 128 insertions(+), 11 deletions(-)

diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 1704a52be12..97e3b23b5d2 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -21072,6 +21072,14 @@ c_parser_omp_target_enter_data (location_t loc, c_parser *parser,
 	  case GOMP_MAP_ALLOC:
 	map_seen = 3;
 	break;
+	  case GOMP_MAP_TOFROM:
+	OMP_CLAUSE_SET_MAP_KIND (*pc, GOMP_MAP_TO);
+	map_seen = 3;
+	break;
+	  case GOMP_MAP_ALWAYS_TOFROM:
+	OMP_CLAUSE_SET_MAP_KIND (*pc, GOMP_MAP_ALWAYS_TO);
+	map_seen = 3;
+	break;
 	  case GOMP_MAP_FIRSTPRIVATE_POINTER:
 	  case GOMP_MAP_ALWAYS_POINTER:
 	  case GOMP_MAP_ATTACH_DETACH:
@@ -21080,7 +21088,7 @@ c_parser_omp_target_enter_data (location_t loc, c_parser *parser,
 	map_seen |= 1;
 	error_at (OMP_CLAUSE_LOCATION (*pc),
 		  "%<#pragma omp target enter data%> with map-type other "
-		  "than % or % on % clause");
+		  "than %, % or % on % clause");
 	*pc = OMP_CLAUSE_CHAIN (*pc);
 	continue;
 	  }
@@ -21159,6 +21167,14 @@ c_parser_omp_target_exit_data (location_t loc, c_parser *parser,
 	  case GOMP_MAP_DELETE:
 	map_seen = 3;
 	break;
+	  case GOMP_MAP_TOFROM:
+	OMP_CLAUSE_SET_MAP_KIND (*pc, GOMP_MAP_FROM);
+	map_seen = 3;
+	break;
+	  case GOMP_MAP_ALWAYS_TOFROM:
+	OMP_CLAUSE_SET_MAP_KIND (*pc, GOMP_MAP_ALWAYS_FROM);
+	map_seen = 3;
+	break;
 	  case GOMP_MAP_FIRSTPRIVATE_POINTER:
 	  case GOMP_MAP_ALWAYS_POINTER:
 	  case GOMP_MAP_ATTACH_DETACH:
@@ -21167,8 +21183,8 @@ c_parser_omp_target_exit_data (location_t loc, c_parser *parser,
 	map_seen |= 1;
 	error_at (OMP_CLAUSE_LOCATION (*pc),
 		  "%<#pragma omp target exit data%> with map-type other "
-		  "than %, % or % on %"
-		  " clause");
+		  "than %, %, % or % "
+		  "on % clause");
 	*pc = OMP_CLAUSE_CHAIN (*pc);
 	continue;
 	  }
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index da2f370cdca..e8376253a60 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -44405,6 +44405,14 @@ cp_parser_omp_target_enter_data (cp_parser *parser, cp_token *pragma_tok,
 	  case GOMP_MAP_ALLOC:
 	map_seen = 3;
 	break;
+	  case GOMP_MAP_TOFROM:
+	OMP_CLAUSE_SET_MAP_KIND (*pc, GOMP_MAP_TO);
+	map_seen = 3;
+	break;
+	  case GOMP_MAP_ALWAYS_TOFROM:
+	OMP_CLAUSE_SET_MAP_KIND (*pc, GOMP_MAP_ALWAYS_TO);
+	map_seen = 3;
+	break;
 	  case GOMP_MAP_FIRSTPRIVATE_POINTER:
 	  case GOMP_MAP_FIRSTPRIVATE_REFERENCE:
 	  case GOMP_MAP_ALWAYS_POINTER:
@@ -44414,7 +44422,7 @@ cp_parser_omp_target_enter_data (cp_parser *parser, cp_token *pragma_tok,
 	map_seen |= 1;
 	error_at (OMP_CLAUSE_LOCATION (*pc),
 		  "%<#pragma omp target 

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

[Martin Sebor via Gcc-patches]

On 7/1/22 08:01, Qing Zhao wrote:




On Jul 1, 2022, at 8:59 AM, Jakub Jelinek  wrote:

On Fri, Jul 01, 2022 at 12:55:08PM +, Qing Zhao wrote:

If so, comparing to the current implemenation to have all the checking in 
middle-end, what’s the
major benefit of moving part of the checking into FE, and leaving the other 
part in middle-end?


The point is recording early what FIELD_DECLs could be vs. can't possibly be
treated like flexible array members and just use that flag in the decisions
in the current routines in addition to what it is doing.


Okay.

Based on the discussion so far, I will do the following:

1. Add a new flag “DECL_NOT_FLEXARRAY” to FIELD_DECL;
2. In C/C++ FE, set the new flag “DECL_NOT_FLEXARRAY” for a FIELD_DECL based on 
[0], [1],
 [] and the option -fstrict-flex-array, and whether it’s the last field of 
the DECL_CONTEXT.
3. In Middle end,  Add a new utility routine is_flexible_array_member_p, which 
bases on
 DECL_NOT_FLEXARRAY + array_at_struct_end_p to decide whether the array
 reference is a real flexible array member reference.


Middle end currently is quite mess, array_at_struct_end_p, component_ref_size, 
and all the phases that
use these routines need to be updated, + new testing cases for each of the 
phases.


So, I still plan to separate the patch set into 2 parts:

   Part A:the above 1 + 2 + 3,  and use these new utilities in 
tree-object-size.cc to resolve PR101836 first.
  Then kernel can use __FORTIFY_SOURCE correctly;

   Part B:update all other phases with the new utilities + new testing 
cases + resolving regressions.

Let me know if you have any comment and suggestion.


It might be worth considering whether it should be possible to control
the "flexible array" property separately for each trailing array member
via either a #pragma or an attribute in headers that can't change
the struct layout but that need to be usable in programs compiled with
stricter -fstrict-flex-array=N settings.

Martin



Thanks a lot for all your help.

Qing



Jakub

Re: [PATCH] x86: Support 2/4/8 byte constant vector stores

[Uros Bizjak via Gcc-patches]

On Thu, Jun 30, 2022 at 4:50 PM H.J. Lu  wrote:
>
> 1. Add a predicate for constant vectors which can be converted to integer
> constants suitable for constant integer stores.  For a 8-byte constant
> vector, the converted 64-bit integer must be valid for store with 64-bit
> immediate, which is a 64-bit integer sign-extended from a 32-bit integer.
> 2. Add a new pattern to allow 2-byte, 4-byte and 8-byte constant vector
> stores, like
>
> (set (mem:V2HI (reg:DI 84))
>  (const_vector:V2HI [(const_int 0 [0]) (const_int 1 [0x1])]))
>
> 3. After reload, convert constant vector stores to constant integer
> stores, like
>
> (set (mem:SI (reg:DI 5 di [84]))
>  (const_int 65536 [0x1]))
>
> For
>
> void
> foo (short * c)
> {
>   c[0] = 0;
>   c[1] = 1;
> }
>
> it generates
>
> movl$65536, (%rdi)
>
> instead of
>
> movl.LC0(%rip), %eax
> movl%eax, (%rdi)
>
> gcc/
>
> PR target/106022
> * config/i386/i386-protos.h (ix86_convert_const_vector_to_integer):
> New.
> * config/i386/i386.cc (ix86_convert_const_vector_to_integer):
> New.
> * config/i386/mmx.md (V_16_32_64): New.
> (*mov_imm): New patterns for stores with 16-bit, 32-bit
> and 64-bit constant vector.
> * config/i386/predicates.md (x86_64_const_vector_operand): New.
>
> gcc/testsuite/
>
> PR target/106022
> * gcc.target/i386/pr106022-1.c: New test.
> * gcc.target/i386/pr106022-2.c: Likewise.
> * gcc.target/i386/pr106022-3.c: Likewise.
> * gcc.target/i386/pr106022-4.c: Likewise.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/i386-protos.h  |  2 +
>  gcc/config/i386/i386.cc| 47 ++
>  gcc/config/i386/mmx.md | 37 +
>  gcc/config/i386/predicates.md  | 11 +
>  gcc/testsuite/gcc.target/i386/pr106022-1.c | 13 ++
>  gcc/testsuite/gcc.target/i386/pr106022-2.c | 14 +++
>  gcc/testsuite/gcc.target/i386/pr106022-3.c | 14 +++
>  gcc/testsuite/gcc.target/i386/pr106022-4.c | 14 +++
>  8 files changed, 152 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-3.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr106022-4.c
>
> diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
> index 3596ce81ecf..cf847751ac5 100644
> --- a/gcc/config/i386/i386-protos.h
> +++ b/gcc/config/i386/i386-protos.h
> @@ -122,6 +122,8 @@ extern void ix86_expand_unary_operator (enum rtx_code, 
> machine_mode,
> rtx[]);
>  extern rtx ix86_build_const_vector (machine_mode, bool, rtx);
>  extern rtx ix86_build_signbit_mask (machine_mode, bool, bool);
> +extern HOST_WIDE_INT ix86_convert_const_vector_to_integer (rtx,
> +  machine_mode);
>  extern void ix86_split_convert_uns_si_sse (rtx[]);
>  extern void ix86_expand_convert_uns_didf_sse (rtx, rtx);
>  extern void ix86_expand_convert_uns_sixf_sse (rtx, rtx);
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index b15b4893bb9..0cfe9962f75 100644
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -15723,6 +15723,53 @@ ix86_build_signbit_mask (machine_mode mode, bool 
> vect, bool invert)
>return force_reg (vec_mode, v);
>  }
>
> +/* Return HOST_WIDE_INT for const vector OP in MODE.  */
> +
> +HOST_WIDE_INT
> +ix86_convert_const_vector_to_integer (rtx op, machine_mode mode)
> +{
> +  if (GET_MODE_SIZE (mode) > UNITS_PER_WORD)
> +gcc_unreachable ();
> +
> +  int nunits = GET_MODE_NUNITS (mode);
> +  wide_int val = wi::zero (GET_MODE_BITSIZE (mode));
> +  machine_mode innermode = GET_MODE_INNER (mode);
> +  unsigned int innermode_bits = GET_MODE_BITSIZE (innermode);
> +
> +  switch (mode)
> +{
> +case E_V2QImode:
> +case E_V4QImode:
> +case E_V2HImode:
> +case E_V8QImode:
> +case E_V4HImode:
> +case E_V2SImode:
> +  for (int i = 0; i < nunits; ++i)
> +   {
> + int v = INTVAL (XVECEXP (op, 0, i));
> + wide_int wv = wi::shwi (v, innermode_bits);
> + val = wi::insert (val, wv, innermode_bits * i, innermode_bits);
> +   }
> +  break;
> +case E_V2HFmode:
> +case E_V4HFmode:
> +case E_V2SFmode:
> +  for (int i = 0; i < nunits; ++i)
> +   {
> + rtx x = XVECEXP (op, 0, i);
> + int v = real_to_target (NULL, CONST_DOUBLE_REAL_VALUE (x),
> + REAL_MODE_FORMAT (innermode));
> + wide_int wv = wi::shwi (v, innermode_bits);
> + val = wi::insert (val, wv, innermode_bits * i, innermode_bits);
> +   }
> +  break;
> +default:
> +  gcc_unreachable ();
> +}
> +
> +  return val.to_shwi ();
> +}
> +
>  /* Return TRUE or FALSE 

[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Joseph S. Myers  ---
Now also applied to GCC 12 branch, so fixed for GCC 12.2.

[PATCH] i386: Use "r" constraint in *andn3_doubleword_bmi

[Uros Bizjak via Gcc-patches]

ANDN is non-destructive, so use "r" instead of "0" for its operand 1 constraint.

2022-07-01  Uroš Bizjak  

gcc/ChangeLog:

* config/i386/i386.md (*andn3_doubleword_bmi):
Use "r" constraint for operand 1.

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

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 352a21c585c..20c3b9a4122 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -10407,7 +10407,7 @@ (define_split
 (define_insn_and_split "*andn3_doubleword_bmi"
   [(set (match_operand: 0 "register_operand" "=r")
(and:
- (not: (match_operand: 1 "register_operand" "0"))
+ (not: (match_operand: 1 "register_operand" "r"))
  (match_operand: 2 "nonimmediate_operand" "ro")))
(clobber (reg:CC FLAGS_REG))]
   "TARGET_BMI"

[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Joseph Myers
:

https://gcc.gnu.org/g:962e7f0803f163f9cf44d64a2e199935d3f361fe

commit r12-8536-g962e7f0803f163f9cf44d64a2e199935d3f361fe
Author: Vladimir Makarov 
Date:   Sat May 28 12:08:38 2022 -0600

Fix ICE on sh

gcc/
PR target/103722
* config/sh/sh.cc (sh_register_move_cost): Avoid cost "2" (which
is special) for various scenarios.

(cherry picked from commit ce1580252ea57de23a595e9804ea87ed4353aa6a)

[Bug c++/106111] -Wc++20-compat doesn't warn about using `requires` as an identifier

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

RFA: Another Rust demangler recursion limit

[Nick Clifton via Gcc-patches]

Hi Jeff,

  [I am sending this to your directly since you seem to be the only one
  reviewing these patches].

  Hot on the heels of the fix for the recursion problem in demangle_const
  a binutils user has filed another PoC that exposes a problem in
  demangle_path_maybe_open_generics():

https://sourceware.org/bugzilla/show_bug.cgi?id=29312#c1

  I have redirected them to file a bug report with the gcc system, but in
  the hopes of getting a fix in quickly I am also attaching a patch
  here.  It just does the obvious thing of adding a recursion counter
  and limit to the function.

Cheers
  Nick

diff --git a/libiberty/rust-demangle.c b/libiberty/rust-demangle.c
index 36afcfae278..d6daf23af27 100644
--- a/libiberty/rust-demangle.c
+++ b/libiberty/rust-demangle.c
@@ -1082,6 +1082,18 @@ demangle_path_maybe_open_generics (struct rust_demangler *rdm)
   if (rdm->errored)
 return open;
 
+  if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+{
+  ++ rdm->recursion;
+  if (rdm->recursion > RUST_MAX_RECURSION_COUNT)
+	{
+	  /* FIXME: There ought to be a way to report
+	 that the recursion limit has been reached.  */
+	  rdm->errored = 1;
+	  goto end_of_func;
+	}
+}
+
   if (eat (rdm, 'B'))
 {
   backref = parse_integer_62 (rdm);
@@ -1107,6 +1119,11 @@ demangle_path_maybe_open_generics (struct rust_demangler *rdm)
 }
   else
 demangle_path (rdm, 0);
+
+ end_of_func:
+  if (rdm->recursion != RUST_NO_RECURSION_LIMIT)
+-- rdm->recursion;
+
   return open;
 }
 

[Bug c++/106111] -Wc++20-compat doesn't warn about using `requires` as an identifier

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

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

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

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

commit r13-1394-g2ea6c59349793761b9c00f75ef281ac413566b2f
Author: Marek Polacek 
Date:   Tue Jun 28 18:59:19 2022 -0400

c++: warn about using keywords as identifiers [PR106111]

In C++03, -Wc++11-compat should warn about

  int constexpr;

since 'constexpr' is a keyword in C++11.  Jonathan reports that
we don't emit a similar warning for 'alignas' or 'alignof', and,
as I found out, 'thread_local'.

Similarly, we don't warn for most C++20 keywords.  That happens
because RID_LAST_CXX20 hasn't been updated in a while.

PR c++/106111

gcc/c-family/ChangeLog:

* c-common.h (enum rid): Update RID_LAST_CXX20.

gcc/cp/ChangeLog:

* parser.cc (cp_lexer_get_preprocessor_token): Also warn about
RID_ALIGNOF, RID_ALIGNAS, RID_THREAD.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/keywords1.C: New test.
* g++.dg/cpp2a/keywords1.C: New test.

Re: [PATCH] c++: warn about using keywords as identifiers [PR106111]

[Jason Merrill via Gcc-patches]

On 6/29/22 12:11, Marek Polacek wrote:

In C++03, -Wc++11-compat should warn about

   int constexpr;

since 'constexpr' is a keyword in C++11.  Jonathan reports that
we don't emit a similar warning for 'alignas' or 'alignof', and,
as I found out, 'thread_local'.

Similarly, we don't warn for most C++20 keywords.  That happens
because RID_LAST_CXX20 hasn't been updated in a while.

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


OK.


PR c++/106111

gcc/c-family/ChangeLog:

* c-common.h (enum rid): Update RID_LAST_CXX20.

gcc/cp/ChangeLog:

* parser.cc (cp_lexer_get_preprocessor_token): Also warn about
RID_ALIGNOF, RID_ALIGNAS, RID_THREAD.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/keywords1.C: New test.
* g++.dg/cpp2a/keywords1.C: New test.
---
  gcc/c-family/c-common.h|  2 +-
  gcc/cp/parser.cc   | 10 +++---
  gcc/testsuite/g++.dg/cpp0x/keywords1.C | 15 +++
  gcc/testsuite/g++.dg/cpp2a/keywords1.C | 12 
  4 files changed, 35 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/keywords1.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/keywords1.C

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 47442c95a53..a1e6a55158d 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -271,7 +271,7 @@ enum rid
RID_FIRST_CXX11 = RID_CONSTEXPR,
RID_LAST_CXX11 = RID_STATIC_ASSERT,
RID_FIRST_CXX20 = RID_CONSTINIT,
-  RID_LAST_CXX20 = RID_CONSTINIT,
+  RID_LAST_CXX20 = RID_CO_RETURN,
RID_FIRST_AT = RID_AT_ENCODE,
RID_LAST_AT = RID_AT_IMPLEMENTATION,
RID_FIRST_PQ = RID_IN,
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index da2f370cdca..cc6525e0509 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -890,10 +890,14 @@ cp_lexer_get_preprocessor_token (unsigned flags, cp_token 
*token)
else
{
if (warn_cxx11_compat
-  && C_RID_CODE (token->u.value) >= RID_FIRST_CXX11
-  && C_RID_CODE (token->u.value) <= RID_LAST_CXX11)
+ && ((C_RID_CODE (token->u.value) >= RID_FIRST_CXX11
+  && C_RID_CODE (token->u.value) <= RID_LAST_CXX11)
+ /* These are outside the CXX11 range.  */
+ || C_RID_CODE (token->u.value) == RID_ALIGNOF
+ || C_RID_CODE (token->u.value) == RID_ALIGNAS
+ || C_RID_CODE (token->u.value)== RID_THREAD))
  {
-  /* Warn about the C++0x keyword (but still treat it as
+ /* Warn about the C++11 keyword (but still treat it as
   an identifier).  */
  warning_at (token->location, OPT_Wc__11_compat,
  "identifier %qE is a keyword in C++11",
diff --git a/gcc/testsuite/g++.dg/cpp0x/keywords1.C 
b/gcc/testsuite/g++.dg/cpp0x/keywords1.C
new file mode 100644
index 000..2b2ab6404ea
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/keywords1.C
@@ -0,0 +1,15 @@
+// PR c++/106111
+// { dg-do compile { target c++98_only } }
+// { dg-options "-Wc++11-compat" }
+
+int alignof; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int alignas; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int constexpr; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int decltype; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int noexcept; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int nullptr; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int static_assert; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int thread_local; // { dg-warning "is a keyword in C\\\+\\\+11" }
+int _Alignas;
+int _Alignof;
+int _Thread_local;
diff --git a/gcc/testsuite/g++.dg/cpp2a/keywords1.C 
b/gcc/testsuite/g++.dg/cpp2a/keywords1.C
new file mode 100644
index 000..7f4dba2d3b7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/keywords1.C
@@ -0,0 +1,12 @@
+// PR c++/106111
+// { dg-do compile { target c++17_down } }
+// { dg-options "-Wc++20-compat -Wc++11-compat -Wc++14-compat -Wc++17-compat" }
+
+int constinit; // { dg-warning "is a keyword in C\\\+\\\+20" }
+int consteval; // { dg-warning "is a keyword in C\\\+\\\+20" }
+int requires; // { dg-warning "is a keyword in C\\\+\\\+20" }
+int concept; // { dg-warning "is a keyword in C\\\+\\\+20" }
+int co_await; // { dg-warning "is a keyword in C\\\+\\\+20" }
+int co_yield; // { dg-warning "is a keyword in C\\\+\\\+20" }
+int co_return; // { dg-warning "is a keyword in C\\\+\\\+20" }
+int char8_t; // { dg-warning "is a keyword in C\\\+\\\+20" }

base-commit: b01c075e7e6d84da846c2ff9087433a30ebeb0d2

Re: [PATCH 9/12] arm: Make libgcc bti compatible

[Richard Earnshaw via Gcc-patches]

On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote:

This change add bti instructions at the beginning of arm specific
libgcc hand written assembly routines.

2022-03-31  Andrea Corallo  

* libgcc/config/arm/crti.S (FUNC_START): Add bti instruction if
necessary.
* libgcc/config/arm/lib1funcs.S (THUMB_FUNC_START, FUNC_START):
Likewise.



+#if defined(__ARM_FEATURE_BTI)

Wouldn't it be better to use __ARM_FEATURE_BTI_DEFAULT?  That way we 
only get BTI instructions in multilib variants that have asked for BTI.


R.

[Bug demangler/105039] rust demangler stack overflow

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

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Nick Clifton  ---
Patch applied.

[Bug demangler/105039] rust demangler stack overflow

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Nick Clifton :

https://gcc.gnu.org/g:9234cdca6ee88badfc00297e72f13dac4e540c79

commit r13-1393-g9234cdca6ee88badfc00297e72f13dac4e540c79
Author: Nick Clifton 
Date:   Fri Jul 1 15:58:52 2022 +0100

Add a recursion limit to the demangle_const function in the Rust demangler.

libiberty/
PR demangler/105039
* rust-demangle.c (demangle_const): Add recursion limit.

[Bug c++/105964] [12 Regression] Return type deduction fails during NTTP use of function dependent on template parameter

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for 12.2.

Re: [RFC] trailing_wide_ints with runtime variable lengths

[Jakub Jelinek via Gcc-patches]

On Fri, Jul 01, 2022 at 04:12:55PM +0200, Aldy Hernandez wrote:
> > --- a/gcc/wide-int.h
> > +++ b/gcc/wide-int.h
> > @@ -1373,10 +1373,13 @@ namespace wi
> >  : public int_traits  {};
> >  }
> >
> > -/* An array of N wide_int-like objects that can be put at the end of
> > -   a variable-sized structure.  Use extra_size to calculate how many
> > -   bytes beyond the sizeof need to be allocated.  Use set_precision
> > -   to initialize the structure.  */
> > +/* A variable-lengthed array of wide_int-like objects that can be put
> > +   at the end of a variable-sized structure.  The number of objects is
> > +   at most N and can be set at runtime by using set_precision().
> > +
> > +   Use extra_size to calculate how many bytes beyond the
> > +   sizeof need to be allocated.  Use set_precision to initialize the
> > +   structure.  */
> >  template 
> >  struct GTY((user)) trailing_wide_ints
> >  {
> > @@ -1387,6 +1390,9 @@ private:
> >/* The shared maximum length of each number.  */
> >unsigned char m_max_len;
> >
> > +  /* The number of elements.  */
> > +  unsigned char m_num_elements;

IMNSHO you certainly don't want to change like this existing
trailing_wide_ints, you don't want to grow unnecessarily existing
trailing_wide_ints users (e.g. const_poly_int_def).

My brief understanding of wide-int.h is that in some cases stuff like this
is implied from template parameters or exact class instantiation and in
other cases it is present explicitly and class inheritence is used to hide
that stuff nicely.

So, you are looking for something like trailing_wide_ints but where that
N is actually a runtime value?  Then e.g. the
  struct {unsigned char len;} m_len[N];
member can't work properly either, because it isn't constant size.

Jakub

[Bug c++/105908] [12 Regression] out-of-class definition of templated method with decltype in trailing return type fails to compile

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for 12.2.

[Bug c++/105541] [12 Regression] ICE: Segmentation fault when template lambda in requires-clause

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 12.2.

Re: [PATCH 8/12 V2] arm: Introduce multilibs for PACBTI target feature

[Richard Earnshaw via Gcc-patches]

On 01/07/2022 15:54, Richard Earnshaw via Gcc-patches wrote:



On 01/06/2022 13:32, Andrea Corallo via Gcc-patches wrote:

Hi all,

second iteration of the previous patch adding the following new
multilibs:

thumb/v8.1-m.main+pacbti/mbranch-protection/nofp
thumb/v8.1-m.main+pacbti+dp/mbranch-protection/soft
thumb/v8.1-m.main+pacbti+dp/mbranch-protection/hard
thumb/v8.1-m.main+pacbti+fp/mbranch-protection/soft
thumb/v8.1-m.main+pacbti+fp/mbranch-protection/hard
thumb/v8.1-m.main+pacbti+mve/mbranch-protection/hard

To trigger the following compiler flags:

-mthumb -march=armv8.1-m.main+pacbti -mbranch-protection=standard 
-mfloat-abi=soft
-mthumb -march=armv8.1-m.main+pacbti+fp -mbranch-protection=standard 
-mfloat-abi=softfp
-mthumb -march=armv8.1-m.main+pacbti+fp -mbranch-protection=standard 
-mfloat-abi=hard
-mthumb -march=armv8.1-m.main+pacbti+fp.dp 
-mbranch-protection=standard -mfloat-abi=softfp
-mthumb -march=armv8.1-m.main+pacbti+fp.dp 
-mbranch-protection=standard -mfloat-abi=hard
-mthumb -march=armv8.1-m.main+pacbti+mve -mbranch-protection=standard 
-mfloat-abi=hard


gcc/ChangeLog:

* config/arm/t-rmprofile: Add multilib rules for march +pacbti
   and mbranch-protection.



+# Map all mbranch-protection values other than 'none' to 'standard'.
+MULTILIB_MATCHES    += mbranch-protection?standard=mbranch-protection?bti
+MULTILIB_MATCHES    += 
mbranch-protection?standard=mbranch-protection?pac-ret
+MULTILIB_MATCHES    += 
mbranch-protection?standard=mbranch-protection?pac-ret+leaf
+MULTILIB_MATCHES    += 
mbranch-protection?standard=mbranch-protection?pac-ret+bti
+MULTILIB_MATCHES    += 
mbranch-protection?standard=mbranch-protection?pac-ret+leaf+bti
+MULTILIB_MATCHES    += 
mbranch-protection?standard=mbranch-protection?bti+pac-ret
+MULTILIB_MATCHES    += 
mbranch-protection?standard=mbranch-protection?bti+pac-ret+leaf

+

The documentation mentions -mbranch-protection=standard+leaf, so you're 
missing a mapping for that.



OK with that change.

R.


Oh, and please add some tests to gcc/testsuite/gcc.target/arm/multilib.exp

R.

[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly

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

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

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

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

commit r13-1392-gaefe23f720a542e90ecc6629885b01d44139b043
Author: Jason Merrill 
Date:   Fri Jul 1 00:37:10 2022 -0400

c++: tweak resolve_args change

I don't know why I used tf_error instead of complain here.

PR c++/105779

gcc/cp/ChangeLog:

* call.cc (resolve_args): Use complain.

[Bug c++/105541] [12 Regression] ICE: Segmentation fault when template lambda in requires-clause

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-8535-gb1c8ee2627696717013ebdb1ca3f5f97a76b1cb9
Author: Jason Merrill 
Date:   Wed May 11 14:53:26 2022 -0400

c++: lambda template in requires [PR105541]

Since the patch for PR103408, the template parameters for the lambda in
this
test have level 1 instead of 2, and we were treating null template args as
1
level of arguments, so tsubst_template_parms decided it had nothing to do.
Fixed by distinguishing between <> and no args at all, which is what we
have
in our "substitution" in a requires-expression.

PR c++/105541

gcc/cp/ChangeLog:

* cp-tree.h (TMPL_ARGS_DEPTH): 0 for null args.
* parser.cc (cp_parser_enclosed_template_argument_list):
Use 0-length TREE_VEC for <>.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-requires1.C: New test.

[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

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

commit r12-8534-gd9130880f77c7f9ffd5deaabda605bc151521be5
Author: Jason Merrill 
Date:   Fri Jul 1 00:37:10 2022 -0400

c++: tweak resolve_args change

I don't know why I used tf_error instead of complain here.

PR c++/105779

gcc/cp/ChangeLog:

* call.cc (resolve_args): Use complain.