Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]

[Jason Merrill via Gcc-patches]

On 10/2/21 15:06, Uecker, Martin wrote:

Am Donnerstag, den 23.09.2021, 17:37 -0400 schrieb Jason Merrill:

On 9/23/21 15:49, Uecker, Martin wrote:

Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:

On 9/5/21 15:14, Uecker, Martin wrote:

Here is the third version of the patch. This also
fixes the index zero case.  Thus, this should be
a complete fix for 91038 and should fix all cases
also supported by clang.  Still not working is
returning a struct of variable size from a
statement expression (29970) when the size depends
on computations inside the statement expression.

Bootstrapped and regression tested
on x86-64 for all languages.

Martin




Fix ICE when mixing VLAs and statement expressions [PR91038]

When returning VM-types from statement expressions, this can
lead to an ICE when declarations from the statement expression
are referred to later. Most of these issues can be addressed by
gimplifying the base expression earlier in gimplify_compound_lval.
Another issue is fixed by not reording some size-related expressions
during folding. This fixes PR91038 and some of the test cases
from PR29970 (structs with VLA members need further work).

   
   2021-08-01  Martin Uecker  
   
   gcc/

PR c/91038
PR c/29970
* gimplify.c (gimplify_var_or_parm_decl): Update comment.
(gimplify_compound_lval): Gimplify base expression first.
(gimplify_target_expr): Do not gimplify size expression.
* fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
in pointer arithmetic for variably modified types.
   
   gcc/testsuite/

PR c/91038
PR c/29970
* gcc.dg/vla-stexp-3.c: New test.
* gcc.dg/vla-stexp-4.c: New test.
* gcc.dg/vla-stexp-5.c: New test.
* gcc.dg/vla-stexp-6.c: New test.
* gcc.dg/vla-stexp-7.c: New test.
* gcc.dg/vla-stexp-8.c: New test.
* gcc.dg/vla-stexp-9.c: New test.


diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index ff23f12f33c..1e6f50692b5 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum tree_code code, 
tree type,
  return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0),
 tem);
}
-  if (TREE_CODE (arg1) == COMPOUND_EXPR)
+  /* This interleaves execution of the two sub-expressions
+which is allowed in C.  For pointer arithmetic when the
+the pointer has a variably modified type, the right expression
+might have a SAVE_EXPR which depends on the left expr, so
+do not fold in this case.  */
+  if (TREE_CODE (arg1) == COMPOUND_EXPR
+ && !(code == POINTER_PLUS_EXPR
+  && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
+  && variably_modified_type_p (type, NULL_TREE))


This seems pretty fragile.  If the problem is that the SAVE_EXPR depends
on a statement-expr on the LHS, can't that happen with expressions other
than POINTER_PLUS_EXPR?


I intentionally limited the change to this specific
case to avoid accidentally breaking or pessimizing
anything else. I did not notice any other cases that
need fixing. It is of course possible that
I have missed some...


Maybe we should include the statement-expr in the SAVE_EXPR?


I am not really sure how to implement this.


Nor am I, I'm not at all familiar with the VLA handling code.  But if
the generated trees rely on evaluation happening with a stricter order
than is actually guaranteed, that seems like a bug in the generation of
the expression trees, not the folding code.


Is there a definition about what is guaranteed?

It seems to be based on the somewhat scary
C semantics where in

(a, b) op (c, d)

evaluation order could be

a, c, b, d.


Exactly.  Or c, d, a, b, for that matter.


If I remember correctly

({ int N; int x[N];  })[0]

becomes

TARGET_EXPR  + (SAVE_EXPR  * 0)

which (somehow involving the rule above) becomes

SAVE_EXPR ; TARGET_EXPR 

It looks like the problem comes when pointer_int_sum multiplies size_exp 
by constant 0, which gets folded into a COMPOUND_EXPR, which is 
problematic here.


The simplest fix is probably for pointer_int_sum to avoid doing the 
multiplication with a 0 index.


More generally, the problem is that pointer_int_sum assumes that the 
element size can be evaluated without previously evaluating the pointer 
operand.  Given


p + sizeof(*p)*off

we could turn that into

SAVE_EXPR + (SAVE_EXPR, sizeof(*p)*off)

so that p is evaluated before sizeof(*p) regardless of transformations. 
 It probably makes sense to condition that on if sizeof(*p) is 
TREE_SIDE_EFFECTS.



Could someone that knows more about VLA weigh in?



Maybe we could apply this patch first (because
I have to work around this bug in a couple of
projects which is a bit annoying)? I am happy
to implement an alternative later if there is
a better way (which I can understand).


The 

Re: [PATCH, v2] c++: Implement C++23 P2334R1 - #elifdef/#elifndef

[Jason Merrill via Gcc-patches]

On 10/5/21 16:24, Jakub Jelinek wrote:

On Tue, Oct 05, 2021 at 05:23:26PM +, Joseph Myers wrote:

One is in the patch below, ignores that sentence and only implements it
for -std=c++23/-std=gnu++23 like it is only implemented for -std=c23.
Another option would be to implement it also in the older GNU modes but
not in the C/CXX modes (but it would be strange if we did that just for
C++ and not for C).
Yet another option is to enable it unconditionally.
And yet another option would be to enable it unconditionally but emit
a warning (or pedwarn) when it is seen.
Note, when it is enabled for the older language modes, as Joseph wrote
in the c11-elifdef-1.c testcase, it can result e.g. in rejecting previously
valid code:


It would probably be reasonable to enable it in older GNU modes for C as
well as C++ if desired (and, in that case, emit a pedwarn-if-pedantic when
it's acted on) - cases where it affects compatibility should be rare.
Enabling with a pedwarn in strict modes is problematic because it changes
semantics of valid code where it was inside #if 0, however.  It doesn't
make sense at all to me to think of a new feature like this (one with no
prior art in C mentioned in the WG14 proposal) as a defect fix.

Any normal directive - i.e. one that has no effect on the preprocessor #if
structure and so is ignored inside #if 0 for all language versions - can
more reasonably be enabled for all language versions with a pedwarn when
used for old versions.  (In particular, that will be appropriate for
#warning, where the "don't pedwarn in C2X modes" part needs implementing
after N2686 was accepted at the August / September WG14 meeting - I don't
know if C++ is doing anything with #warning.)


Ok, here is an updated version which accepts them in both
CPP_OPTION (pfile, elifdef) (aka -std={gnu,c}{2x,++2b,++23} modes) or
!CPP_OPTION (pfile, std) (aka -std=gnu* modes), but for the latter
pedwarns if pedantic (but only if the directive actually changes the
preprocessing behavior or if it would be rejected with corresponding
-std=c*).
The second hunk in directives.c is for the cases where it would otherwise
error about unknown directive, the third hunk is for the case where it
changes the skipping state.  If pfile->state.skipping is true before
encountering the directive and after it as well, then whether the directive
is there or not makes no difference.


LGTM.


2021-10-05  Jakub Jelinek  

libcpp/
* init.c (lang_defaults): Implement P2334R1, enable elifdef for
-std=c++23 and -std=gnu++23.
* directives.c (_cpp_handle_directive): Support elifdef/elifndef if
either CPP_OPTION (pfile, elifdef) or !CPP_OPTION (pfile, std).
(do_elif): For older non-std modes if pedantic pedwarn about
#elifdef/#elifndef directives that change behavior.
gcc/testsuite/
* gcc.dg/cpp/gnu11-elifdef-1.c: New test.
* gcc.dg/cpp/gnu11-elifdef-2.c: New test.
* gcc.dg/cpp/gnu11-elifdef-3.c: New test.
* gcc.dg/cpp/gnu11-elifdef-4.c: New test.
* g++.dg/cpp/elifdef-1.C: New test.
* g++.dg/cpp/elifdef-2.C: New test.
* g++.dg/cpp/elifdef-3.C: New test.
* g++.dg/cpp/elifdef-4.C: New test.
* g++.dg/cpp/elifdef-5.C: New test.
* g++.dg/cpp/elifdef-6.C: New test.
* g++.dg/cpp/elifdef-7.C: New test.

--- libcpp/init.c.jj2021-09-02 10:01:15.954715595 +0200
+++ libcpp/init.c   2021-10-05 09:55:15.010620700 +0200
@@ -122,8 +122,8 @@ static const struct lang_flags lang_defa
/* CXX17*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1, 
1, 0,   1,  0,   1, 0,   0,   0 },
/* GNUCXX20 */  { 1,  1,  1,  1,  1,  0,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   0,   0 },
/* CXX20*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   0,   0 },
-  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   0 },
-  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   0 },
+  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   1 },
+  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   1 },
/* ASM  */  { 0,  0,  1,  0,  0,  0,0,  0,   0,   0,   0,0, 
0, 0,   0,  0,   0, 0,   0,   0 }
  };
  
--- libcpp/directives.c.jj	2021-05-12 09:44:55.080621650 +0200

+++ libcpp/directives.c 2021-10-05 22:05:52.303984796 +0200
@@ -447,7 +447,11 @@ _cpp_handle_directive (cpp_reader *pfile
if (dname->val.node.node->is_directive)
{
  dir = [dname->val.node.node->directive_index];
- if ((dir->flags & ELIFDEF) && !CPP_OPTION (pfile, elifdef))
+ if ((dir->flags & ELIFDEF)
+ && !CPP_OPTION 

Re: [PATCH, v2] c++: Implement C++23 P2242R3 - Non-literal variables (and labels and gotos) in constexpr functions

[Jason Merrill via Gcc-patches]

On 10/5/21 18:24, Jakub Jelinek wrote:

On Tue, Oct 05, 2021 at 05:24:09PM -0400, Jason Merrill wrote:

That seems correct to me.  If they have static initialization, they are
initialized.


Ok, I've included those tests in the patch now too.

@@ -8736,14 +8765,14 @@ potential_constant_expression_1 (tree t,
 tmp = DECL_EXPR_DECL (t);
 if (VAR_P (tmp) && !DECL_ARTIFICIAL (tmp))
{
- if (TREE_STATIC (tmp))
+ if (TREE_STATIC (tmp) && cxx_dialect < cxx23)
{
  if (flags & tf_error)
error_at (DECL_SOURCE_LOCATION (tmp), "%qD declared "
  "% in % context", tmp);
  return false;
}
- else if (CP_DECL_THREAD_LOCAL_P (tmp))
+ else if (CP_DECL_THREAD_LOCAL_P (tmp) && cxx_dialect < cxx23)
{
  if (flags & tf_error)
error_at (DECL_SOURCE_LOCATION (tmp), "%qD declared "


Hmm, I wouldn't expect this hunk to be needed; if there's a control path
that doesn't include these declarations, we shouldn't hit these errors.


You're right, that is unnecessary, if the static/thread_local declaration
is unconditional, we can (but aren't required to) diagnose it even when
the constexpr function is never evaluated in constant expressions.
But, I had to swap the TREE_STATIC and CP_DECL_THREAD_LOCAL_P checks
because the latter implies the former and so static would be always
printed instead of thread_local for thread_local declarations.


@@ -9025,7 +9054,7 @@ potential_constant_expression_1 (tree t,
   case LABEL_EXPR:
 t = LABEL_EXPR_LABEL (t);
-  if (DECL_ARTIFICIAL (t))
+  if (DECL_ARTIFICIAL (t) || cxx_dialect >= cxx23)
return true;
 else if (flags & tf_error)
error_at (loc, "label definition is not a constant expression");


Let's change this message to "only available with..." like the others.


Changed too.

Here is an updated patch (also after IRC chat with Jonathan changed
the __cpp_constexpr value from 202103L that was in the paper to 202110L).
Passes the tests that are modified so far, full bootstrap/regtest
queued after my current one finishes.


OK.


2021-10-06  Jakub Jelinek  

gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): For -std=c++23 predefine
__cpp_constexpr to 202110L rather than 201907L.
gcc/cp/
* parser.c (cp_parser_jump_statement): Implement C++23 P2242R3.
Allow goto expressions in constexpr function bodies for C++23.
Adjust error message for older standards to mention it.
* decl.c (start_decl): Allow static and thread_local declarations
in constexpr function bodies for C++23.  Adjust error message for
older standards to mention it.
* constexpr.c (ensure_literal_type_for_constexpr_object): Allow
declarations of variables with non-literal type in constexpr function
bodies for C++23.  Adjust error message for older standards to mention
it.
(cxx_eval_constant_expression) : Diagnose declarations
of initialization of static or thread_local vars.
(cxx_eval_constant_expression) : Diagnose goto
statements for C++23.
(potential_constant_expression_1) : Swap the
CP_DECL_THREAD_LOCAL_P and TREE_STATIC checks.
(potential_constant_expression_1) : Allow labels for
C++23.  Adjust error message for older standards to mention it.
gcc/testsuite/
* g++.dg/cpp23/feat-cxx2b.C: Expect __cpp_constexpr 202110L rather
than 201907L.
* g++.dg/cpp23/constexpr-nonlit1.C: New test.
* g++.dg/cpp23/constexpr-nonlit2.C: New test.
* g++.dg/cpp23/constexpr-nonlit3.C: New test.
* g++.dg/cpp23/constexpr-nonlit4.C: New test.
* g++.dg/cpp23/constexpr-nonlit5.C: New test.
* g++.dg/cpp23/constexpr-nonlit6.C: New test.
* g++.dg/diagnostic/constexpr1.C: Only expect some diagnostics for
c++20_down.
* g++.dg/cpp1y/constexpr-label.C: Likewise.
* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
* g++.dg/cpp2a/constexpr-try5.C: Likewise.  Adjust some expected
wording.
* g++.dg/cpp2a/constexpr-dtor3.C: Likewise.
* g++.dg/cpp2a/consteval3.C: Likewise.  Add effective target c++20
and remove dg-options.

--- gcc/c-family/c-cppbuiltin.c.jj  2021-10-05 22:27:39.387959561 +0200
+++ gcc/c-family/c-cppbuiltin.c 2021-10-05 23:47:13.865054265 +0200
@@ -1052,7 +1052,8 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_init_captures=201803L");
  cpp_define (pfile, "__cpp_generic_lambdas=201707L");
  cpp_define (pfile, "__cpp_designated_initializers=201707L");
- cpp_define (pfile, "__cpp_constexpr=201907L");
+ if (cxx_dialect <= cxx20)
+   cpp_define (pfile, "__cpp_constexpr=201907L");
  cpp_define (pfile, "__cpp_constexpr_in_decltype=201711L");
  cpp_define (pfile, 

[PATCH, v5] c++: Fix up synthetization of defaulted comparison operators on classes with bitfields [PR102490]

[Jason Merrill via Gcc-patches]

On 10/1/21 11:07, Jakub Jelinek wrote:

On Thu, Sep 30, 2021 at 03:01:49PM -0400, Jason Merrill wrote:

After fixing the incomplete std::strong_ordering spaceship-synth8.C is now
accepted, but I'm afraid I'm getting lost in this - clang++ rejects that
testcase instead complaining that D has <=> operator, but has it pure virtual.


Ah, I think we need to add LOOKUP_NO_VIRTUAL to the flags variable, as we do
in do_build_copy_assign.  I suppose it wouldn't hurt to add LOOKUP_DEFAULTED
as well.


I've tried that (see patch below), but neither in build_comparison_op, nor
in genericize_spaceship those changes made any difference for
spaceship-synth8.C, it is still accepted instead of rejected.


I've switched to handling bases via binfo as discussed on IRC and added 
spaceship-synth14.C to test proper base handling with virtual <=>. 
Here's what I'm committing:
From dd8421dd37fad0a3f0a5572bcbf142ff22a79297 Mon Sep 17 00:00:00 2001
From: Jakub Jelinek 
Date: Fri, 1 Oct 2021 17:07:17 +0200
Subject: [PATCH] c++: defaulted <=> with bitfields [PR102490]
To: gcc-patches@gcc.gnu.org

The testcases in the patch are either miscompiled or ICE with checking,
because the defaulted operator== is synthesized too early (but only if
constexpr), when the corresponding class type is still incomplete type.  The
problem is that at that point the bitfield FIELD_DECLs still have as
TREE_TYPE their underlying type rather than integral type with their
precision and when layout_class_type is called for the class soon after
that, it changes those types but the COMPONENT_REFs type stay the way that
they were during the operator== synthesize_method type and the middle-end is
then upset by the mismatch of types.  As what exact type will be given isn't
just a one liner but quite long code especially for over-sized bitfields, I
think it is best to just not synthesize the comparison operators so early
and call defaulted_late_check for them once again as soon as the class is
complete.

This is also a problem for virtual operator<=>, where we need to compare the
noexcept-specifier to validate the override before the class is complete.
Rather than try to defer that comparison, maybe_instantiate_noexcept now
calls maybe_synthesize_method, which calls build_comparison_op in
non-defining mode if the class isn't complete yet.  In that situation we
also might not have base fields yet, so we look in the binfo for the bases.

Co-authored-by: Jason Merrill 

2021-10-01  Jakub Jelinek  

	PR c++/98712
	PR c++/102490
	* cp-tree.h (maybe_synthesize_method): Declare.
	* method.c (genericize_spaceship): Use
	LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
	LOOKUP_NORMAL for flags.
	(comp_info): Remove defining member.  Add complain, code, retcat.
	(comp_info::comp_info): Adjust.
	(do_one_comp): Split out from build_comparison_op.   Use
	LOOKUP_NORMAL | LOOKUP_NONVIRTUAL | LOOKUP_DEFAULTED instead of
	LOOKUP_NORMAL for flags.
	(build_comparison_op): Add defining argument. Adjust comp_info
	construction.  Use defining instead of info.defining.  Assert that
	if defining, ctype is a complete type.  Walk base binfos.
	(synthesize_method, maybe_explain_implicit_delete,
	explain_implicit_non_constexpr): Adjust build_comparison_op callers.
	(maybe_synthesize_method): New function.
	* class.c (check_bases_and_members): Don't call defaulted_late_check
	for sfk_comparison.
	(finish_struct_1): Call it here instead after class has been
	completed.
	* pt.c (maybe_instantiate_noexcept): Call maybe_synthesize_method
	instead of synthesize_method.

	* g++.dg/cpp2a/spaceship-synth8.C (std::strong_ordering): Provide
	more complete definition.
	(std::strong_ordering::less, std::strong_ordering::equal,
	std::strong_ordering::greater): Define.
	* g++.dg/cpp2a/spaceship-synth12.C: New test.
	* g++.dg/cpp2a/spaceship-synth13.C: New test.
	* g++.dg/cpp2a/spaceship-synth14.C: New test.
	* g++.dg/cpp2a/spaceship-eq11.C: New test.
	* g++.dg/cpp2a/spaceship-eq12.C: New test.
	* g++.dg/cpp2a/spaceship-eq13.C: New test.
---
 gcc/cp/cp-tree.h  |   1 +
 gcc/cp/class.c|  13 +-
 gcc/cp/method.c   | 240 +++---
 gcc/cp/pt.c   |   2 +-
 gcc/testsuite/g++.dg/cpp2a/spaceship-eq11.C   |  43 
 gcc/testsuite/g++.dg/cpp2a/spaceship-eq12.C   |   5 +
 gcc/testsuite/g++.dg/cpp2a/spaceship-eq13.C   |  22 ++
 .../g++.dg/cpp2a/spaceship-synth12.C  |  24 ++
 .../g++.dg/cpp2a/spaceship-synth13.C  |  29 +++
 .../g++.dg/cpp2a/spaceship-synth14.C  |  26 ++
 gcc/testsuite/g++.dg/cpp2a/spaceship-synth8.C |  13 +-
 11 files changed, 328 insertions(+), 90 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-eq11.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-eq12.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-eq13.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-synth12.C
 create mode 100644 

Re: [PATCH] libiberty: prevent buffer overflow when decoding user input

[Eric Gallager via Gcc-patches]

On Tue, Oct 5, 2021 at 1:28 PM Luís Ferreira  wrote:
>
> On Tue, 2021-10-05 at 09:00 -0600, Jeff Law wrote:
> >
> >
> > On 10/4/2021 10:52 AM, Luís Ferreira wrote:
> > > On Thu, 2021-09-23 at 09:50 -0600, Jeff Law wrote:
> > > >
> > > > On 9/23/2021 4:16 AM, ibuclaw--- via Gcc-patches wrote:
> > > > > > On 22/09/2021 03:10 Luís Ferreira 
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > > Currently a stack/heap overflow may happen if a crafted
> > > > > > mangle is
> > > > > > maliciously used to cause denial of service, such as
> > > > > > intentional
> > > > > > crashes
> > > > > > by accessing a reserved memory space.
> > > > > >
> > > > > Hi,
> > > > >
> > > > > Thanks for this.  Is there a test that could trigger this code
> > > > > path?
> > > > I don't think Luis has commit privs, so I went ahead and
> > > > committed
> > > > this
> > > > patch.
> > > >
> > > > Yea, a testcase would be great.
> > > >
> > > > Jeff
> > > >
> > > Does the test suite runned against address sanitization? if yes, I
> > > can
> > > submit a patch to make this fail, otherwise it is hard to trigger a
> > > consistent crash for this issue.
> > Unfortunately, no it doesn't run with sanitization.  If it's too
> > painful
> > to create a test, don't worry about it.  It happens from time to
> > time.
> >
> > jeff
>
> I would like to add address sanitization if I knew how GCC autotools
> work but I think this is a better fit when I invest some time
> implementing something to OSS fuzz and build some infrastructure for
> fuzzing parts of the GCC.
>

I can help with the autotools part if you can say how precisely you'd
like to use them to add address sanitization. And as for the OSS
fuzz part, I think someone tried setting up auto-fuzzing for it once,
but the main bottleneck was getting the bug reports that it generated
properly triaged, so if you could make sure the bug-submitting portion
of the process is properly streamlined, that'd probably go a long way
towards helping it be useful.

> --
> Sincerely,
> Luís Ferreira @ lsferreira.net
>

Re: [PATCH] c++: odr-use argument to a function NTTP [PR53164]

[Jason Merrill via Gcc-patches]

On 10/5/21 15:17, Patrick Palka wrote:

On Mon, 4 Oct 2021, Patrick Palka wrote:


When passing a function template as the argument to a function NTTP
inside a template, we resolve it to the right specialization ahead of
time via resolve_address_of_overloaded_function, though the call to
mark_used within defers odr-using it until instantiation time (as usual).
But at instantiation time we end up never calling mark_used on the
specialization.

This patch fixes this by adding a call to mark_used in
convert_nontype_argument_function.

PR c++/53164

gcc/cp/ChangeLog:

* pt.c (convert_nontype_argument_function): Call mark_used.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent16.C: New test.
---
  gcc/cp/pt.c |  3 +++
  gcc/testsuite/g++.dg/template/non-dependent16.C | 16 
  2 files changed, 19 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/template/non-dependent16.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f950f4a21b7..5e819c9598c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6668,6 +6668,9 @@ convert_nontype_argument_function (tree type, tree expr,
return NULL_TREE;
  }
  
+  if (!mark_used (fn_no_ptr, complain) && !(complain & tf_error))

+return NULL_TREE;
+
linkage = decl_linkage (fn_no_ptr);
if (cxx_dialect >= cxx11 ? linkage == lk_none : linkage != lk_external)
  {
diff --git a/gcc/testsuite/g++.dg/template/non-dependent16.C 
b/gcc/testsuite/g++.dg/template/non-dependent16.C
new file mode 100644
index 000..b7dca8f6752
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/non-dependent16.C
@@ -0,0 +1,16 @@
+// PR c++/53164
+
+template
+void f(T) {
+  T::fail; // { dg-error "not a member" }
+}
+
+template
+struct A { };
+
+template
+void g() {
+  A a;
+}


I should mention that the original testcase in the PR was slightly
different than this one in that it also performed a call to the NTTP,
e.g.

   template
   struct A {
 static void h() {
   p(0);
 }
   };

   template
   void g() {
 A::h();
   }

   templated void g<0>();

and not even the call was enough to odr-use f, apparently because the
CALL_EXPR case of tsubst_expr calls mark_used on the callee only when
it's a FUNCTION_DECL, but in this case after substitution it's an
ADDR_EXPR of a FUNCTION_DECL.  Fixing this by looking through the ADDR_EXPR
worked, but IIUC the call isn't necessary for f to be odr-used, simply
using f as a template argument should be sufficient, so it seems the
above is better fix.


I agree that pedantically the use happens when substituting into the use 
of A, but convert_nontype_argument_function seems like a weird place 
to implement that; it's only called again during instantiation of A, 
when we instantiate the injected-class-name.  If A isn't 
instantiated, e.g. if 'a' is a pointer to A, we again don't 
instantiate f.


I see that clang doesn't reject your testcase, either, but MSVC and icc 
do (even with 'a' a pointer): https://godbolt.org/z/MGE6TcMch


Jason

[PATCH v2] Improve integer bit test on __atomic_fetch_[or|and]_* returns

[H.J. Lu via Gcc-patches]

On Tue, Oct 5, 2021 at 9:40 AM H.J. Lu  wrote:
>
> On Tue, Oct 5, 2021 at 3:07 AM Richard Biener  wrote:
> >
> > On Mon, 4 Oct 2021, H.J. Lu wrote:
> >
> > > commit adedd5c173388ae505470df152b9cb3947339566
> > > Author: Jakub Jelinek 
> > > Date:   Tue May 3 13:37:25 2016 +0200
> > >
> > > re PR target/49244 (__sync or __atomic builtins will not emit 'lock 
> > > bts/btr/btc')
> > >
> > > optimized bit test on atomic builtin return with lock bts/btr/btc.  But
> > > it works only for unsigned integers since atomic builtins operate on the
> > > 'uintptr_t' type.  It fails on bool:
> > >
> > >   _1 = atomic builtin;
> > >   _4 = (_Bool) _1;
> > >
> > > and signed integers:
> > >
> > >   _1 = atomic builtin;
> > >   _2 = (int) _1;
> > >   _5 = _2 & (1 << N);
> > >
> > > Improve bit test on atomic builtin return by converting:
> > >
> > >   _1 = atomic builtin;
> > >   _4 = (_Bool) _1;
> > >
> > > to
> > >
> > >   _1 = atomic builtin;
> > >   _5 = _1 & (1 << 0);
> > >   _4 = (_Bool) _5;
> > >
> > > and converting:
> > >
> > >   _1 = atomic builtin;
> > >   _2 = (int) _1;
> > >   _5 = _2 & (1 << N);
> > >
> > > to
> > >   _1 = atomic builtin;
> > >   _6 = _1 & (1 << N);
> > >   _5 = (int) _6;
> >
> > Why not do this last bit with match.pd patterns (and independent on
> > whether _1 is defined by an atomic builtin)?  For the first suggested
>
> The full picture is
>
>  _1 = _atomic_fetch_or_* (ptr_6, mask, _3);
>   _2 = (int) _1;
>   _5 = _2 & mask;
>
> to
>
>   _1 = _atomic_fetch_or_* (ptr_6, mask, _3);
>   _6 = _1 & mask;
>   _5 = (int) _6;
>
> It is useful only if 2 masks are the same.
>
> > transform that's likely going to be undone by folding, no?
> >
>
> The bool case is
>
>   _1 = __atomic_fetch_or_* (ptr_6, 1, _3);
>   _4 = (_Bool) _1;
>
> to
>
>   _1 = __atomic_fetch_or_* (ptr_6, 1, _3);
>   _5 = _1 & 1;
>   _4 = (_Bool) _5;
>
> Without __atomic_fetch_or_*, the conversion isn't needed.
> After the conversion, optimize_atomic_bit_test_and will
> immediately optimize the code sequence to
>
>   _6 = .ATOMIC_BIT_TEST_AND_SET (, 0, 0, 0);
>   _4 = (_Bool) _6;
>
> and there is nothing to fold after it.
>

Here is the v2 patch to handle more cases.


-- 
H.J.
From 5e72aa847ddc73754d821b96c508c3892f523d4b Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sun, 3 Oct 2021 09:43:00 -0700
Subject: [PATCH v2] Improve integer bit test on __atomic_fetch_[or|and]_*
 returns

commit adedd5c173388ae505470df152b9cb3947339566
Author: Jakub Jelinek 
Date:   Tue May 3 13:37:25 2016 +0200

re PR target/49244 (__sync or __atomic builtins will not emit 'lock bts/btr/btc')

optimized bit test on __atomic_fetch_or_* and __atomic_fetch_and_* returns
with lock bts/btr/btc by turning

  mask_2 = 1 << cnt_1;
  _4 = __atomic_fetch_or_* (ptr_6, mask_2, _3);
  _5 = _4 & mask_2;

into

  _4 = ATOMIC_BIT_TEST_AND_SET (ptr_6, cnt_1, 0, _3);
  _5 = _4;

and

  mask_6 = 1 << bit_5(D);
  _1 = ~mask_6;
  _2 = __atomic_fetch_and_4 (v_8(D), _1, 0);
  _3 = _2 & mask_6;
  _4 = _3 != 0;

into

  mask_6 = 1 << bit_5(D);
  _1 = ~mask_6;
  _11 = .ATOMIC_BIT_TEST_AND_RESET (v_8(D), bit_5(D), 1, 0);
  _4 = _11 != 0;

But it failed to optimize when there is a cast.  Improve this optimization
by transforming the IR to meet the required conditions if possible:

1. Transform

  _1 = __atomic_fetch_or_4 (ptr_6, 1, _3);
  _4 = (_Bool) _1;

to

  _1 = __atomic_fetch_or_4 (ptr_6, 1, _3);
  _5 = _1 & 1;
  _4 = (_Bool) _5;

or

  _1 = __atomic_fetch_and_4 (ptr_6, ~1, _3);
  _4 = (_Bool) _1;

to

  _1 = __atomic_fetch_and_4 (ptr_6, ~1, _3);
  _5 = _1 & 1;
  _4 = (_Bool) _5;

2. Transform

  _1 = __atomic_fetch_or_4 (ptr_6, 1, _3);
  _7 = ~_1;
  _5 = (_Bool) _7;

to

  _1 = __atomic_fetch_or_4 (ptr_6, 1, _3);
  _7 = _1 & 1;
  _5 = _7 == 0;

or

  _1 = __atomic_fetch_and_4 (ptr_6, ~1, _3);
  _7 = ~_1;
  _5 = (_Bool) _7;

to

  _1 = __atomic_fetch_and_4 (ptr_6, ~1, _3);
  _7 = _1 & 1;
  _5 = _7 == 0;

3. Transform

  _1 = __atomic_fetch_or_4 (ptr_6, 1, _3);
  _2 = (int) _1;
  _7 = ~_2;
  _5 = (_Bool) _7;

to

  _1 = __atomic_fetch_or_4 (ptr_6, 1, _3);
  _7 = _1 & 1;
  _5 = _7 == 0;

or

  _1 = __atomic_fetch_and_4 (ptr_6, ~1, _3);
  _2 = (int) _1;
  _7 = ~_2;
  _5 = (_Bool) _7;

to

  _1 = __atomic_fetch_and_4 (ptr_6, ~1, _3);
  _7 = _1 & 1;
  _5 = _7 == 0;

4. Transform

  _1 = _atomic_fetch_or_4 (ptr_6, mask, _3);
  _2 = (int) _1;
  _5 = _2 & mask;

to

  _1 = _atomic_fetch_or_4 (ptr_6, mask, _3);
  _6 = _1 & mask;
  _5 = (int) _6;

5. Transform

  _1 = __atomic_fetch_or_4 (ptr_6, 0x8000, _3);
  _5 = (signed int) _1;
  _4 = _5 < 0;

to

  _1 = __atomic_fetch_or_4 (ptr_6, 0x8000, _3);
  _6 = _1 & 0x8000;
  _4 = _6 != 0;

or

  _1 = __atomic_fetch_and_4 (ptr_6, 0x7fff, _3);
  _5 = (signed int) _1;
  _4 = _5 < 0;

to

  _1 = __atomic_fetch_and_4 (ptr_6, 0x7fff, _3);
  _6 = _1 & 0x8000;
  _4 = _6 != 0;

6. Extract the bit mask from

  _1 = 1 << bit_4(D);
  mask_5 = (unsigned int) _1;
  _2 = __atomic_fetch_or_4 (v_7(D), mask_5, 0);
  _3 = 

Re: [patch][middle-end/PR102359]Not add initialization for DECL_VALUE_EXPR variables with -ftrivial-auto-var-init

[Qing Zhao via Gcc-patches]

> On Oct 5, 2021, at 1:30 PM, Jason Merrill  wrote:
> 
>>> 'decl_had_value_expr_p' and check && !decl_had_value_expr_p here?
>>> So sth like
>> I can do this -:) I agree that the change will make the code simpler.
>> However, my major concern with this change is: later when people look at 
>> this change, they might ask:
>> Why we should not initialize a variable with VALUE_EXPR? And whether the 
>> variable whose VALUE_EXPR
>> was created by “gimplify_vla_decl” should be excluded?
>> My new function and comments were all for this purpose.
>> If I go with this change, at least we should add some comments to explain 
>> this as following, what do you think?
>>> 
>>> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
>>> index b27776af7c8..9013f385f13 100644
>>> --- a/gcc/gimplify.c
>>> +++ b/gcc/gimplify.c
>>> @@ -1872,6 +1872,7 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
>>> {
>>>   tree init = DECL_INITIAL (decl);
>>>   bool is_vla = false;
>>+ /* Check whether a decl has FE created VALUE_EXPR here BEFORE
>>+  gimplify_vla_decl creates VALUE_EXPR for vla decl.  */
>>> +  bool decl_had_value_expr_p = DECL_HAS_VALUE_EXPR_P (decl);
>>> 
>>>   poly_uint64 size;
>>>   if (!poly_int_tree_p (DECL_SIZE_UNIT (decl), )
>>> @@ -1934,7 +1935,8 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
>>>   /* When there is no explicit initializer, if the user requested,
>>> We should insert an artifical initializer for this automatic
>>> variable.  */
>>> -  else if (is_var_need_auto_init (decl))
>>> +  else if (is_var_need_auto_init (decl)
>> +   /* If the VAR_DECL has DECL_VALUE_EXPR that was created by FE (usually 
>> C++FE),
>> +   it's a proxy varaible, and FE already initializd the DECL_VALUE_EXPR of 
>> it. */
> 
> I'd suggest merging this comment into the comment on the variable declaration.

Okay, will merge these two comments into one and put it on the variable 
declaration.

thanks.

Qing

[PATCH] ctfc: Free CTF type and CTF variable objects in ctfc_delete_container ()

[Indu Bhagat via Gcc-patches]

Hello,

This patch fixes an outstanding issue with memory cleanup in the CTF container.
Earlier the two hash tables in the CTF container were not cleaned up in
ctfc_delete_container ().  With this patch, we first free up the CTF type and
CTF variable entries in the hash_table slots, followed by emptying of the hash
tables.

Bootstrapped and regression tested on x86_64.

Thanks



Free up the memory held by CTF type and CTF variable objects after CTF debug
information has been emitted.  In ctfc_delete_container (), traverse the
hash_table of CTF types and CTF variables and free the memory held by the
respective objects.

gcc/ChangeLog:

* ctfc.c (free_ctf_dtdef_cb): New function.
(free_ctf_dvdef_cb): Likewise.
(ctfc_delete_container): Free hash table contents.
---
 gcc/ctfc.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/gcc/ctfc.c b/gcc/ctfc.c
index 73c118e..1f961c9 100644
--- a/gcc/ctfc.c
+++ b/gcc/ctfc.c
@@ -179,6 +179,26 @@ ctf_dvd_lookup (const ctf_container_ref ctfc, dw_die_ref 
die)
   return NULL;
 }
 
+/* Callback function to free the CTF type from hash table.  */
+
+static int
+free_ctf_dtdef_cb (ctf_dtdef_ref * slot, void * arg ATTRIBUTE_UNUSED)
+{
+  if (slot && *slot)
+ggc_free (*slot);
+  return 1;
+}
+
+/* Callback function to free the CTF variable from hash table.  */
+
+static int
+free_ctf_dvdef_cb (ctf_dvdef_ref * slot, void * arg ATTRIBUTE_UNUSED)
+{
+  if (slot && *slot)
+ggc_free (*slot);
+  return 1;
+}
+
 /* Append member definition to the list.  Member list is a singly-linked list
with list start pointing to the head.  */
 
@@ -944,11 +964,16 @@ ctfc_delete_strtab (ctf_strtable_t * strtab)
 void
 ctfc_delete_container (ctf_container_ref ctfc)
 {
-  /* FIXME - CTF container can be cleaned up now.
- Will the ggc machinery take care of cleaning up the container structure
- including the hash_map members etc. ?  */
   if (ctfc)
 {
+  ctfc->ctfc_types->traverse (NULL);
+  ctfc->ctfc_types->empty ();
+  ctfc->ctfc_types = NULL;
+
+  ctfc->ctfc_vars->traverse (NULL);
+  ctfc->ctfc_vars->empty ();
+  ctfc->ctfc_types = NULL;
+
   ctfc_delete_strtab (>ctfc_strtable);
   ctfc_delete_strtab (>ctfc_aux_strtable);
   if (ctfc->ctfc_vars_list)
-- 
1.8.3.1

[PATCH, v2] c++: Implement C++23 P2242R3 - Non-literal variables (and labels and gotos) in constexpr functions

[Jakub Jelinek via Gcc-patches]

On Tue, Oct 05, 2021 at 05:24:09PM -0400, Jason Merrill wrote:
> That seems correct to me.  If they have static initialization, they are
> initialized.

Ok, I've included those tests in the patch now too.
> > @@ -8736,14 +8765,14 @@ potential_constant_expression_1 (tree t,
> > tmp = DECL_EXPR_DECL (t);
> > if (VAR_P (tmp) && !DECL_ARTIFICIAL (tmp))
> > {
> > - if (TREE_STATIC (tmp))
> > + if (TREE_STATIC (tmp) && cxx_dialect < cxx23)
> > {
> >   if (flags & tf_error)
> > error_at (DECL_SOURCE_LOCATION (tmp), "%qD declared "
> >   "% in % context", tmp);
> >   return false;
> > }
> > - else if (CP_DECL_THREAD_LOCAL_P (tmp))
> > + else if (CP_DECL_THREAD_LOCAL_P (tmp) && cxx_dialect < cxx23)
> > {
> >   if (flags & tf_error)
> > error_at (DECL_SOURCE_LOCATION (tmp), "%qD declared "
> 
> Hmm, I wouldn't expect this hunk to be needed; if there's a control path
> that doesn't include these declarations, we shouldn't hit these errors.

You're right, that is unnecessary, if the static/thread_local declaration
is unconditional, we can (but aren't required to) diagnose it even when
the constexpr function is never evaluated in constant expressions.
But, I had to swap the TREE_STATIC and CP_DECL_THREAD_LOCAL_P checks
because the latter implies the former and so static would be always
printed instead of thread_local for thread_local declarations.

> > @@ -9025,7 +9054,7 @@ potential_constant_expression_1 (tree t,
> >   case LABEL_EXPR:
> > t = LABEL_EXPR_LABEL (t);
> > -  if (DECL_ARTIFICIAL (t))
> > +  if (DECL_ARTIFICIAL (t) || cxx_dialect >= cxx23)
> > return true;
> > else if (flags & tf_error)
> > error_at (loc, "label definition is not a constant expression");
> 
> Let's change this message to "only available with..." like the others.

Changed too.

Here is an updated patch (also after IRC chat with Jonathan changed
the __cpp_constexpr value from 202103L that was in the paper to 202110L).
Passes the tests that are modified so far, full bootstrap/regtest
queued after my current one finishes.

2021-10-06  Jakub Jelinek  

gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): For -std=c++23 predefine
__cpp_constexpr to 202110L rather than 201907L.
gcc/cp/
* parser.c (cp_parser_jump_statement): Implement C++23 P2242R3.
Allow goto expressions in constexpr function bodies for C++23.
Adjust error message for older standards to mention it.
* decl.c (start_decl): Allow static and thread_local declarations
in constexpr function bodies for C++23.  Adjust error message for
older standards to mention it.
* constexpr.c (ensure_literal_type_for_constexpr_object): Allow
declarations of variables with non-literal type in constexpr function
bodies for C++23.  Adjust error message for older standards to mention
it.
(cxx_eval_constant_expression) : Diagnose declarations
of initialization of static or thread_local vars.
(cxx_eval_constant_expression) : Diagnose goto
statements for C++23.
(potential_constant_expression_1) : Swap the
CP_DECL_THREAD_LOCAL_P and TREE_STATIC checks.
(potential_constant_expression_1) : Allow labels for
C++23.  Adjust error message for older standards to mention it.
gcc/testsuite/
* g++.dg/cpp23/feat-cxx2b.C: Expect __cpp_constexpr 202110L rather
than 201907L.
* g++.dg/cpp23/constexpr-nonlit1.C: New test.
* g++.dg/cpp23/constexpr-nonlit2.C: New test.
* g++.dg/cpp23/constexpr-nonlit3.C: New test.
* g++.dg/cpp23/constexpr-nonlit4.C: New test.
* g++.dg/cpp23/constexpr-nonlit5.C: New test.
* g++.dg/cpp23/constexpr-nonlit6.C: New test.
* g++.dg/diagnostic/constexpr1.C: Only expect some diagnostics for
c++20_down.
* g++.dg/cpp1y/constexpr-label.C: Likewise.
* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
* g++.dg/cpp2a/constexpr-try5.C: Likewise.  Adjust some expected
wording.
* g++.dg/cpp2a/constexpr-dtor3.C: Likewise.
* g++.dg/cpp2a/consteval3.C: Likewise.  Add effective target c++20
and remove dg-options.

--- gcc/c-family/c-cppbuiltin.c.jj  2021-10-05 22:27:39.387959561 +0200
+++ gcc/c-family/c-cppbuiltin.c 2021-10-05 23:47:13.865054265 +0200
@@ -1052,7 +1052,8 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_init_captures=201803L");
  cpp_define (pfile, "__cpp_generic_lambdas=201707L");
  cpp_define (pfile, "__cpp_designated_initializers=201707L");
- cpp_define (pfile, "__cpp_constexpr=201907L");
+ if (cxx_dialect <= cxx20)
+   cpp_define (pfile, "__cpp_constexpr=201907L");
  cpp_define (pfile, "__cpp_constexpr_in_decltype=201711L");
  cpp_define (pfile, 

Go patch committed: Use nullptr in a couple of cases

[Ian Lance Taylor via Gcc-patches]

This Go frontend patch by Than McIntosh uses nullptr in a couple of
cases to avoid errors in template matching with some stage1 compilers.
Bootstrapped on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
patch
f4da52d91658cf73eb95d3d8b4b0fd79c8b0ac23
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 7eea97765c3..affba73e4bb 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-bbc1effb1a8a757a38011074f1d4477fae3936f5
+925ace70ac7426c3f8b5c0bfb75aa9601f071de4
 
 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/types.cc b/gcc/go/gofrontend/types.cc
index c6ce6230c58..0f1937c 100644
--- a/gcc/go/gofrontend/types.cc
+++ b/gcc/go/gofrontend/types.cc
@@ -2259,7 +2259,7 @@ Named_object*
 Type::build_equal_function(Gogo* gogo, Named_type* name, int64_t size,
   Function_type* equal_fntype)
 {
-  std::pair val(name != NULL ? name : this, NULL);
+  std::pair val(name != NULL ? name : this, nullptr);
   std::pair ins =
 Type::type_equal_functions_table.insert(val);
   if (!ins.second)
@@ -6413,7 +6413,7 @@ Struct_type::interface_method_table(Interface_type* 
interface,
bool is_pointer)
 {
   std::pair
-val(this, NULL);
+val(this, nullptr);
   std::pair ins =
 Struct_type::struct_method_tables.insert(val);
 

Re: [PATCH v3] libgcc: Add a backchain fallback to _Unwind_Backtrace() on PowerPC

[Segher Boessenkool]

On Tue, Oct 05, 2021 at 03:32:52PM -0300, Raphael Moreira Zinsly wrote:
> Without dwarf2 unwind tables available _Unwind_Backtrace() is not
> able to return the full backtrace.
> This patch adds a fallback function on powerpc to get the backtrace
> by doing a backchain, this code was originally at glibc.
> 
> libgcc/ChangeLog:
> 
>   * config/rs6000/linux-unwind.h (struct rt_sigframe): Move it to
>   outside of get_regs() in order to use it in another function, this
>   is done twice: for __powerpc64__ and for !__powerpc64__.
>   (struct trace_arg): New struct.
>   (struct layout): New struct.
>   (ppc_backchain_fallback): New function.
>   * unwind.inc (_Unwind_Backtrace): Look for _URC_NORMAL_STOP code
>   state and call MD_BACKCHAIN_FALLBACK.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/powerpc/unwind-backchain.c: New test.
> ---
>  .../gcc.target/powerpc/unwind-backchain.c |  24 +
>  libgcc/config/rs6000/linux-unwind.h   | 102 +++---
>  libgcc/unwind.inc |  14 ++-
>  3 files changed, 124 insertions(+), 16 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/powerpc/unwind-backchain.c

So what is new or different in v3 compared to v2?


Segher

Re: [PATCH] c++: Implement C++23 P2242R3 - Non-literal variables (and labels and gotos) in constexpr functions

[Jason Merrill via Gcc-patches]

On 10/5/21 08:39, Jakub Jelinek wrote:

Hi!

The following patch implements C++23 P2242R3 - Non-literal variables
(and labels and gotos) in constexpr functions.
I think it is mostly straightforward, don't diagnose certain
statements/declarations just because of their presence in
constexpr/consteval functions, but (except for the non-literal type
var declarations which ought to be caught by e.g. constructor or
destructor call during evaluation not being constexpr and for
labels which are now always allowed) diagnose it during constexpr
evaluation.

The only unclear thing to me is "a control flow that passes through a
declaration".  The patch implements diagnostics when encountering a
DECL_EXPR for such variables.  But because constexpr/consteval functions
support switch statements, another thing that can happen is jump over
such a declaration.  Consider e.g. following testcase (not included
in the patch).  When evaluating foo (12) or bar (12) the patch
accepts those as constant expressions, eventhough it jumps across such
declarations.  For baz (12) and corge (12) it rejects them not
because of jumping across such declarations, but because those
static or thread_local variables aren't initialized with constant
expressions and are accessed.  If baz/corge is modified not to have
const keyword, they are rejected because the vars aren't aren't const.
If they have const keyword and are initialized by constant expression,
accesses to those vars are accepted.  Is that ok?


That seems correct to me.  If they have static initialization, they are 
initialized.


Some comments in the patch below.


So far regtested with
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make -j32 -k check-g++
ok for trunk if it passes full bootstrap/regtest?

// { dg-do compile }
// { dg-options "-std=c++2b" }

int qux ();

constexpr int
foo (int x)
{
   switch (x)
 {
   static int bar = qux ();
 case 12:
   return 1;
 }
   return 0;
}

constexpr int
bar (int x)
{
   switch (x)
 {
   thread_local int bar = qux ();
 case 12:
   return 1;
 }
   return 0;
}

constexpr int
baz (int x)
{
   switch (x)
 {
   static const int bar = qux ();   // { dg-message "'bar' was not initialized 
with a constant expression" }
 case 12:
   return bar;
 }
   return 0;
}

constexpr int
corge (int x)
{
   switch (x)
 {
   const thread_local int bar = qux (); // { dg-message "'bar' was not 
initialized with a constant expression" }
 case 12:
   return bar;
 }
   return 0;
}

constexpr int a = foo (12);
constexpr int b = bar (12);
constexpr int c = baz (12); // { dg-error "the value of 'bar' is not 
usable in a constant expression" }
constexpr int d = corge (12);   // { dg-error "the value of 'bar' is not 
usable in a constant expression" }


2021-10-05  Jakub Jelinek  

gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): For -std=c++23 predefine
__cpp_constexpr to 202103L rather than 201907L.
gcc/cp/
* parser.c (cp_parser_jump_statement): Implement C++23 P2242R3.
Allow goto expressions in constexpr function bodies for C++23.
Adjust error message for older standards to mention it.
* decl.c (start_decl): Allow static and thread_local declarations
in constexpr function bodies for C++23.  Adjust error message for
older standards to mention it.
* constexpr.c (ensure_literal_type_for_constexpr_object): Allow
declarations of variables with non-literal type in constexpr function
bodies for C++23.  Adjust error message for older standards to mention
it.
(cxx_eval_constant_expression) : Diagnose declarations
of initialization of static or thread_local vars.
(cxx_eval_constant_expression) : Diagnose goto
statements for C++23.
(potential_constant_expression_1) : Allow declarations
of static and thread_local vars for C++23.
(potential_constant_expression_1) : Allow labels for
C++23.
gcc/testsuite/
* g++.dg/cpp23/feat-cxx2b.C: Expect __cpp_constexpr 202103L rather
than 201907L.
* g++.dg/cpp23/constexpr-nonlit1.C: New test.
* g++.dg/cpp23/constexpr-nonlit2.C: New test.
* g++.dg/cpp23/constexpr-nonlit3.C: New test.
* g++.dg/diagnostic/constexpr1.C: Only expect some diagnostics for
c++20_down.
* g++.dg/cpp1y/constexpr-label.C: Likewise.
* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
* g++.dg/cpp2a/constexpr-try5.C: Likewise.  Adjust some expected
wording.
* g++.dg/cpp2a/constexpr-dtor3.C: Likewise.
* g++.dg/cpp2a/consteval3.C: Likewise.  Add effective target c++20
and remove dg-options.

--- gcc/c-family/c-cppbuiltin.c.jj  2021-09-21 23:31:01.016248936 +0200
+++ gcc/c-family/c-cppbuiltin.c 2021-10-05 12:54:29.898321379 +0200
@@ -1052,7 +1052,8 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, 

[PATCH, v2] c++: Implement C++23 P2334R1 - #elifdef/#elifndef

[Jakub Jelinek via Gcc-patches]

On Tue, Oct 05, 2021 at 05:23:26PM +, Joseph Myers wrote:
> > One is in the patch below, ignores that sentence and only implements it
> > for -std=c++23/-std=gnu++23 like it is only implemented for -std=c23.
> > Another option would be to implement it also in the older GNU modes but
> > not in the C/CXX modes (but it would be strange if we did that just for
> > C++ and not for C).
> > Yet another option is to enable it unconditionally.
> > And yet another option would be to enable it unconditionally but emit
> > a warning (or pedwarn) when it is seen.
> > Note, when it is enabled for the older language modes, as Joseph wrote
> > in the c11-elifdef-1.c testcase, it can result e.g. in rejecting previously
> > valid code:
> 
> It would probably be reasonable to enable it in older GNU modes for C as 
> well as C++ if desired (and, in that case, emit a pedwarn-if-pedantic when 
> it's acted on) - cases where it affects compatibility should be rare.  
> Enabling with a pedwarn in strict modes is problematic because it changes 
> semantics of valid code where it was inside #if 0, however.  It doesn't 
> make sense at all to me to think of a new feature like this (one with no 
> prior art in C mentioned in the WG14 proposal) as a defect fix.
> 
> Any normal directive - i.e. one that has no effect on the preprocessor #if 
> structure and so is ignored inside #if 0 for all language versions - can 
> more reasonably be enabled for all language versions with a pedwarn when 
> used for old versions.  (In particular, that will be appropriate for 
> #warning, where the "don't pedwarn in C2X modes" part needs implementing 
> after N2686 was accepted at the August / September WG14 meeting - I don't 
> know if C++ is doing anything with #warning.)

Ok, here is an updated version which accepts them in both
CPP_OPTION (pfile, elifdef) (aka -std={gnu,c}{2x,++2b,++23} modes) or
!CPP_OPTION (pfile, std) (aka -std=gnu* modes), but for the latter
pedwarns if pedantic (but only if the directive actually changes the
preprocessing behavior or if it would be rejected with corresponding
-std=c*).
The second hunk in directives.c is for the cases where it would otherwise
error about unknown directive, the third hunk is for the case where it
changes the skipping state.  If pfile->state.skipping is true before
encountering the directive and after it as well, then whether the directive
is there or not makes no difference.

2021-10-05  Jakub Jelinek  

libcpp/
* init.c (lang_defaults): Implement P2334R1, enable elifdef for
-std=c++23 and -std=gnu++23.
* directives.c (_cpp_handle_directive): Support elifdef/elifndef if
either CPP_OPTION (pfile, elifdef) or !CPP_OPTION (pfile, std).
(do_elif): For older non-std modes if pedantic pedwarn about
#elifdef/#elifndef directives that change behavior.
gcc/testsuite/
* gcc.dg/cpp/gnu11-elifdef-1.c: New test.
* gcc.dg/cpp/gnu11-elifdef-2.c: New test.
* gcc.dg/cpp/gnu11-elifdef-3.c: New test.
* gcc.dg/cpp/gnu11-elifdef-4.c: New test.
* g++.dg/cpp/elifdef-1.C: New test.
* g++.dg/cpp/elifdef-2.C: New test.
* g++.dg/cpp/elifdef-3.C: New test.
* g++.dg/cpp/elifdef-4.C: New test.
* g++.dg/cpp/elifdef-5.C: New test.
* g++.dg/cpp/elifdef-6.C: New test.
* g++.dg/cpp/elifdef-7.C: New test.

--- libcpp/init.c.jj2021-09-02 10:01:15.954715595 +0200
+++ libcpp/init.c   2021-10-05 09:55:15.010620700 +0200
@@ -122,8 +122,8 @@ static const struct lang_flags lang_defa
   /* CXX17*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1, 
1, 0,   1,  0,   1, 0,   0,   0 },
   /* GNUCXX20 */  { 1,  1,  1,  1,  1,  0,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   0,   0 },
   /* CXX20*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   0,   0 },
-  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   0 },
-  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   0 },
+  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   1 },
+  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   1 },
   /* ASM  */  { 0,  0,  1,  0,  0,  0,0,  0,   0,   0,   0,0, 
0, 0,   0,  0,   0, 0,   0,   0 }
 };
 
--- libcpp/directives.c.jj  2021-05-12 09:44:55.080621650 +0200
+++ libcpp/directives.c 2021-10-05 22:05:52.303984796 +0200
@@ -447,7 +447,11 @@ _cpp_handle_directive (cpp_reader *pfile
   if (dname->val.node.node->is_directive)
{
  dir = [dname->val.node.node->directive_index];
- if ((dir->flags & ELIFDEF) && !CPP_OPTION (pfile, elifdef))
+ if ((dir->flags & ELIFDEF)
+  

Re[2]: [PATCH] Fix check C99 TR1 support

[mkh199740]

Thank you, for your fast response.

> There are some cross-compilation cases
> where we can't link, and that's why we only
> use AC_TRY_COMPILE.

May you give me some examples of this cases? 

I had some problems when tries to create toolchain with ulibc-ng and gcc11 for 
armv5. 

The problem is that libstdc++ is build with undefined  fesetround/fegetround 
symbols. And compilation of hello-world via this toolchain is fails.

This situation may be avoided if libstdc++ checks presence of this symbols at 
the configuration step.

I accepts that it may be a problem of ulibc-ng.  But I don’t know for sure. 


What do you think? 


вторник, 5 октября 2021 г., 6:12 PM +0300 от Jonathan Wakely  
:
>On Tue, 5 Oct 2021 at 11:32, Petr Mikhalicin wrote:
>>
>> Autotools tests for libstdc++ check only declaration of required
>> symbols, but some symbols may not be defined.
>>
>> This patch adds trying to link "C99 TR1" tests, not only compile them.
>Thanks for the patch.
>
>N.B. patches for libstdc++ should also be sent to the gcc-patches
>list, see  https://gcc.gnu.org/contribute.html#patches and
>https://gcc.gnu.org/lists.html
>
>I don't think this patch is OK though. There are some
>cross-compilation cases where we can't link, and that's why we only
>use AC_TRY_COMPILE.
>
>>
>> Signed-off-by: Petr Mikhalicin < mkh199...@mail.ru >
>> ---
>>  libstdc++-v3/acinclude.m4 | 16 
>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
>> index 90ecc4a87a2..8bf8b884a7c 100644
>> --- a/libstdc++-v3/acinclude.m4
>> +++ b/libstdc++-v3/acinclude.m4
>> @@ -1645,7 +1645,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>>ac_c99_complex_tr1=no;
>>if test x"$ac_has_complex_h" = x"yes"; then
>>  AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
>> -AC_TRY_COMPILE([#include ],
>> +AC_TRY_LINK(   [#include ],
>>[typedef __complex__ float float_type; float_type tmpf;
>> cacosf(tmpf);
>> casinf(tmpf);
>> @@ -1680,7 +1680,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>># Check for the existence of  functions.
>>AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
>>AC_CACHE_VAL(glibcxx_cv_c99_ctype_tr1, [
>> -  AC_TRY_COMPILE([#include ],
>> +  AC_TRY_LINK(   [#include ],
>>  [int ch;
>>   int ret;
>>   ret = isblank(ch);
>> @@ -1699,7 +1699,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>>ac_c99_fenv_tr1=no;
>>if test x"$ac_has_fenv_h" = x"yes"; then
>>  AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
>> -AC_TRY_COMPILE([#include ],
>> +AC_TRY_LINK(   [#include ],
>>[int except, mode;
>> fexcept_t* pflag;
>> fenv_t* penv;
>> @@ -1727,7 +1727,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>># Check for the existence of  types.
>>AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
>>AC_CACHE_VAL(glibcxx_cv_c99_stdint_tr1, [
>> -  AC_TRY_COMPILE([#define __STDC_LIMIT_MACROS
>> +  AC_TRY_LINK(   [#define __STDC_LIMIT_MACROS
>>   #define __STDC_CONSTANT_MACROS
>>   #include ],
>>  [typedef int8_t  my_int8_t;
>> @@ -1827,7 +1827,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>># Check for the existence of  functions.
>>AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
>>AC_CACHE_VAL(glibcxx_cv_c99_math_tr1, [
>> -  AC_TRY_COMPILE([#include ],
>> +  AC_TRY_LINK(   [#include ],
>>  [typedef double_t  my_double_t;
>>   typedef float_t   my_float_t;
>>   acosh(0.0);
>> @@ -1949,7 +1949,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>>darwin*)
>>  AC_MSG_CHECKING([for ISO C99 rounding functions in ])
>>  AC_CACHE_VAL(glibcxx_cv_c99_math_llround, [
>> -  AC_TRY_COMPILE([#include ],
>> +AC_TRY_LINK([#include ],
>>  [llrint(0.0);
>>   llrintf(0.0f);
>>   llrintl(0.0l);
>> @@ -1974,7 +1974,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>>ac_c99_inttypes_tr1=no;
>>if test x"$glibcxx_cv_c99_stdint_tr1" = x"yes"; then
>>  AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
>> -AC_TRY_COMPILE([#include ],
>> +AC_TRY_LINK(   [#include ],
>>[intmax_t i, numer, denom, base;
>> const char* s;
>> char** endptr;
>> @@ -1996,7 +1996,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
>>ac_c99_inttypes_wchar_t_tr1=no;
>>if test x"$glibcxx_cv_c99_stdint_tr1" = x"yes"; then
>>  AC_MSG_CHECKING([for wchar_t ISO C99 support to TR1 in ])
>> -AC_TRY_COMPILE([#include ],
>> +AC_TRY_LINK(   [#include ],
>>[intmax_t base;
>> const wchar_t* s;
>> wchar_t** endptr;
>> --
>> 2.31.1
>>
>

Re: [Patch] Fortran: Fix deprecate warning with parameter

[Tobias Burnus]

Hi Harald,

On 05.10.21 21:10, Harald Anlauf wrote:

Am 05.10.21 um 20:03 schrieb Tobias Burnus:

Played around with the warning in the 'omp_lib' module (needs tweaking
as for the current version, no warning is done). Turned out that already
   use omp_lib
outputs a warning even when not used.


that must have been a non-trivial example; I didn't see that on my
installation.


The example is trivial – but as written, you need to tweak the module.

libgomp/omp_lib.f90.in has:
...
#if _OPENMP >= 202011
!GCC$ ATTRIBUTES DEPRECATED :: omp_proc_bind_master
#endif

That file is compiled with '-fopenmp -cpp' and _OPENMP is set to
201511 (= OpenMP 4.5) but the parameter is only deprecated in
OpenMP 5.1 (202011). Thus, you only see this warning (with -Wall)
when either the OpenMP version is bumped - or as I did it:
when commenting the version checks.

Tobias

PS: I will commit the patch tomorrow. Thanks for the review.

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

Re: [committed] d: gdc driver ignores -static-libstdc++ when automatically linking libstdc++ library

[Iain Sandoe]

Hi Iain,

> On 5 Oct 2021, at 09:02, ibuc...@gdcproject.org wrote:
> 
>> On 04/10/2021 18:48 Iain Sandoe  wrote:
>> 
>> For targets that don’t support HAVE_LD_STATIC_DYNAMIC it would be useful
>> to push the option back out, so that they can use that to substitute a 
>> static version
>> of the library using %:replace-outfile(-lx libx+.a%s) [ see darwin.h 
>> for 
>> examples. ] .. I suppose we could figure out a follow-on patch and test that 
>> on
>> Darwin?
>> 
>> so
>> #else
>> … code to push the -libstdc++ out
>> 
>> (yes, we do have this problem also with the g++ driver… I posted a patch eons
>> ago .. but suspect it was never applied)
>> 
> 
> Sure, seems reasonable to me, will follow up.

as it happens the current state breaks Darwin bootstrap, there’s a “set but 
unused”.

fixed by https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581016.html

if that fix is acceptible, then we can backport it to the branches too - which 
will also be broken; if not then we should shake down an alternate soon.

> I had a look at darwin.h, and it occurs to me that you probably will be 
> wanting -static-libphobos added there as well, which means moving that option 
> to common.opt.

could be; but the fix above at least provides independent control over the 
static-libstdc++ situation (which tends to be more problematic on Darwin, since 
libstdc++ (latest) is always co-installed with the system’s (very old) version.

Iain

[pushed] Darwin, D: Fix bootstrap when target does not support -Bstatic/dynamic.

[Iain Sandoe via Gcc-patches]

This fixes a bootstrap fail because saw_static_libcxx was unused for
targets without support for -Bstatic/dynamic.

The fix applied pushes the -static-libstdc++ back onto the command
line, which allows a target to substitute a static version of the
c++ standard library using specs.

tested on x86_64-darwin, pushed as bootstrap fix (it, or an alternate
will also be needed on open branches), thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/d/ChangeLog:

* d-spec.cc (lang_specific_driver): Push the -static-libstdc++
option back onto the command line for targets without support
for -Bstatic/dynamic.
---
 gcc/d/d-spec.cc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/d/d-spec.cc b/gcc/d/d-spec.cc
index 5adc662c6f2..b12d28f1047 100644
--- a/gcc/d/d-spec.cc
+++ b/gcc/d/d-spec.cc
@@ -468,6 +468,12 @@ lang_specific_driver (cl_decoded_option 
**in_decoded_options,
  generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
   _decoded_options[j++]);
}
+#else
+  /* Push the -static-libstdc++ option back onto the command so that
+a target without LD_STATIC_DYNAMIC can use outfile substitution.  */
+  if (saw_static_libcxx && !static_link)
+   generate_option (OPT_static_libstdc__, NULL, 1, CL_DRIVER,
+_decoded_options[j++]);
 #endif
   if (saw_libcxx)
new_decoded_options[j++] = *saw_libcxx;
-- 
2.24.3 (Apple Git-128)

Re: [PATCH] c++: Suppress error when cv-qualified reference is introduced by typedef [PR101783]

[Jason Merrill via Gcc-patches]

On 10/1/21 15:52, Nick Huang wrote:

...the subject line for the commit should be the first line of the
commit message, followed by a blank line, followed by the description of
the patch; without the subject line, git format-patch thought your whole
description was the subject of the patch.


oh,  I didn't realize this without your mentioning it. I read this guide
(https://gcc.gnu.org/codingconventions.html#ChangeLogs) many times
and still don't get this. I guess it was written long long ago.


FYI that's a git thing, not a ChangeLog thing.  From the git 
format-patch manual:



   By default, the subject of a single patch is "[PATCH] " followed by the
   concatenation of lines from the commit message up to the first blank
   line (see the DISCUSSION section of git-commit(1)).


And from git-commit(1):


   Though not required, it’s a good idea to begin the commit message with
   a single short (less than 50 character) line summarizing the change,
   followed by a blank line and then a more thorough description. The text
   up to the first blank line in a commit message is treated as the commit
   title, and that title is used throughout Git. For example, git-format-
   patch(1) turns a commit into email, and it uses the title on the
   Subject line and the rest of the commit in the body.
But yes, it would be good to give more of this instruction in the gcc 
contribute.html.


Jason

Re: [PATCH] c++: odr-use argument to a function NTTP [PR53164]

[Patrick Palka via Gcc-patches]

On Mon, 4 Oct 2021, Patrick Palka wrote:

> When passing a function template as the argument to a function NTTP
> inside a template, we resolve it to the right specialization ahead of
> time via resolve_address_of_overloaded_function, though the call to
> mark_used within defers odr-using it until instantiation time (as usual).
> But at instantiation time we end up never calling mark_used on the
> specialization.
> 
> This patch fixes this by adding a call to mark_used in
> convert_nontype_argument_function.
> 
>   PR c++/53164
> 
> gcc/cp/ChangeLog:
> 
>   * pt.c (convert_nontype_argument_function): Call mark_used.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/template/non-dependent16.C: New test.
> ---
>  gcc/cp/pt.c |  3 +++
>  gcc/testsuite/g++.dg/template/non-dependent16.C | 16 
>  2 files changed, 19 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/template/non-dependent16.C
> 
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index f950f4a21b7..5e819c9598c 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -6668,6 +6668,9 @@ convert_nontype_argument_function (tree type, tree expr,
>return NULL_TREE;
>  }
>  
> +  if (!mark_used (fn_no_ptr, complain) && !(complain & tf_error))
> +return NULL_TREE;
> +
>linkage = decl_linkage (fn_no_ptr);
>if (cxx_dialect >= cxx11 ? linkage == lk_none : linkage != lk_external)
>  {
> diff --git a/gcc/testsuite/g++.dg/template/non-dependent16.C 
> b/gcc/testsuite/g++.dg/template/non-dependent16.C
> new file mode 100644
> index 000..b7dca8f6752
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/non-dependent16.C
> @@ -0,0 +1,16 @@
> +// PR c++/53164
> +
> +template
> +void f(T) {
> +  T::fail; // { dg-error "not a member" }
> +}
> +
> +template
> +struct A { };
> +
> +template
> +void g() {
> +  A a;
> +}

I should mention that the original testcase in the PR was slightly
different than this one in that it also performed a call to the NTTP,
e.g.

  template
  struct A {
static void h() {
  p(0);
}
  };

  template
  void g() {
A::h();
  }

  templated void g<0>();

and not even the call was enough to odr-use f, apparently because the
CALL_EXPR case of tsubst_expr calls mark_used on the callee only when
it's a FUNCTION_DECL, but in this case after substitution it's an
ADDR_EXPR of a FUNCTION_DECL.  Fixing this by looking through the ADDR_EXPR
worked, but IIUC the call isn't necessary for f to be odr-used, simply
using f as a template argument should be sufficient, so it seems the
above is better fix.

> +
> +template void g<0>();
> -- 
> 2.33.0.610.gcefe983a32
> 
> 

Re: [Patch] Fortran: Fix deprecate warning with parameter

[Harald Anlauf via Gcc-patches]

Hi Tobias,

Am 05.10.21 um 20:03 schrieb Tobias Burnus:

Played around with the warning in the 'omp_lib' module (needs tweaking
as for the current version, no warning is done). Turned out that already
   use omp_lib
outputs a warning even when not used.


that must have been a non-trivial example; I didn't see that on my
installation.


That's fixed by the attached patch - even if the location is not perfect.


That is certainly an improvement for the testcase.

IIUC the warning is for GCC$ ATTRIBUTES DEPRECATED, so could you mention
that in the commit message.


OK for GCC 12 + GCC 11 backport?


OK for both.

Thanks for the patch!

Harald


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

Re: [PATCH] c++: Implement C++20 -Wdeprecated-array-compare [PR97573]

[Jason Merrill via Gcc-patches]

On 10/1/21 16:14, Marek Polacek wrote:

On Fri, Oct 01, 2021 at 09:30:41AM -0400, Jason Merrill wrote:

On 9/30/21 17:56, Marek Polacek wrote:

On Thu, Sep 30, 2021 at 03:34:24PM -0400, Jason Merrill wrote:

On 9/30/21 10:50, Marek Polacek wrote:

This patch addresses one of my leftovers from GCC 11.  C++20 introduced
[depr.array.comp]:
"Equality and relational comparisons between two operands of array type are
deprecated."
so this patch adds -Wdeprecated-array-compare (enabled by default in C++20).


Why not enable it by default in all modes?  It was always pretty dubious
code.


Sure, it could be done, but it kind of complicates things: we'd probably
need a different option and a different message because it seems incorrect
to say "deprecated" in e.g. C++17 when this was only deprecated in C++20.


The warning could say "deprecated in C++20", which is always true?


I'd rather not add another option; if it stays -Wdeprecated-array-compare
but -Wno-deprecated doesn't turn it off that also seems weird.

I could rename it to -Warray-compare, enable by -Wall, and only
append "is deprecated" to the warning message in C++20.  Does that seem
better?


That sounds fine too.


I did this so that I can add the warning to the C FE too.  Please
take a look at

if you get the chance, thanks.

So consider this patch discarded.  I wonder what I could do so that
Patchwork marks it as such, too.


Yes, I'm surprised that there don't seem to be any support for email 
annotations to direct patchwork, only someone with maintainer privs can 
retire a patch.


Jason

Re: [PATCH] c++: unifying equal NONTYPE_ARGUMENT_PACKs [PR102547]

[Jason Merrill via Gcc-patches]

On 10/1/21 13:29, Patrick Palka wrote:

On Fri, 1 Oct 2021, Jason Merrill wrote:


On 10/1/21 10:26, Patrick Palka wrote:

On Fri, 1 Oct 2021, Jason Merrill wrote:


On 10/1/21 09:46, Patrick Palka wrote:

Here during partial ordering of the two partial specializations we end
up in unify with parm=arg=NONTYPE_ARGUMENT_PACK, and crash
shortly
thereafter because uses_template_parms calls
potential_constant_expression
which doesn't handle NONTYPE_ARGUMENT_PACK.

This patch fixes this by checking dependent_template_arg_p instead of
uses_template_parms when parm==arg, which does handle
NONTYPE_ARGUMENT_PACK.
We could also perhaps fix uses_template_parms / inst_dep_expr_p to
better
handle NONTYPE_ARGUMENT_PACK,


Please.


Sounds good, like the following then?  Passes light testing, bootstrap
and regtest on progress.

-- >8 --

PR c++/102547

gcc/cp/ChangeLog:

* pt.c (instantiation_dependent_expression_p): Sidestep checking
potential_constant_expression on NONTYPE_ARGUMENT_PACK.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic-partial2.C: New test.
* g++.dg/cpp0x/variadic-partial2a.C: New test.
---
   gcc/cp/pt.c   |  4 +++-
   .../g++.dg/cpp0x/variadic-partial2.C  | 16 ++
   .../g++.dg/cpp0x/variadic-partial2a.C | 22 +++
   3 files changed, 41 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C
   create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 1dcdffe322a..643204103c5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -27705,7 +27705,9 @@ instantiation_dependent_expression_p (tree
expression)
   {
 return (instantiation_dependent_uneval_expression_p (expression)
  || (processing_template_decl
- && potential_constant_expression (expression)
+ && expression != NULL_TREE
+ && (TREE_CODE (expression) == NONTYPE_ARGUMENT_PACK
+ || potential_constant_expression (expression))


I'd prefer to loop over the elements of the pack, either here or (probably
better) in potential_constant_expression.


Ah, makes sense.  Like so?  Bootstrapped and regtested on
x86_64-pc-linux-gnu.

-- >8 --

Subject: [PATCH] c++: unifying equal NONTYPE_ARGUMENT_PACKs [PR102547]

Here during partial ordering of the two partial specializations we end
up in unify with parm=arg=NONTYPE_ARGUMENT_PACK, and crash shortly
thereafter because uses_template_parms(parms) calls potential_const_expr
which doesn't handle NONTYPE_ARGUMENT_PACK.

This patch fixes this by extending potential_constant_expression to handle
NONTYPE_ARGUMENT_PACK appropriately.

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


OK.


PR c++/102547

gcc/cp/ChangeLog:

* constexpr.c (potential_constant_expression_1): Handle
NONTYPE_ARGUMENT_PACK.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic-partial2.C: New test.
* g++.dg/cpp0x/variadic-partial2a.C: New test.
---
  gcc/cp/constexpr.c| 10 +
  .../g++.dg/cpp0x/variadic-partial2.C  | 16 ++
  .../g++.dg/cpp0x/variadic-partial2a.C | 22 +++
  3 files changed, 48 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 18d9d117a48..e95ff00774f 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -9043,6 +9043,16 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
  case CO_RETURN_EXPR:
return false;
  
+case NONTYPE_ARGUMENT_PACK:

+  {
+   tree args = ARGUMENT_PACK_ARGS (t);
+   int len = TREE_VEC_LENGTH (args);
+   for (int i = 0; i < len; ++i)
+ if (!RECUR (TREE_VEC_ELT (args, i), any))
+   return false;
+   return true;
+  }
+
  default:
if (objc_non_constant_expr_p (t))
return false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C 
b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C
new file mode 100644
index 000..df61f26a3c1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C
@@ -0,0 +1,16 @@
+// PR c++/102547
+// { dg-do compile { target c++11 } }
+
+template
+struct vals { };
+
+template
+struct vals_client { };
+
+template
+struct vals_client, T> { };
+
+template
+struct vals_client, void> { };
+
+template struct vals_client, void>; //- "sorry, unimplemented..., 
ICE"
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C 
b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C
new file mode 100644
index 000..e98bdbbc07b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C
@@ -0,0 +1,22 @@
+// PR c++/102547
+// { dg-do compile { target c++11 } }
+// A version of 

Re: [PATCH] c++: Fix apply_identity_attributes [PR102548]

[Jason Merrill via Gcc-patches]

On 10/5/21 03:50, Jakub Jelinek wrote:

Hi!

The following testcase ICEs on x86_64-linux with -m32 due to a bug in
apply_identity_attributes.  The function is being smart and attempts not
to duplicate the chain unnecessarily, if either there are no attributes
that affect type identity or there is possibly empty set of attributes
that do not affect type identity in the chain followed by attributes
that do affect type identity, it reuses that attribute chain.

The function mishandles the cases where in the chain an attribute affects
type identity and is followed by one or more attributes that don't
affect type identity (and then perhaps some further ones that do).

There are two bugs.  One is that when we notice first attribute that
doesn't affect type identity after first attribute that does affect type
identity (with perhaps some further such attributes in the chain after it),
we want to put into the new chain just attributes starting from
(inclusive) first_ident and up to (exclusive) the current attribute a,
but the code puts into the chain all attributes starting with first_ident,
including the ones that do not affect type identity and if e.g. we have
doesn't0 affects1 doesn't2 affects3 affects4 sequence of attributes, the
resulting sequence would have
affects1 doesn't2 affects3 affects4 affects3 affects4
attributes, i.e. one attribute that shouldn't be there and two attributes
duplicated.  That is fixed by the a2 -> a2 != a change.

The second one is that we ICE once we see second attribute that doesn't
affect type identity after an attribute that affects it.  That is because
first_ident is set to error_mark_node after handling the first attribute
that doesn't affect type identity (i.e. after we've copied the
[first_ident, a) set of attributes to the new chain) to denote that from
that time on, each attribute that affects type identity should be copied
whenever it is seen (the if (as && as->affects_type_identity) code does
that correctly).  But that condition is false and first_ident is
error_mark_node, we enter else if (first_ident) and use TREE_PURPOSE
/TREE_VALUE/TREE_CHAIN on error_mark_node, which ICEs.  When
first_ident is error_mark_node and a doesn't affect type identity,
we want to do nothing.  So that is the && first_ident != error_mark_node
chunk.

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


OK.


2021-10-05  Jakub Jelinek  

PR c++/102548
* tree.c (apply_identity_attributes): Fix handling of the
case where an attribute in the list doesn't affect type
identity but some attribute before it does.

* g++.target/i386/pr102548.C: New test.

--- gcc/cp/tree.c.jj2021-10-01 18:06:54.603452541 +0200
+++ gcc/cp/tree.c   2021-10-04 19:52:28.767457791 +0200
@@ -1499,9 +1499,9 @@ apply_identity_attributes (tree result,
  p = _CHAIN (*p);
}
}
-  else if (first_ident)
+  else if (first_ident && first_ident != error_mark_node)
{
- for (tree a2 = first_ident; a2; a2 = TREE_CHAIN (a2))
+ for (tree a2 = first_ident; a2 != a; a2 = TREE_CHAIN (a2))
{
  *p = tree_cons (TREE_PURPOSE (a2), TREE_VALUE (a2), NULL_TREE);
  p = _CHAIN (*p);
--- gcc/testsuite/g++.target/i386/pr102548.C.jj 2021-10-04 20:06:19.314810708 
+0200
+++ gcc/testsuite/g++.target/i386/pr102548.C2021-10-04 20:05:14.808717194 
+0200
@@ -0,0 +1,12 @@
+// PR c++/102548
+// { dg-do compile { target { c++14 && ia32 } } }
+
+typedef decltype(sizeof(0)) size_t;
+struct tm;
+extern "C" size_t __attribute__((__cdecl__)) strftime (char *, size_t, const 
char *, const struct tm *);
+
+auto
+foo (void)
+{
+  return strftime;
+}

Jakub

Re: [PATCH RFA] vec: Fix --enable-gather-detailed-mem-stats

[Jason Merrill via Gcc-patches]

On 10/5/21 07:27, Richard Biener wrote:

On Mon, Oct 4, 2021 at 8:28 PM Jason Merrill via Gcc-patches
 wrote:


When r12-4038 introduced the global auto_vec save_opt_decoded_options,
it broke compilers configured with --enable-gather-detailed-mem-stats,
due to the memory descriptors getting discarded before the auto_vec was
destroyed.  Attached below are two approaches to making this work,
either by using the init_priority attribute, or turning vec_mem_desc
into a singleton function.  I prefer the first one, primarily because it
doesn't require auto_vec variables to force immediate allocation.  It
relies on a G++ extension, but I figure that's OK for code that is only
exercised with a debugging configure flag.

Thoughts?  Either one OK for trunk?


Hmm, isn't the way to fix this to turn the global auto_vec into
vec<> *x and allocate it at runtime (thus explicitly mange its
lifetime?).  We don't want global CTORs/DTORs in general
because of startup cost and of course those pesky ordering issues...


That is the usual approach, yes.  I was giving up on that, but perhaps 
it's better to stick with it.  Martin, want to make that fix for 
save_opt_decoded_options?



Oh, and maybe we can make

 static mem_alloc_description  vec_mem_desc;

statically initialized with some C++?  (constexpr? constinit? whatever?
It can't be statically initialized, because it needs to allocate 
multiple maps.


Jason

[PATCH v3] libgcc: Add a backchain fallback to _Unwind_Backtrace() on PowerPC

[Raphael Moreira Zinsly via Gcc-patches]

Without dwarf2 unwind tables available _Unwind_Backtrace() is not
able to return the full backtrace.
This patch adds a fallback function on powerpc to get the backtrace
by doing a backchain, this code was originally at glibc.

libgcc/ChangeLog:

* config/rs6000/linux-unwind.h (struct rt_sigframe): Move it to
outside of get_regs() in order to use it in another function, this
is done twice: for __powerpc64__ and for !__powerpc64__.
(struct trace_arg): New struct.
(struct layout): New struct.
(ppc_backchain_fallback): New function.
* unwind.inc (_Unwind_Backtrace): Look for _URC_NORMAL_STOP code
state and call MD_BACKCHAIN_FALLBACK.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/unwind-backchain.c: New test.
---
 .../gcc.target/powerpc/unwind-backchain.c |  24 +
 libgcc/config/rs6000/linux-unwind.h   | 102 +++---
 libgcc/unwind.inc |  14 ++-
 3 files changed, 124 insertions(+), 16 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/unwind-backchain.c

diff --git a/gcc/testsuite/gcc.target/powerpc/unwind-backchain.c 
b/gcc/testsuite/gcc.target/powerpc/unwind-backchain.c
new file mode 100644
index 000..affa9b2efec
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/unwind-backchain.c
@@ -0,0 +1,24 @@
+/* -linux* targets have a fallback for the absence of unwind tables, thus are
+   the only ones we can guarantee backtrace returns all addresses.  */
+/* { dg-do run { target { *-*-linux* } } } */
+/* { dg-options "-fno-asynchronous-unwind-tables" } */
+
+#include 
+
+void
+test_backtrace()
+{
+  int addresses;
+  void *buffer[10];
+
+  addresses = backtrace(buffer, 10);
+  if(addresses != 4)
+__builtin_abort();
+}
+
+int
+main()
+{
+  test_backtrace();
+  return 0;
+}
diff --git a/libgcc/config/rs6000/linux-unwind.h 
b/libgcc/config/rs6000/linux-unwind.h
index acdc948f85d..8deccc1d650 100644
--- a/libgcc/config/rs6000/linux-unwind.h
+++ b/libgcc/config/rs6000/linux-unwind.h
@@ -94,6 +94,15 @@ struct gcc_ucontext
 
 enum { SIGNAL_FRAMESIZE = 128 };
 
+struct rt_sigframe {
+  char gap[SIGNAL_FRAMESIZE];
+  struct gcc_ucontext uc;
+  unsigned long pad[2];
+  int tramp[6];
+  void *pinfo;
+  struct gcc_ucontext *puc;
+};
+
 /* If PC is at a sigreturn trampoline, return a pointer to the
regs.  Otherwise return NULL.  */
 
@@ -136,14 +145,7 @@ get_regs (struct _Unwind_Context *context)
 #endif
{
  /* This works for 2.4.21 and later kernels.  */
- struct rt_sigframe {
-   char gap[SIGNAL_FRAMESIZE];
-   struct gcc_ucontext uc;
-   unsigned long pad[2];
-   int tramp[6];
-   void *pinfo;
-   struct gcc_ucontext *puc;
- } *frame = (struct rt_sigframe *) context->cfa;
+ struct rt_sigframe *frame = (struct rt_sigframe *) context->cfa;
  return frame->uc.regs;
}
 }
@@ -154,6 +156,12 @@ get_regs (struct _Unwind_Context *context)
 
 enum { SIGNAL_FRAMESIZE = 64 };
 
+struct rt_sigframe {
+  char gap[SIGNAL_FRAMESIZE + 16];
+  char siginfo[128];
+  struct gcc_ucontext uc;
+};
+
 static struct gcc_regs *
 get_regs (struct _Unwind_Context *context)
 {
@@ -176,11 +184,7 @@ get_regs (struct _Unwind_Context *context)
 }
   else if (pc[0] == 0x3800 || pc[0] == 0x38AC)
 {
-  struct rt_sigframe {
-   char gap[SIGNAL_FRAMESIZE + 16];
-   char siginfo[128];
-   struct gcc_ucontext uc;
-  } *frame = (struct rt_sigframe *) context->cfa;
+  struct rt_sigframe *frame = (struct rt_sigframe *) context->cfa;
   return frame->uc.regs;
 }
   return NULL;
@@ -203,7 +207,7 @@ ppc_fallback_frame_state (struct _Unwind_Context *context,
   int i;
 
   if (regs == NULL)
-return _URC_END_OF_STACK;
+return _URC_NORMAL_STOP;
 
   new_cfa = regs->gpr[__LIBGCC_STACK_POINTER_REGNUM__];
   fs->regs.cfa_how = CFA_REG_OFFSET;
@@ -352,3 +356,73 @@ frob_update_context (struct _Unwind_Context *context, 
_Unwind_FrameState *fs ATT
 }
 #endif
 }
+
+#define MD_BACKCHAIN_FALLBACK ppc_backchain_fallback
+
+struct trace_arg
+{
+  /* Stores the list of addresses.  */
+  void **array;
+  struct unwind_link *unwind_link;
+  _Unwind_Word cfa;
+  /* Number of addresses currently stored.  */
+  int count;
+  /* Maximum number of addresses.  */
+  int size;
+};
+
+/* This is the stack layout we see with every stack frame.
+   Note that every routine is required by the ABI to lay out the stack
+   like this.
+
+   +++-+
+%r1  -> | previous frame> | previous frame--->...  --> NULL
+   ||| |
+   | cr save|| cr save |
+   ||| |
+   | (unused)   || lr save |
+   +++-+
+
+  The CR save is only present 

Re: [patch][middle-end/PR102359]Not add initialization for DECL_VALUE_EXPR variables with -ftrivial-auto-var-init

[Jason Merrill via Gcc-patches]

On 10/5/21 10:32, Qing Zhao wrote:




On Oct 5, 2021, at 3:19 AM, Richard Biener  wrote:

On Tue, 5 Oct 2021, Qing Zhao wrote:


Hi,

This is the patch to fix this issue based on our discussion.

I have tested it on aarch64 with bootstrap and regtests. X86 bootstrap was 
done, regtests is ongoing.

Okay for trunk?

Thanks.

Qing

==
 From d349ef0145512efe7f9af2c6bbd01f636475bce3 Mon Sep 17 00:00:00 2001
From: qing zhao 
Date: Mon, 4 Oct 2021 15:26:03 -0700
Subject: [PATCH] middle-end/102359 Not add initialization for variables that
have been  initialized by FEs.

C++ FE creates proxy variables, which have associated DECL_VALUE_EXPR
and have been initialized by FE. For such auto variable, we should not
add initialization when -ftrivial-auto-var-init presents.

gcc/ChangeLog:

2021-10-04  qing zhao  

* gimplify.c (is_decl_init_by_fe): New function.
(gimplify_decl_expr): Not add initialization for an auto variable
when it has been initialized by frontend.

gcc/testsuite/ChangeLog:

2021-10-04  qing zhao  

* g++.dg/pr102359_1.C: New test.
* g++.dg/pr102359_2.C: New test.
---
gcc/gimplify.c| 21 -
gcc/testsuite/g++.dg/pr102359_1.C | 13 +
gcc/testsuite/g++.dg/pr102359_2.C | 13 +
3 files changed, 46 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/pr102359_1.C
create mode 100644 gcc/testsuite/g++.dg/pr102359_2.C

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index b27776a..d6865ad 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1819,6 +1819,19 @@ gimple_add_padding_init_for_auto_var (tree decl, bool 
is_vla,
   gimplify_seq_add_stmt (seq_p, call);
}

+/* Return true if the DECL is initialized by FE.
+   If the VAR_DECL has DECL_VALUE_EXPR that was created by FE (usually C++FE),
+   it's a proxy varaible, and FE already initializd the DECL_VALUE_EXPR of it.
+*/
+static bool
+is_decl_init_by_fe (tree decl, bool is_created_by_fe)
+{
+  if (DECL_HAS_VALUE_EXPR_P (decl)
+  && is_created_by_fe)
+return true;
+  return false;
+}
+
/* Return true if the DECL need to be automaticly initialized by the
compiler.  */
static bool
@@ -1871,8 +1884,13 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
   if (VAR_P (decl) && !DECL_EXTERNAL (decl))
 {
   tree init = DECL_INITIAL (decl);
+  bool is_value_expr_created_by_fe = false;


no need for the = false, it's always initialized below.


   bool is_vla = false;

+  /* Check whether a decl has FE created VALUE_EXPR here BEFORE
+gimplify_vla_decl creates VALUE_EXPR for vla decl.  */
+  is_value_expr_created_by_fe = DECL_HAS_VALUE_EXPR_P (decl);


That looks a bit weird when looking at ...


+
   poly_uint64 size;
   if (!poly_int_tree_p (DECL_SIZE_UNIT (decl), )
  || (!TREE_STATIC (decl)
@@ -1934,7 +1952,8 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
   /* When there is no explicit initializer, if the user requested,
 We should insert an artifical initializer for this automatic
 variable.  */
-  else if (is_var_need_auto_init (decl))
+  else if (is_var_need_auto_init (decl)
+  && !is_decl_init_by_fe (decl, is_value_expr_created_by_fe))


... which just expands to

if (DECL_HAS_VALUE_EXPR_P (decl) && DECL_HAS_VALUE_EXPR_P (decl))

can you please name 'is_value_expr_created_by_fe' as
'decl_had_value_expr_p' and check && !decl_had_value_expr_p here?
So sth like


I can do this -:) I agree that the change will make the code simpler.

However, my major concern with this change is: later when people look at this 
change, they might ask:
Why we should not initialize a variable with VALUE_EXPR? And whether the 
variable whose VALUE_EXPR
was created by “gimplify_vla_decl” should be excluded?

My new function and comments were all for this purpose.

If I go with this change, at least we should add some comments to explain this 
as following, what do you think?


diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index b27776af7c8..9013f385f13 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1872,6 +1872,7 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
 {
   tree init = DECL_INITIAL (decl);
   bool is_vla = false;


+ /* Check whether a decl has FE created VALUE_EXPR here BEFORE
+gimplify_vla_decl creates VALUE_EXPR for vla decl.  */

+  bool decl_had_value_expr_p = DECL_HAS_VALUE_EXPR_P (decl);

   poly_uint64 size;
   if (!poly_int_tree_p (DECL_SIZE_UNIT (decl), )
@@ -1934,7 +1935,8 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
   /* When there is no explicit initializer, if the user requested,
 We should insert an artifical initializer for this automatic
 variable.  */
-  else if (is_var_need_auto_init (decl))
+  else if (is_var_need_auto_init (decl)


+   /* If the VAR_DECL has DECL_VALUE_EXPR that was created by FE (usually 
C++FE),
+   it's a 

[Patch] Fortran: Fix deprecate warning with parameter

[Tobias Burnus]

Played around with the warning in the 'omp_lib' module (needs tweaking
as for the current version, no warning is done). Turned out that already
  use omp_lib
outputs a warning even when not used.

That's fixed by the attached patch - even if the location is not perfect.

OK for GCC 12 + GCC 11 backport?

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
Fortran: Fix deprecate warning with parameter

gcc/fortran/ChangeLog:

	* resolve.c (resolve_values): Only show
	deprecated warning if attr.referenced.

gcc/testsuite/ChangeLog:

	* gfortran.dg/attr_deprecated-2.f90: New test.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 511fe3a5e55..0d0af39d23f 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12351,7 +12351,7 @@ resolve_values (gfc_symbol *sym)
   if (sym->value == NULL)
 return;
 
-  if (sym->attr.ext_attr & (1 << EXT_ATTR_DEPRECATED))
+  if (sym->attr.ext_attr & (1 << EXT_ATTR_DEPRECATED) && sym->attr.referenced)
 gfc_warning (OPT_Wdeprecated_declarations,
 		 "Using parameter %qs declared at %L is deprecated",
 		 sym->name, >declared_at);
diff --git a/gcc/testsuite/gfortran.dg/attr_deprecated-2.f90 b/gcc/testsuite/gfortran.dg/attr_deprecated-2.f90
new file mode 100644
index 000..97a365a7c4a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/attr_deprecated-2.f90
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! { dg-additional-options "-Wall" }
+!
+! Ensure that only those parameters are warned for which are actually used
+!
+module m
+  implicit none
+  integer, parameter :: parm = 4   ! unused
+  integer, parameter :: parm2 = 4  ! used in the main program
+  integer, parameter :: parm3 = 4  ! used in "f()" - { dg-warning "Using parameter 'parm3' declared at .1. is deprecated" }
+  integer, save :: var, var2
+!GCC$ ATTRIBUTES DEPRECATED :: parm, parm2, parm3, var, var2
+contains
+  subroutine f()
+print *, parm3 ! warning shown above
+  end
+end module m
+
+use m  ! { dg-warning "Using parameter 'parm2' declared at .1. is deprecated" }
+implicit none
+print *, var2, parm2  ! { dg-warning "Using variable 'var2' at .1. is deprecated" }
+end

Re: [PATCH] d-demangle: properly skip anonymous symbols

[Luís Ferreira]

On Tue, 2021-10-05 at 18:13 +0100, Luís Ferreira wrote:
> This patch fixes a bug on the D demangler by parsing and skip anonymous
> symbols
> correctly, according the ABI specification. Furthermore, it also
> includes tests
> to cover anonymous symbols.
> 
> The spec specifies [1] that a symbol name can be anonymous and multiple
> anonymous symbols are allowed.
> 
> [1]: https://dlang.org/spec/abi.html#SymbolName
> 
> ChangeLog:
> libiberty/
> * d-demangle.c (dlang_parse_qualified): Handle anonymous
> symbols
>   correctly.
> 
> * testsuite/d-demangle-expected: New tests to cover anonymous
> symbols.
> 
> Signed-off-by: Luís Ferreira 
> ---
>  libiberty/d-demangle.c  | 13 +
>  libiberty/testsuite/d-demangle-expected |  8 
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
> index 3adf7b562d1..682f73f9923 100644
> --- a/libiberty/d-demangle.c
> +++ b/libiberty/d-demangle.c
> @@ -1650,13 +1650,18 @@ dlang_parse_qualified (string *decl, const char
> *mangled,
>    size_t n = 0;
>    do
>  {
> +  /* Skip over anonymous symbols.  */
> +  if (*mangled == '0')
> +  {
> +   do mangled++;
> +   while (*mangled == '0');
> +
> +   continue;
> +  }
> +
>    if (n++)
> string_append (decl, ".");
>  
> -  /* Skip over anonymous symbols.  */
> -  while (*mangled == '0')
> -   mangled++;
> -
>    mangled = dlang_identifier (decl, mangled, info);
>  
>    /* Consume the encoded arguments.  However if this is not
> followed by the
> diff --git a/libiberty/testsuite/d-demangle-expected
> b/libiberty/testsuite/d-demangle-expected
> index 44a3649c429..9459f600779 100644
> --- a/libiberty/testsuite/d-demangle-expected
> +++ b/libiberty/testsuite/d-demangle-expected
> @@ -1450,3 +1450,11 @@ mod.func().nested!(int).nested()
>  --format=dlang
>  _D6mangle__T8fun21753VSQv6S21753S1f_DQBj10__lambda71MFNaNbNiNfZvZQCbQp
>  mangle.fun21753!(mangle.S21753(mangle.__lambda71())).fun21753
> +#
> +--format=dlang
> +_D8demangle9anonymous0Z
> +demangle.anonymous
> +#
> +--format=dlang
> +_D8demangle9anonymous03fooZ
> +demangle.anonymous.foo

Updated ChangeLog:

ChangeLog:
libiberty/
PR bugzilla_component/102618
* d-demangle.c (dlang_parse_qualified): Handle anonymous
symbols correctly.

* testsuite/d-demangle-expected: New tests to cover anonymous
symbols.

-- 
Sincerely,
Luís Ferreira @ lsferreira.net



signature.asc
Description: This is a digitally signed message part

[PATCH] Transition nvptx backend to STORE_FLAG_VALUE = 1

[Roger Sayle]

This patch to the nvptx backend changes the backend's STORE_FLAG_VALUE
from -1 to 1, by using BImode predicates and selp instructions, instead
of set instructions (almost always followed by integer negation).

Historically, it was reasonable (through rare) for backends to use -1
for representing true during the RTL passes.  However with tree-ssa,
GCC now emits lots of code that reads and writes _Bool values, requiring
STORE_FLAG_VALUE=-1 targets to frequently convert 0/-1 pseudos to 0/1
pseudos using integer negation.  Unfortunately, this process prevents
or complicates many optimizations (negate isn't associative with logical
AND, OR and XOR, and interferes with range/vrp/nonzerobits bounds etc.).

The impact of this is that for a relatively simple logical expression
like "return (x==21) && (y==69);", the nvptx backend currently generates:

mov.u32 %r26, %ar0;
mov.u32 %r27, %ar1;
set.u32.eq.u32  %r30, %r26, 21;
neg.s32 %r31, %r30;
mov.u32 %r29, %r31;
set.u32.eq.u32  %r33, %r27, 69;
neg.s32 %r34, %r33;
mov.u32 %r32, %r34;
cvt.u16.u8  %r39, %r29;
mov.u16 %r36, %r39;
cvt.u16.u8  %r39, %r32;
mov.u16 %r37, %r39;
and.b16 %r35, %r36, %r37;
cvt.u32.u16 %r38, %r35;
cvt.u32.u8  %value, %r38;

This patch tweaks nvptx to generate 0/1 values instead, requiring the
same number of instructions, using (BImode) predicate registers and selp
instructions so as to now generate the almost identical:

mov.u32 %r26, %ar0;
mov.u32 %r27, %ar1;
setp.eq.u32 %r31, %r26, 21;
selp.u32%r30, 1, 0, %r31;
mov.u32 %r29, %r30;
setp.eq.u32 %r34, %r27, 69;
selp.u32%r33, 1, 0, %r34;
mov.u32 %r32, %r33;
cvt.u16.u8  %r39, %r29;
mov.u16 %r36, %r39;
cvt.u16.u8  %r39, %r32;
mov.u16 %r37, %r39;
and.b16 %r35, %r36, %r37;
cvt.u32.u16 %r38, %r35;
cvt.u32.u8  %value, %r38;

The hidden benefit is that this sequence can (in theory) be optimized
by the RTL passes to eventually generate a much shorter sequence using
an and.pred instruction (just like Nvidia's nvcc compiler).

This patch has been tested nvptx-none with a "make" and "make -k check"
(including newlib) hosted on x86_64-pc-linux-gnu with no new failures.
Ok for mainline?


2021-10-05  Roger Sayle  

gcc/ChangeLog
* config/nvptx/nvptx.h (STORE_FLAG_VALUE): Change to 1.
* config/nvptx/nvptx.md (movbi): Use P1 constraint for true.
(setcc_from_bi): Remove SImode specific pattern.
(setcc_from_bi): Provide more general HSDIM pattern.
(extendbi2, zeroextendbi2): Provide instructions
for sign- and zero-extending BImode predicates to integers.
(setcc_int): Remove previous (-1-based) instructions.
(cstorebi4): Remove BImode to SImode specific expander.
(cstore4): Fix indentation.  Expand using setccsi_from_bi.
(cstore4): For both integer and floating point modes.


Thanks in advance,
Roger
--

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index d367174..fcebcf9 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -315,7 +315,7 @@ struct GTY(()) machine_function
 #define NO_DOT_IN_LABEL
 #define ASM_COMMENT_START "//"
 
-#define STORE_FLAG_VALUE -1
+#define STORE_FLAG_VALUE 1
 #define FLOAT_STORE_FLAG_VALUE(MODE) REAL_VALUE_ATOF("1.0", (MODE))
 
 #define CASE_VECTOR_MODE SImode
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index 108de1c..b3275b1 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -213,7 +213,7 @@
 ;; get variables in this mode and pseudos are never spilled.
 (define_insn "movbi"
   [(set (match_operand:BI 0 "nvptx_register_operand" "=R,R,R")
-   (match_operand:BI 1 "nvptx_nonmemory_operand" "R,P0,Pn"))]
+   (match_operand:BI 1 "nvptx_nonmemory_operand" "R,P0,P1"))]
   ""
   "@
%.\\tmov%t0\\t%0, %1;
@@ -789,12 +789,26 @@
 
 ;; Conditional stores
 
-(define_insn "setcc_from_bi"
-  [(set (match_operand:SI 0 "nvptx_register_operand" "=R")
-   (ne:SI (match_operand:BI 1 "nvptx_register_operand" "R")
-  (const_int 0)))]
+(define_insn "setcc_from_bi"
+  [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
+   (ne:HSDIM (match_operand:BI 1 "nvptx_register_operand" "R")
+  (const_int 0)))]
+  ""
+  "%.\\tselp%t0\\t%0, 1, 0, %1;")
+
+(define_insn "extendbi2"
+  [(set (match_operand:HSDIM 0 "nvptx_register_operand" "=R")
+   (sign_extend:HSDIM
+(match_operand:BI 1 "nvptx_register_operand" "R")))]
+  ""
+  "%.\\tselp%t0\\t%0, -1, 0, %1;")
+

Re: [PATCH] d-demangle: properly skip anonymous symbols

[Luís Ferreira]

On Tue, 2021-10-05 at 18:13 +0100, Luís Ferreira wrote:
> This patch fixes a bug on the D demangler by parsing and skip
> anonymous symbols
> correctly, according the ABI specification. Furthermore, it also
> includes tests
> to cover anonymous symbols.
> 
> The spec specifies [1] that a symbol name can be anonymous and
> multiple
> anonymous symbols are allowed.
> 
> [1]: https://dlang.org/spec/abi.html#SymbolName
> 
> ChangeLog:
> libiberty/
> * d-demangle.c (dlang_parse_qualified): Handle anonymous
> symbols
>   correctly.
> 
> * testsuite/d-demangle-expected: New tests to cover anonymous
> symbols.
> 
> Signed-off-by: Luís Ferreira 
> ---
>  libiberty/d-demangle.c  | 13 +
>  libiberty/testsuite/d-demangle-expected |  8 
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
> index 3adf7b562d1..682f73f9923 100644
> --- a/libiberty/d-demangle.c
> +++ b/libiberty/d-demangle.c
> @@ -1650,13 +1650,18 @@ dlang_parse_qualified (string *decl, const
> char *mangled,
>    size_t n = 0;
>    do
>  {
> +  /* Skip over anonymous symbols.  */
> +  if (*mangled == '0')
> +  {
> +   do mangled++;
> +   while (*mangled == '0');
> +
> +   continue;
> +  }
> +
>    if (n++)
> string_append (decl, ".");
>  
> -  /* Skip over anonymous symbols.  */
> -  while (*mangled == '0')
> -   mangled++;
> -
>    mangled = dlang_identifier (decl, mangled, info);
>  
>    /* Consume the encoded arguments.  However if this is not
> followed by the
> diff --git a/libiberty/testsuite/d-demangle-expected
> b/libiberty/testsuite/d-demangle-expected
> index 44a3649c429..9459f600779 100644
> --- a/libiberty/testsuite/d-demangle-expected
> +++ b/libiberty/testsuite/d-demangle-expected
> @@ -1450,3 +1450,11 @@ mod.func().nested!(int).nested()
>  --format=dlang
>  _D6mangle__T8fun21753VSQv6S21753S1f_DQBj10__lambda71MFNaNbNiNfZvZQCb
> Qp
>  mangle.fun21753!(mangle.S21753(mangle.__lambda71())).fun21753
> +#
> +--format=dlang
> +_D8demangle9anonymous0Z
> +demangle.anonymous
> +#
> +--format=dlang
> +_D8demangle9anonymous03fooZ
> +demangle.anonymous.foo

I can't create an issue on bugzilla for this patch, since I don't have
an account. I'm going to create one right now. On the meanwhile, feel
free to review it.

-- 
Sincerely,
Luís Ferreira @ lsferreira.net



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] libiberty: prevent buffer overflow when decoding user input

[Luís Ferreira]

On Tue, 2021-10-05 at 09:00 -0600, Jeff Law wrote:
> 
> 
> On 10/4/2021 10:52 AM, Luís Ferreira wrote:
> > On Thu, 2021-09-23 at 09:50 -0600, Jeff Law wrote:
> > > 
> > > On 9/23/2021 4:16 AM, ibuclaw--- via Gcc-patches wrote:
> > > > > On 22/09/2021 03:10 Luís Ferreira 
> > > > > wrote:
> > > > > 
> > > > >    
> > > > > Currently a stack/heap overflow may happen if a crafted
> > > > > mangle is
> > > > > maliciously used to cause denial of service, such as
> > > > > intentional
> > > > > crashes
> > > > > by accessing a reserved memory space.
> > > > > 
> > > > Hi,
> > > > 
> > > > Thanks for this.  Is there a test that could trigger this code
> > > > path?
> > > I don't think Luis has commit privs, so I went ahead and
> > > committed
> > > this
> > > patch.
> > > 
> > > Yea, a testcase would be great.
> > > 
> > > Jeff
> > > 
> > Does the test suite runned against address sanitization? if yes, I
> > can
> > submit a patch to make this fail, otherwise it is hard to trigger a
> > consistent crash for this issue.
> Unfortunately, no it doesn't run with sanitization.  If it's too
> painful 
> to create a test, don't worry about it.  It happens from time to
> time.
> 
> jeff

I would like to add address sanitization if I knew how GCC autotools
work but I think this is a better fit when I invest some time
implementing something to OSS fuzz and build some infrastructure for
fuzzing parts of the GCC.

-- 
Sincerely,
Luís Ferreira @ lsferreira.net



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] c++: Implement C++23 P2334R1 - #elifdef/#elifndef

[Joseph Myers]

On Tue, 5 Oct 2021, Jakub Jelinek via Gcc-patches wrote:

> One is in the patch below, ignores that sentence and only implements it
> for -std=c++23/-std=gnu++23 like it is only implemented for -std=c23.
> Another option would be to implement it also in the older GNU modes but
> not in the C/CXX modes (but it would be strange if we did that just for
> C++ and not for C).
> Yet another option is to enable it unconditionally.
> And yet another option would be to enable it unconditionally but emit
> a warning (or pedwarn) when it is seen.
> Note, when it is enabled for the older language modes, as Joseph wrote
> in the c11-elifdef-1.c testcase, it can result e.g. in rejecting previously
> valid code:

It would probably be reasonable to enable it in older GNU modes for C as 
well as C++ if desired (and, in that case, emit a pedwarn-if-pedantic when 
it's acted on) - cases where it affects compatibility should be rare.  
Enabling with a pedwarn in strict modes is problematic because it changes 
semantics of valid code where it was inside #if 0, however.  It doesn't 
make sense at all to me to think of a new feature like this (one with no 
prior art in C mentioned in the WG14 proposal) as a defect fix.

Any normal directive - i.e. one that has no effect on the preprocessor #if 
structure and so is ignored inside #if 0 for all language versions - can 
more reasonably be enabled for all language versions with a pedwarn when 
used for old versions.  (In particular, that will be appropriate for 
#warning, where the "don't pedwarn in C2X modes" part needs implementing 
after N2686 was accepted at the August / September WG14 meeting - I don't 
know if C++ is doing anything with #warning.)

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

[wwwdocs] Update cxx-status with October 2021 WG21 plenary

[Marek Polacek via Gcc-patches]

Pushed.  Jakub already added the feature test macros.

commit 78f03a4a633950743a416f5b9e7f721db7892090
Author: Marek Polacek 
Date:   Tue Oct 5 12:57:19 2021 -0400

cxx-status: Add papers from the October 2021 WG21 plenary

diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 7c150fbc..add6f428 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -131,6 +131,69 @@

 
 -->
+
+
+   Deducing this 
+   https://wg21.link/p0847r7;>P0847R7
+   https://gcc.gnu.org/PR102609;>No
+   
+
+
+
+   Change scope of lambda trailing-return-type 
+   https://wg21.link/p2036r3;>P2036R3
+   https://gcc.gnu.org/PR102610;>No
+   
+
+
+
+   Multidimensional subscript operator 
+   https://wg21.link/p2128r6;>P2128R6
+   https://gcc.gnu.org/PR102611;>No
+   
+
+
+
+   Non-literal variables (and labels and gotos) in constexpr functions 

+   https://wg21.link/p2242r3;>P2242R3
+   https://gcc.gnu.org/PR102612;>No
+   
+
+
+
+   Character encoding of diagnostic text 
+   https://wg21.link/p2246r1;>P2246R1
+   https://gcc.gnu.org/PR102613;>No
+   
+
+
+
+   Character sets and encodings 
+   https://wg21.link/p2314r4;>P2314R4
+   https://gcc.gnu.org/PR102614;>No
+   
+
+
+
+   Consistent character literal encoding 
+   https://wg21.link/p2316r2;>P2316R2
+   https://gcc.gnu.org/PR102615;>No
+   
+
+
+
+   Add support for preprocessing directives elifdef and elifndef 
+   https://wg21.link/p2334r1;>P2334R1
+   https://gcc.gnu.org/PR102616;>No
+   
+
+
+
+   Extend init-statement to allow alias-declaration 
+   https://wg21.link/p2360r0;>P2360R0
+   https://gcc.gnu.org/PR102617;>No
+   
+
 
CWG 2397: auto specifier for pointers and references to arrays 
https://wg21.link/cwg2397;>CWG2397

[PATCH] d-demangle: properly skip anonymous symbols

[Luís Ferreira]

This patch fixes a bug on the D demangler by parsing and skip anonymous symbols
correctly, according the ABI specification. Furthermore, it also includes tests
to cover anonymous symbols.

The spec specifies [1] that a symbol name can be anonymous and multiple
anonymous symbols are allowed.

[1]: https://dlang.org/spec/abi.html#SymbolName

ChangeLog:
libiberty/
* d-demangle.c (dlang_parse_qualified): Handle anonymous symbols
  correctly.

* testsuite/d-demangle-expected: New tests to cover anonymous symbols.

Signed-off-by: Luís Ferreira 
---
 libiberty/d-demangle.c  | 13 +
 libiberty/testsuite/d-demangle-expected |  8 
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 3adf7b562d1..682f73f9923 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -1650,13 +1650,18 @@ dlang_parse_qualified (string *decl, const char 
*mangled,
   size_t n = 0;
   do
 {
+  /* Skip over anonymous symbols.  */
+  if (*mangled == '0')
+  {
+   do mangled++;
+   while (*mangled == '0');
+
+   continue;
+  }
+
   if (n++)
string_append (decl, ".");
 
-  /* Skip over anonymous symbols.  */
-  while (*mangled == '0')
-   mangled++;
-
   mangled = dlang_identifier (decl, mangled, info);
 
   /* Consume the encoded arguments.  However if this is not followed by the
diff --git a/libiberty/testsuite/d-demangle-expected 
b/libiberty/testsuite/d-demangle-expected
index 44a3649c429..9459f600779 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -1450,3 +1450,11 @@ mod.func().nested!(int).nested()
 --format=dlang
 _D6mangle__T8fun21753VSQv6S21753S1f_DQBj10__lambda71MFNaNbNiNfZvZQCbQp
 mangle.fun21753!(mangle.S21753(mangle.__lambda71())).fun21753
+#
+--format=dlang
+_D8demangle9anonymous0Z
+demangle.anonymous
+#
+--format=dlang
+_D8demangle9anonymous03fooZ
+demangle.anonymous.foo
-- 
2.33.0

Re: [PATCH] Loop unswitching: support gswitch statements.

[Andrew MacLeod via Gcc-patches]

On 9/28/21 7:50 AM, Richard Biener wrote:

On Wed, Sep 15, 2021 at 10:46 AM Martin Liška  wrote:

Hello.

The patch extends the loop unswitching pass so that gswitch
statements are supported. The pass now uses ranger which marks
switch edges that are known to be unreachable in a versioned loop.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin



Do you have any switch size restrictions or limits?
I'm about to add --param which will limit ranger to switches of a specified 
size, defaulting to 50 outgoing edges.
It turns out a number of the pathological cases we see are very large switches, 
and we spend a lot of time processing and unioning ranges on the various edges 
and at meet points.

Anyway, the limit will make ranger not "see" switches above the threshold, so 
it will not generate ranges for them. I hope to eliminate this for next release, but for 
now it serves a purpose.
The patch currently makes this apply to all rangers, but if this is problematic 
for you, I will adjust it to make sure its only when invoked via EVRP.

Andrew

Re: [PATCH] Improve integer bit test on atomic builtin return

[H.J. Lu via Gcc-patches]

On Tue, Oct 5, 2021 at 3:07 AM Richard Biener  wrote:
>
> On Mon, 4 Oct 2021, H.J. Lu wrote:
>
> > commit adedd5c173388ae505470df152b9cb3947339566
> > Author: Jakub Jelinek 
> > Date:   Tue May 3 13:37:25 2016 +0200
> >
> > re PR target/49244 (__sync or __atomic builtins will not emit 'lock 
> > bts/btr/btc')
> >
> > optimized bit test on atomic builtin return with lock bts/btr/btc.  But
> > it works only for unsigned integers since atomic builtins operate on the
> > 'uintptr_t' type.  It fails on bool:
> >
> >   _1 = atomic builtin;
> >   _4 = (_Bool) _1;
> >
> > and signed integers:
> >
> >   _1 = atomic builtin;
> >   _2 = (int) _1;
> >   _5 = _2 & (1 << N);
> >
> > Improve bit test on atomic builtin return by converting:
> >
> >   _1 = atomic builtin;
> >   _4 = (_Bool) _1;
> >
> > to
> >
> >   _1 = atomic builtin;
> >   _5 = _1 & (1 << 0);
> >   _4 = (_Bool) _5;
> >
> > and converting:
> >
> >   _1 = atomic builtin;
> >   _2 = (int) _1;
> >   _5 = _2 & (1 << N);
> >
> > to
> >   _1 = atomic builtin;
> >   _6 = _1 & (1 << N);
> >   _5 = (int) _6;
>
> Why not do this last bit with match.pd patterns (and independent on
> whether _1 is defined by an atomic builtin)?  For the first suggested

The full picture is

 _1 = _atomic_fetch_or_* (ptr_6, mask, _3);
  _2 = (int) _1;
  _5 = _2 & mask;

to

  _1 = _atomic_fetch_or_* (ptr_6, mask, _3);
  _6 = _1 & mask;
  _5 = (int) _6;

It is useful only if 2 masks are the same.

> transform that's likely going to be undone by folding, no?
>

The bool case is

  _1 = __atomic_fetch_or_* (ptr_6, 1, _3);
  _4 = (_Bool) _1;

to

  _1 = __atomic_fetch_or_* (ptr_6, 1, _3);
  _5 = _1 & 1;
  _4 = (_Bool) _5;

Without __atomic_fetch_or_*, the conversion isn't needed.
After the conversion, optimize_atomic_bit_test_and will
immediately optimize the code sequence to

  _6 = .ATOMIC_BIT_TEST_AND_SET (, 0, 0, 0);
  _4 = (_Bool) _6;

and there is nothing to fold after it.

-- 
H.J.

Re: [RFC] More jump threading restrictions in the presence of loops.

[Aldy Hernandez via Gcc-patches]

On Tue, Oct 5, 2021 at 6:08 PM Jeff Law  wrote:

> OK.  I think there may still be some concern if the latch is marked as a 
> joiner.I think we should always reject those before the loop optimizers 
> run as the joiner's clone would introduce a second latch.   I think that can 
> be handled in a follow-up refinement.

I've been mumbling, to myself mostly, that the loop threading
restrictions should be owned by the loop experts.  There's not much I
can contribute here, except testcases and patches that I *think* are
what y'all want.  That being said, I will follow-up with the
suggestions made by Richi, because I've already done the work, and
have cobbled up the relevant gimple FE tests ;-).

>
>
>
>
>
>
> Co-authored-by: Jeff Law 
>
> I'm not sure I deserve co-authorship :-)  You're doing all the work, I'm just 
> reporting the regressions.

Heh.  Heh.  Ok.   I honestly thought about putting everyone's name here.

Aldy

Re: *PING* [PATCH] libiberty: allow comments in option file

[Hans-Peter Nilsson]

On Sat, 25 Sep 2021, Hu Jialun wrote:
> Hello,
>
> Sorry for bumping it again but I guess it was getting overlooked.
>
> I am very junior with mailing list open source contributions so please feel
> free to point out if I have inadvertantly done something in an incorrect way.
>
> The archive of the original email can be found at
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579232.html
> and is also appended below.
>
> Best regards,
> Hu Jialun

This looks useful, I hope a reviewer will eventually notice it.
Until then keep pinging (say, weekly)!

A few comments (no pun intended):

>
> > Enables putting line comments into option files included using '@'.
> >
> > Comments begin with a ';' followed by whitespace, and terminates at the
> > end of the line.  Backward compability should be satisfactory since ';'
> > is a character disallowed in DOS filenames and rarely used in filenames
> > or options anywhere else as well.

Perhaps mention that the ';' has to be at the start of the line
to be considered a comment?

Also, while ';' is, as you say, very suitable considering the
context, maybe allow the ubiquitous '#' as well?  Though, I
don't know how common that is in MSWindows and Apple-anything
file-paths, in corner cases.  Thoughts?

> >
> > Related discussion: https://gcc.gnu.org/legacy-ml/gcc/2011-02/msg00422.html
> > ---
> >  libiberty/argv.c  |  5 +
> >  libiberty/testsuite/test-expandargv.c | 12 
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/libiberty/argv.c b/libiberty/argv.c
> > index 48dcd102461..2bc7569b718 100644
> > --- a/libiberty/argv.c
> > +++ b/libiberty/argv.c
> > @@ -194,6 +194,11 @@ char **buildargv (const char *input)
> > {
> >   /* Pick off argv[argc] */
> >   consume_whitespace ();

I'd suggest a comment here as to the purpose, e.g.
  /* Skip comments.  */

> > + if (*input == ';')
> > +   {
> > + for (; *input != '\n' && *input != EOS; ++input);

The ";" (for the empty block) should be at a line by itself,
says the coding-standard.

> > + continue;
> > +   }
> >
> >   if ((maxargc == 0) || (argc >= (maxargc - 1)))
> > {
> > diff --git a/libiberty/testsuite/test-expandargv.c 
> > b/libiberty/testsuite/test-expandargv.c
> > index 56c170f9ec6..5640b2b41cf 100644
> > --- a/libiberty/testsuite/test-expandargv.c
> > +++ b/libiberty/testsuite/test-expandargv.c
> > @@ -142,6 +142,18 @@ const char *test_data[] = {
> >"b",
> >0,
> >
> > +  /* Test 7 - Check for comments in option file.  */
> > +  "abc\n;def\nxy \\;z \\ ;gh",/* Test 7 data */
> > +  ARGV0,
> > +  "@test-expandargv-7.lst",
> > +  0,
> > +  ARGV0,
> > +  "abc",
> > +  "xy",
> > +  ";z",
> > +  " ;gh",
> > +  0,
> > +
> >0 /* Test done marker, don't remove. */
> >  };
> >
> > --
> > 2.33.0
>

Thanks and good luck!

brgds, H-P

Re: [RFC] More jump threading restrictions in the presence of loops.

[Jeff Law via Gcc-patches]

On 10/5/2021 7:33 AM, Aldy Hernandez wrote:


OK?

BTW Jeff, this fixes all the regressions you mention except:

1. pr68911.c

The path not being threaded here is 7->10->11->12.  It crosses loops
multiple times, so I believe the restriction code is correct.

7, 10, 12 are in loop1.
11 is in loop 2.

So we have a path going from loop1 -> loop2 -> loop1.  I can't
conceive any scenario where this is ok, but I can attach the entire IL
if I'm missing something.
Wow.  I'm having trouble seeing how we were threading that, but clearly 
not OK.


2. 961125-1.c

This one is a bit trickier.  Here we're trying to thread the following
conditional, which I mentioned when I contributed this work, we don't
handle (and happens infrequently enough not to matter):

Sorry, I'd forgotten about this case.



+  // Loop 4
+   [local count: 114863531]:
+  # ptr_8 = PHI 
+  if (ptr_8 <   [(void *)":ab" + 3B])
+goto ; [50.00%]
+  else
+goto ; [50.00%]

The hybrid threader doesn't handle  in the final conditional.  As
I mentioned earlier, if this becomes an issue, we can adapt class
pointer_equiv_analyzer like we did for evrp.  I have a gimple FE test
I will contribute as an XFAIL with an associated PR to keep us honest.

That being said... in this particular test, this is all irrelevant
because the path will be disallowed for two reasons:

a) The path crosses loops, and the reason we didn't realize it in the
old code was because the ASSERT_EXPR had pulled the SSA outside the
loop, so it looks like the entire path is l in the same loop.  If you
look at the original IL, it's not.

b) Now the path actually fits the pattern being discussed in this
patch, where there's an early exit out of a loop, so it looks like we
should handle it.  But...in this case, we would fill a presently empty
latch.  Interestingly, the old code didn't catch it, becauseyou
guessed it...there was an ASSERT_EXPR in the latch.

So I argue that even in the absence of MEM_REF handling, we shouldn't
thread this path.
I can live with that too.  I'll set new baselines for visium-elf so that 
these don't show up again.




0001-Loosen-loop-crossing-restriction-in-threader.patch

 From 5abe65668f602d53b8f3dc515508dc4616beb048 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Tue, 5 Oct 2021 15:03:34 +0200
Subject: [PATCH] Loosen loop crossing restriction in threader.

Crossing loops is generally discouraged from the threader, but we can
make an exception when we don't cross the latch or enter another loop,
since this is just an early exit out of the loop.

In fact, the whole threaded path is logically outside the loop.  This
has nice secondary effects.  For example, objects on the threaded path
will no longer necessarily be live throughout the loop, so we can get
register allocation improvements.  The threaded path can physically
move outside the loop resulting in better icache efficiency, etc.

Tested on x86-64 Linux, and on a visium-elf cross making sure that the
following tests do not have an abort in the final assembly:

gcc.c-torture/execute/960218-1.c
gcc.c-torture/execute/visium-pending-4.c
gcc.c-torture/execute/pr58209.c

gcc/ChangeLog:

* tree-ssa-threadupdate.c (jt_path_registry::cancel_invalid_paths):

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/ssa-thread-valid.c: New test.
OK.  I think there may still be some concern if the latch is marked as a 
joiner.    I think we should always reject those before the loop 
optimizers run as the joiner's clone would introduce a second latch.   I 
think that can be handled in a follow-up refinement.








Co-authored-by: Jeff Law 
I'm not sure I deserve co-authorship :-)  You're doing all the work, I'm 
just reporting the regressions.


jeff

[i386] Fix couple of issues in large PIC model on x86-64/VxWorks

[Eric Botcazou via Gcc-patches]

Hi,

the first issue is that the !gotoff_operand path of legitimize_pic_address in 
large PIC model does not make use of REG when it is available, which breaks 
for thunks because new pseudo-registers can no longer be created.  And the 
second issue is that the system compiler (LLVM) generates @GOTOFF in large 
model even for RTP, so we do the same.

Tested on x86-64/Linux and VxWorks, OK for the mainline?


2021-10-05  Eric Botcazou  

* config/i386/i386.c (legitimize_pic_address): Adjust comment and
use the REG argument on the CM_LARGE_PIC code path as well.
* config/i386/predicates.md (gotoff_operand): Do not treat VxWorks
specially with the large code models.

-- 
Eric Botcazoudiff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a566d84a61e..a6784c4e9d6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -11152,7 +11152,7 @@ legitimize_pic_address (rtx orig, rtx reg)
 	new_rtx = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, new_rtx);
 }
   else if ((GET_CODE (addr) == SYMBOL_REF && SYMBOL_REF_TLS_MODEL (addr) == 0)
-	   /* We can't use @GOTOFF for text labels
+	   /* We can't always use @GOTOFF for text labels
 	  on VxWorks, see gotoff_operand.  */
 	   || (TARGET_VXWORKS_RTP && GET_CODE (addr) == LABEL_REF))
 {
@@ -11181,9 +11181,19 @@ legitimize_pic_address (rtx orig, rtx reg)
 	 from the Global Offset Table (@GOT).  */
 	  new_rtx = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr), UNSPEC_GOT);
 	  new_rtx = gen_rtx_CONST (Pmode, new_rtx);
+
 	  if (TARGET_64BIT)
-	new_rtx = force_reg (Pmode, new_rtx);
-	  new_rtx = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, new_rtx);
+	new_rtx = copy_to_suggested_reg (new_rtx, reg, Pmode);
+
+	  if (reg != 0)
+	{
+	  gcc_assert (REG_P (reg));
+	  new_rtx = expand_simple_binop (Pmode, PLUS, pic_offset_table_rtx,
+	 new_rtx, reg, 1, OPTAB_DIRECT);
+	}
+	  else
+	new_rtx = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, new_rtx);
+
 	  new_rtx = gen_const_mem (Pmode, new_rtx);
 	  set_mem_alias_set (new_rtx, ix86_GOT_alias_set ());
 	}
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index df5acb425d4..af2a573f3dd 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -617,9 +617,11 @@
 ;; use @GOTOFF unless we are absolutely sure that the symbol is in the
 ;; same segment as the GOT.  Unfortunately, the flexibility of linker
 ;; scripts means that we can't be sure of that in general, so assume
-;; that @GOTOFF is never valid on VxWorks.
+;; @GOTOFF is not valid on VxWorks, except with the large code model.
 (define_predicate "gotoff_operand"
-  (and (not (match_test "TARGET_VXWORKS_RTP"))
+  (and (ior (not (match_test "TARGET_VXWORKS_RTP"))
+(match_test "ix86_cmodel == CM_LARGE")
+(match_test "ix86_cmodel == CM_LARGE_PIC"))
(match_operand 0 "local_symbolic_operand")))
 
 ;; Test for various thread-local symbols.

[committed] libstdc++: Ensure std::span and std::string_view are trivially copyable (P2251R1)

[Jonathan Wakely via Gcc-patches]

The recently approved P2251R1 paper requires these types to be trivially
copyable. They always have been in libstdc++, but add tests to check it.

libstdc++-v3/ChangeLog:

* 
testsuite/21_strings/basic_string_view/requirements/trivially_copyable.cc:
New test.
* testsuite/23_containers/span/trivially_copyable.cc: New test.

Tested x86_64-linux. Committed to trunk.

commit 1f51e9af7b615838424214e6aaea0de793cb10fe
Author: Jonathan Wakely 
Date:   Tue Oct 5 16:38:42 2021

libstdc++: Ensure std::span and std::string_view are trivially copyable 
(P2251R1)

The recently approved P2251R1 paper requires these types to be trivially
copyable. They always have been in libstdc++, but add tests to check it.

libstdc++-v3/ChangeLog:

* 
testsuite/21_strings/basic_string_view/requirements/trivially_copyable.cc:
New test.
* testsuite/23_containers/span/trivially_copyable.cc: New test.

diff --git 
a/libstdc++-v3/testsuite/21_strings/basic_string_view/requirements/trivially_copyable.cc
 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/requirements/trivially_copyable.cc
new file mode 100644
index 000..3f2589c61d8
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/21_strings/basic_string_view/requirements/trivially_copyable.cc
@@ -0,0 +1,11 @@
+// { dg-do compile { target c++17 } }
+
+// http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2251r1.pdf
+
+#include 
+
+static_assert( std::is_trivially_copyable_v );
+static_assert( std::is_trivially_copyable_v );
+
+struct traits : std::char_traits { };
+static_assert( std::is_trivially_copyable_v> );
diff --git a/libstdc++-v3/testsuite/23_containers/span/trivially_copyable.cc 
b/libstdc++-v3/testsuite/23_containers/span/trivially_copyable.cc
new file mode 100644
index 000..e3748293555
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/span/trivially_copyable.cc
@@ -0,0 +1,13 @@
+// { dg-options "-std=gnu++20" }
+// { dg-do compile { target c++20 } }
+
+// http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2251r1.pdf
+
+#include 
+
+static_assert( std::is_trivially_copyable_v> );
+static_assert( std::is_trivially_copyable_v> );
+
+struct NonTrivial { NonTrivial(); NonTrivial(const NonTrivial&); };
+static_assert( std::is_trivially_copyable_v> );
+static_assert( std::is_trivially_copyable_v> );

Re: [patch][middle-end/PR102359]Not add initialization for DECL_VALUE_EXPR variables with -ftrivial-auto-var-init

[Qing Zhao via Gcc-patches]

This is the updated patch, I will push it after done with testing.

Let me know if you see any issue.

Thanks.

Qing.



>From 1f07c20ecdc9a015369c8bb472ebbd3bcaabdf17 Mon Sep 17 00:00:00 2001
From: qing zhao 
Date: Tue, 5 Oct 2021 08:10:02 -0700
Subject: [PATCH] middle-end/102359 Not add initialization for variables that
 have been  initialized by FEs.

C++ FE creates proxy variables, which have associated DECL_VALUE_EXPR
and have been initialized by FE. For such auto variable, we should not
add initialization when -ftrivial-auto-var-init presents.

gcc/ChangeLog:

2021-10-05  qing zhao  

* gimplify.c (gimplify_decl_expr): Not add initialization for an
auto variable when it has been initialized by frontend.

gcc/testsuite/ChangeLog:

2021-10-05  qing zhao  

* g++.dg/pr102359_1.C: New test.
* g++.dg/pr102359_2.C: New test.
---
 gcc/gimplify.c|  9 -
 gcc/testsuite/g++.dg/pr102359_1.C | 13 +
 gcc/testsuite/g++.dg/pr102359_2.C | 13 +
 3 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/pr102359_1.C
 create mode 100644 gcc/testsuite/g++.dg/pr102359_2.C

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index b27776a..d96fca4 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -1872,6 +1872,9 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
 {
   tree init = DECL_INITIAL (decl);
   bool is_vla = false;
+  /* Check whether a decl has FE created VALUE_EXPR here BEFORE
+gimplify_vla_decl creates VALUE_EXPR for a vla decl.  */
+  bool decl_had_value_expr_p = DECL_HAS_VALUE_EXPR_P (decl);
 
   poly_uint64 size;
   if (!poly_int_tree_p (DECL_SIZE_UNIT (decl), )
@@ -1934,7 +1937,11 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
   /* When there is no explicit initializer, if the user requested,
 We should insert an artifical initializer for this automatic
 variable.  */
-  else if (is_var_need_auto_init (decl))
+  else if (is_var_need_auto_init (decl)
+  /* If the decl has VALUE_EXPR that was created by FE (usually
+ C++FE), it's a proxy varaible, and FE already initialized
+ the VALUE_EXPR of it, we should not initialize it here.  */
+  && !decl_had_value_expr_p)
{
  gimple_add_init_for_auto_var (decl,
flag_auto_var_init,
diff --git a/gcc/testsuite/g++.dg/pr102359_1.C 
b/gcc/testsuite/g++.dg/pr102359_1.C
new file mode 100644
index 000..da643cd
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr102359_1.C
@@ -0,0 +1,13 @@
+/* PR middle-end/102359 ICE gimplification failed since
+   r12-3433-ga25e0b5e6ac8a77a.  */
+/* { dg-do compile } */
+/* { dg-options "-ftrivial-auto-var-init=zero" } */
+/* { dg-require-effective-target c++17 } */
+
+struct A {
+  double a = 111;
+  auto foo() {
+return [*this] { return a; };
+  }
+};
+int X = A{}.foo()();
diff --git a/gcc/testsuite/g++.dg/pr102359_2.C 
b/gcc/testsuite/g++.dg/pr102359_2.C
new file mode 100644
index 000..d026d72
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr102359_2.C
@@ -0,0 +1,13 @@
+/* PR middle-end/102359 ICE gimplification failed since
+   r12-3433-ga25e0b5e6ac8a77a.  */
+/* { dg-do run} */
+/* { dg-options "-ftrivial-auto-var-init=zero" } */
+/* { dg-require-effective-target c++17 } */
+
+int main()
+{
+ int i = 42;
+ auto l = [=]() mutable { return i; };
+ if (l() != i)
+   __builtin_abort ();
+}
-- 
1.9.1

Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors

[Qing Zhao via Gcc-patches]

> On Oct 5, 2021, at 1:25 AM, Richard Biener  wrote:
> 
> On Mon, 4 Oct 2021, Qing Zhao wrote:
> 
>> 
>> 
>>> On Oct 4, 2021, at 12:19 PM, Richard Biener  wrote:
>>> 
>>> On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao  
>>> wrote:
 I have several questions on this fix:
 
 1. This fix avoided expanding “.DEFERRED_INIT” when !tree_fits_uhwi_p 
 (TYPE_SIZE_UNIT (var_type)).
  As a result, this call to .DEFERRED_INIT will NOT be expanded at all.
>>> 
>>> Yes. 
>> 
>> Then, should we exclude such auto init during gimplification phase?
> 
> No, we do want to and can handle such variables just fine.
Okay.
> 
>>> 
  Then not expanding .DEFERRED_INIT in RTL expanding phase will trigger 
 more issues in later RTL phases, this looks not correct to me. (Actually, 
 with is the patch, this testing case still failed in a later RTL stage). 
 
  So, If we really want to avoid auto-init for VLA vectors, we should not 
 add call to .DEFERRED_INIT in gimplification phase at all. 
>> 
>> 
 
 
 2. For the added .DEFERRED_INIT:
 
 __SVFloat64_t f64;
 
 f64 = .DEFERRED_INIT (POLY_INT_CST [16, 16], 2, 0);
 
 What does “POLY_INT_CST[16,16]” mean? Is this a constant size? If YES, 
 what’s the value of it? If Not, can we use “memset” to expand it?
>>> 
>>> When the target is a register memset doesn't work. I'm not sure the memset 
>>> expansion path will work as-is either for aggregates with vla parts -
>> 
>> Stupid question here:  what does POLY_INT_CST[16,16] mean?   It’s not a 
>> constant? 
> 
> It's 16 *  where the factor is determined by the hardware
> implementation but fixed throughout the programs lifetime.  You could
> think of the POLY_INT_CST expanding to a multiplication of 16 by a special
> hardware register.
So, it’s a fixed value but cannot be treated as an constant during compilation 
time?
> 
> For vector types the zero-init could be done using build_zero_cst and
> the expand_assignment path.  Also the memset path should just work
> as well.
> 
> It's the pattern init that's a bit more complicated but I'm sure
> Richard will sort that out.

Okay, so, now we use zeroes for both zero-init and pattern-init for variable 
with “vector types”? 
Shall we document this fact?
> 
> Note TYPE_SIZE_UNIT will honor tree_fits_poly_uint64_p but for the
> pattern init we'd have to repeat the constant and maybe there's
> a clever way to do this repeating just the single pattern byte.
> 
> But as said...
> 
>>> but I'll leave that to Richard S. to sort out. 
> 
> ^^^

okay.

thanks.

Qing
> 
> Richard.
> 
>> 
>>> 
>>> Richard. 
>>> 
 Thanks.
 
 Qing
 
 
 
> On Oct 4, 2021, at 3:57 AM, Richard Biener via Gcc-patches 
>  wrote:
> 
> This avoids ICEing for VLA vector auto-init by not initializing.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
> 
> 2021-10-04  Richard Biener  
> 
>   PR middle-end/102587
>   * internal-fn.c (expand_DEFERRED_INIT): Guard register
>   initialization path an avoid initializing VLA registers
>   with it.
> 
>   * gcc.target/aarch64/sve/pr102587-1.c: New testcase.
>   * gcc.target/aarch64/sve/pr102587-2.c: Likewise.
> ---
> gcc/internal-fn.c | 3 ++-
> gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c | 4 
> gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c | 4 
> 3 files changed, 10 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c
> create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c
> 
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 8312d08aab2..ef5dc90db56 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -3035,7 +3035,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
> /* Expand this memset call.  */
> expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type));
>   }
> -  else
> +  /* ???  Deal with poly-int sized registers.  */
> +  else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))
>   {
> /* If this variable is in a register, use expand_assignment might
>generate better code.  */
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c 
> b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c
> new file mode 100644
> index 000..2b9a68b0b59
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-1.c
> @@ -0,0 +1,4 @@
> +/* { dg-do compile } */
> +/* { dg-options "-ftrivial-auto-var-init=zero" } */
> +
> +void foo() { __SVFloat64_t f64; }
> diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c 
> b/gcc/testsuite/gcc.target/aarch64/sve/pr102587-2.c
> new file mode 100644
> index 000..4cdb9056002
> --- /dev/null
> +++ 

[committed] Fix s390 test to have pointer type for computed goto

[Jeff Law via Gcc-patches]

More minor fallout from Andrew's work. Committed to the trunk.

Jeff
commit f9e6f20f280daf74763cf3fe21f3c211d3d04620
Author: Jeff Law 
Date:   Tue Oct 5 11:15:02 2021 -0400

Fix s390 test to have pointer type for computed goto

gcc/testsuite
* gcc.target/s390/pr80725.c: Ensure computed goto is used on
a pointer type.

diff --git a/gcc/testsuite/gcc.target/s390/pr80725.c 
b/gcc/testsuite/gcc.target/s390/pr80725.c
index 4a402c41422..d556e6ba7ca 100644
--- a/gcc/testsuite/gcc.target/s390/pr80725.c
+++ b/gcc/testsuite/gcc.target/s390/pr80725.c
@@ -18,7 +18,7 @@ foo (int x, int y)
 while (a < x)
   {
if (y)
- goto *d;
+ goto *(void *)d;
g = b | b + g;
bar (g);
c = (char) (long) foo;

Re: [PATCH] c++: Implement C++23 P2334R1 - #elifdef/#elifndef

[Marek Polacek via Gcc-patches]

On Tue, Oct 05, 2021 at 10:35:12AM +0200, Jakub Jelinek wrote:
> Hi!
> 
> This patch implements C++23 P2334R1, which is easy because Joseph has done
> all the hard work for C2X already.
> Unlike the C N2645 paper, the C++ P2334R1 contains one important addition
> (but not in the normative text):
> "While this is a new preprocessor feature and cannot be treated as a defect
> report, implementations that support older versions of the standard are
> encouraged to implement this feature in the older language modes as well
> as C++23."
> so there are different variants how to implement it.
> One is in the patch below, ignores that sentence and only implements it
> for -std=c++23/-std=gnu++23 like it is only implemented for -std=c23.
> Another option would be to implement it also in the older GNU modes but
> not in the C/CXX modes (but it would be strange if we did that just for
> C++ and not for C).
> Yet another option is to enable it unconditionally.

This would work for me, but...

> And yet another option would be to enable it unconditionally but emit
> a warning (or pedwarn) when it is seen.

...frankly, I'd prefer this last option: enable it unconditionally but emit
a pedwarn when -Wpedantic.  I think let's see what Joseph and Jason think
before you change your patch though; don't want to add more work for you.

> Note, when it is enabled for the older language modes, as Joseph wrote
> in the c11-elifdef-1.c testcase, it can result e.g. in rejecting previously
> valid code:
> #define A
> #undef B
> #if 0
> #elifdef A
> #error "#elifdef A applied"
> #endif
> #if 0
> #elifndef B
> #error "#elifndef B applied"
> #endif
> Note, seems clang went the enable it unconditionally in all standard
> versions of both C and C++, no warnings or anything whatsoever, so
> essentially treated it as a DR that changed behavior of e.g. the above code.
> 
> 2021-10-05  Jakub Jelinek  
> 
> libcpp/
>   * init.c (lang_defaults): Implement P2334R1, enable elifdef for
>   -std=c++23 and -std=gnu++23.
> gcc/testsuite/
>   * g++.dg/cpp/elifdef-1.C: New test.
>   * g++.dg/cpp/elifdef-2.C: New test.
>   * g++.dg/cpp/elifdef-3.C: New test.
> 
> --- libcpp/init.c.jj  2021-09-02 10:01:15.954715595 +0200
> +++ libcpp/init.c 2021-10-05 09:55:15.010620700 +0200
> @@ -122,8 +122,8 @@ static const struct lang_flags lang_defa
>/* CXX17*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1,
>  1, 0,   1,  0,   1, 0,   0,   0 },
>/* GNUCXX20 */  { 1,  1,  1,  1,  1,  0,0,  1,   1,   1,   1,1,
>  1, 0,   1,  1,   1, 0,   0,   0 },
>/* CXX20*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1,
>  1, 0,   1,  1,   1, 0,   0,   0 },
> -  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1,
>  1, 0,   1,  1,   1, 0,   1,   0 },
> -  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1,
>  1, 0,   1,  1,   1, 0,   1,   0 },
> +  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1,
>  1, 0,   1,  1,   1, 0,   1,   1 },
> +  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1,
>  1, 0,   1,  1,   1, 0,   1,   1 },
>/* ASM  */  { 0,  0,  1,  0,  0,  0,0,  0,   0,   0,   0,0,
>  0, 0,   0,  0,   0, 0,   0,   0 }
>  };
>  
> --- gcc/testsuite/g++.dg/cpp/elifdef-1.C.jj   2021-10-05 10:00:41.410057024 
> +0200
> +++ gcc/testsuite/g++.dg/cpp/elifdef-1.C  2021-10-05 10:00:33.110173069 
> +0200
> @@ -0,0 +1,3 @@
> +// { dg-do preprocess { target { ! c++23 } } }
> +
> +#include "../../gcc.dg/cpp/c11-elifdef-1.c"
> --- gcc/testsuite/g++.dg/cpp/elifdef-2.C.jj   2021-10-05 10:01:30.345372808 
> +0200
> +++ gcc/testsuite/g++.dg/cpp/elifdef-2.C  2021-10-05 10:03:36.560608083 
> +0200
> @@ -0,0 +1,4 @@
> +// P2334R1
> +// { dg-do preprocess { target c++23 } }
> +
> +#include "../../gcc.dg/cpp/c2x-elifdef-1.c"
> --- gcc/testsuite/g++.dg/cpp/elifdef-3.C.jj   2021-10-05 10:01:36.029293338 
> +0200
> +++ gcc/testsuite/g++.dg/cpp/elifdef-3.C  2021-10-05 10:03:48.896435601 
> +0200
> @@ -0,0 +1,4 @@
> +// P2334R1
> +// { dg-do preprocess { target c++23 } }
> +
> +#include "../../gcc.dg/cpp/c2x-elifdef-1.c"
> 
>   Jakub
> 

Marek

Re: [RFC] More jump threading restrictions in the presence of loops.

[Jeff Law via Gcc-patches]

On 10/5/2021 7:33 AM, Aldy Hernandez wrote:

On Mon, Oct 4, 2021 at 6:29 PM Michael Matz  wrote:

Hello,

On Mon, 4 Oct 2021, Jeff Law wrote:


And just in case it got lost.  Here's the analysis on 960218-1 on visium:

We've got this going into ethread:

int f (int x)
{
   int D.1420;
   int a;

;;   basic block 2, loop depth 0, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
   a_4 = ~x_3(D);
   goto ; [INV]
;;succ:   4 (FALLTHRU,EXECUTABLE)

;;   basic block 3, loop depth 1, maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 (TRUE_VALUE,EXECUTABLE)
   gl = a_1;
;;succ:   4 (FALLTHRU,DFS_BACK,EXECUTABLE)

;;   basic block 4, loop depth 1, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 (FALLTHRU,EXECUTABLE)
;;3 (FALLTHRU,DFS_BACK,EXECUTABLE)
   # a_1 = PHI 
   if (a_1 != 0)
 goto ; [INV]
   else
 goto ; [INV]
;;succ:   3 (TRUE_VALUE,EXECUTABLE)
;;5 (FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 0, maybe hot
;;prev block 4, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 (FALSE_VALUE,EXECUTABLE)
   return;
;;succ:   EXIT

}

First notice that this doesn't have an empty latch block to start with
(in fact, there is no separate latch block at all), so the loop optimizers
haven't been initialized for simple latches at this point.  Still, I would
say that even then we want to be careful with the latch edge, as putting
code onto it will most probably create a problem downstream once we _do_
want to intialize the loop optimizers for simple latches.  So, that we are
careful here is okay, we are just too careful in this specific case.


There's a pretty obvious jump thread in there.  3->4->5.

We used to allow this, but it's currently being rejected and I'm not
sure it should.

In simplest terms we're threading from inside the loop, through the
latch to a point outside the loop.  At first glance, that seems safe.

Is at least the unrestricted jump threader (the one after loop optimizers)
picking this up?

Independend of that, I agree, that this specific instance of threading
through the latch block, even though followed by to-be-copied
instructions, is okay.  We need to determine precisely when that is okay,
though.  In this case there are several reasons I could see why this is
so:
(a) while the thread is through the latch block, it's _not_ through the
 latch edge (which is 4->3).  That would create the problem, so here
 we're fine.

It seems we all agree Jeff's finding should be allowed, so let's
attack this one first, since it gets almost all of his visium
failures.  I can submit the rest of the cases separately.

The attached patch catches the IL discussed, and adds a relevant
gimple FE test others can use for experimenting :).

Tested on x86-64 and by visual inspection on visium-elf on the
regressions Jeff pointed me at.

OK?

BTW Jeff, this fixes all the regressions you mention except:

1. pr68911.c

The path not being threaded here is 7->10->11->12.  It crosses loops
multiple times, so I believe the restriction code is correct.

7, 10, 12 are in loop1.
11 is in loop 2.

So we have a path going from loop1 -> loop2 -> loop1.  I can't
conceive any scenario where this is ok, but I can attach the entire IL
if I'm missing something.

2. 961125-1.c

This one is a bit trickier.  Here we're trying to thread the following
conditional, which I mentioned when I contributed this work, we don't
handle (and happens infrequently enough not to matter):

+  // Loop 4
+   [local count: 114863531]:
+  # ptr_8 = PHI 
+  if (ptr_8 <   [(void *)":ab" + 3B])
+goto ; [50.00%]
+  else
+goto ; [50.00%]

The hybrid threader doesn't handle  in the final conditional.  As
I mentioned earlier, if this becomes an issue, we can adapt class
pointer_equiv_analyzer like we did for evrp.  I have a gimple FE test
I will contribute as an XFAIL with an associated PR to keep us honest.

That being said... in this particular test, this is all irrelevant
because the path will be disallowed for two reasons:

a) The path crosses loops, and the reason we didn't realize it in the
old code was because the ASSERT_EXPR had pulled the SSA outside the
loop, so it looks like the entire path is l in the same loop.  If you
look at the original IL, it's not.

b) Now the path actually fits the pattern being discussed in this
patch, where there's an early exit out of a loop, so it looks like we
should handle it.  But...in this case, we would fill a presently empty
latch.  Interestingly, the old code didn't catch it, becauseyou
guessed it...there was an ASSERT_EXPR in the latch.

So I argue that even in the absence of MEM_REF handling, we shouldn't
thread this path.

0001-Loosen-loop-crossing-restriction-in-threader.patch

 From 5abe65668f602d53b8f3dc515508dc4616beb048 Mon 

Re: [committed] libstdc++: Support printing volatile pointers (P1147R1)

[Jonathan Wakely via Gcc-patches]

On Tue, 5 Oct 2021 at 10:29, Daniel Krügler wrote:
>
> Am Di., 5. Okt. 2021 um 10:55 Uhr schrieb Jonathan Wakely via
> Libstdc++ :
> >
> > To avoid needing to export a new symbol from the library (for now) the
> > new member function uses __attribute__((always_inline)).
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/ostream (operator<<(const volatile void*)):
> > Add new overload, as per P1147R1.
> > * 
> > testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc:
> > New test.
> >
> > Tested powerpc64le-linux. Committed to trunk.
>
> I think the test is insufficient, because it will succeed on every
> library implementation regardless of the new feature. Without the new
> feature it will select the unexpected operator<<(bool) overload and
> just print "1".

Yes, that's true. I did test it locally (and the function is
ridiculously simple), and the main purpose of that test was to ensure
we don't fail to link due to the new member not being explicitly
instantiated in the library. But we might as well make the test do
something more useful.

Done by the attached patch, tested x86_64-linux, pushed to trunk.
commit 313193edfc3986c40dedce3d0b41455d0bcdbe43
Author: Jonathan Wakely 
Date:   Tue Oct 5 14:45:11 2021

libstdc++: Improve test for printing volatile pointers

libstdc++-v3/ChangeLog:

* 
testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc:
Check result matches non-volatile pointer.

diff --git 
a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc
 
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc
index 1b1a9434a95..151e13d3bdd 100644
--- 
a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc
+++ 
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc
@@ -1,11 +1,15 @@
 // { dg-options "-std=gnu++23 -fno-inline" }
-// { dg-do link { target c++23 } }
+// { dg-do run { target c++23 } }
 
-#include 
+#include 
+#include 
 
 int main()
 {
   int i = 0;
-  volatile void* p = 
-  std::cout << p << std::endl;
+  volatile void* vp = 
+  std::ostringstream s1, s2;
+  s1 << 
+  s2 << vp;
+  VERIFY( s1.str() == s2.str() );
 }

Re: PING: [AVR] Fix unused argument warning

[Jeff Law via Gcc-patches]

On 10/5/2021 9:03 AM, Jan-Benedict Glaw wrote:

Hi Jeff,

On Tue, 2021-10-05 08:53:00 -0600, Jeff Law  wrote:

On 10/5/2021 8:46 AM, Jan-Benedict Glaw wrote:

On Thu, 2021-09-30 21:27:23 +0200, Jan-Benedict Glaw  wrote:

gcc/ChangeLog:

* common/config/avr/avr-common.c (avr_handle_option): Mark
argument as ATTRIBUTE_UNUSED.

diff --git a/gcc/common/config/avr/avr-common.c 
b/gcc/common/config/avr/avr-common.c
index 6486659d27c..a6939ad03d3 100644
--- a/gcc/common/config/avr/avr-common.c
+++ b/gcc/common/config/avr/avr-common.c
@@ -77,7 +77,8 @@ static const struct default_options 
avr_option_optimization_table[] =
   static bool
   avr_handle_option (struct gcc_options *opts, struct gcc_options*,
-   const struct cl_decoded_option *decoded, location_t loc)
+   const struct cl_decoded_option *decoded,
+   location_t loc ATTRIBUTE_UNUSED)
   {
 int value = decoded->value;


Ok for trunk?

Wanted to give this a ping.

I thought I sent a reply a few days ago.  Instead of using ATTRIBUTE_UNUSED,
just drop the parameter's name.  You should consider that pre-approved for
this and any other cases you run into.

Not quite I think. The `loc`ation parameter is used under some
circumstances, though it's dependant on some #ifdefs:
Sigh.  We rooted out most of those kinds of conditional compilation from 
the core compiler years ago for precisely these kinds of reasons.  Go 
ahead with the ATTRIBUTE_UNUSED in this case.  But generally dropping 
the argument's name is better.  Extra points if you killed the 
conditional compilation in the avr backend, but I don't think that 
should be a requirement to move forward.


Jeff

Re: PING: [AVR] Fix unused argument warning

[Jan-Benedict Glaw]

Hi Jeff,

On Tue, 2021-10-05 08:53:00 -0600, Jeff Law  wrote:
> On 10/5/2021 8:46 AM, Jan-Benedict Glaw wrote:
> > On Thu, 2021-09-30 21:27:23 +0200, Jan-Benedict Glaw  
> > wrote:
> > > gcc/ChangeLog:
> > > 
> > >   * common/config/avr/avr-common.c (avr_handle_option): Mark
> > >   argument as ATTRIBUTE_UNUSED.
> > > 
> > > diff --git a/gcc/common/config/avr/avr-common.c 
> > > b/gcc/common/config/avr/avr-common.c
> > > index 6486659d27c..a6939ad03d3 100644
> > > --- a/gcc/common/config/avr/avr-common.c
> > > +++ b/gcc/common/config/avr/avr-common.c
> > > @@ -77,7 +77,8 @@ static const struct default_options 
> > > avr_option_optimization_table[] =
> > >   static bool
> > >   avr_handle_option (struct gcc_options *opts, struct gcc_options*,
> > > -   const struct cl_decoded_option *decoded, location_t 
> > > loc)
> > > +   const struct cl_decoded_option *decoded,
> > > +   location_t loc ATTRIBUTE_UNUSED)
> > >   {
> > > int value = decoded->value;
> > > 
> > > 
> > >Ok for trunk?
> > Wanted to give this a ping.
> I thought I sent a reply a few days ago.  Instead of using ATTRIBUTE_UNUSED,
> just drop the parameter's name.  You should consider that pre-approved for
> this and any other cases you run into.

Not quite I think. The `loc`ation parameter is used under some
circumstances, though it's dependant on some #ifdefs:

 78 static bool
 79 avr_handle_option (struct gcc_options *opts, struct gcc_options*,
 80const struct cl_decoded_option *decoded,
 81location_t loc ATTRIBUTE_UNUSED)
 82 {
 83   int value = decoded->value;
 84 
 85   switch (decoded->opt_index)
 86 {
 87 case OPT_mdouble_:
 88   if (value == 64)
 89 {
 90 #if !defined (HAVE_DOUBLE64)
 91   error_at (loc, "option %<-mdouble=64%> is only available if "
 92 "configured %<--with-double={64|64,32|32,64}%>");
 93 #endif
 94   opts->x_avr_long_double = 64;
 95 }
 96   else if (value == 32)
 97 {
 98 #if !defined (HAVE_DOUBLE32)
 99   error_at (loc, "option %<-mdouble=32%> is only available if "
100 "configured %<--with-double={32|32,64|64,32}%>");
101 #endif
102 }

Also, this implements the TARGET_HANDLE_OPTION function, so changing
the arguments wouldn't really work and as the `loc` argument is used
under certain circumstances, I kept it as is and marked it unused.
(Adding an #ifdef in front doesn't make the code any more readable.)

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Re: [PATCH] libiberty: prevent buffer overflow when decoding user input

[Jeff Law via Gcc-patches]

On 10/4/2021 10:52 AM, Luís Ferreira wrote:

On Thu, 2021-09-23 at 09:50 -0600, Jeff Law wrote:


On 9/23/2021 4:16 AM, ibuclaw--- via Gcc-patches wrote:

On 22/09/2021 03:10 Luís Ferreira  wrote:

   
Currently a stack/heap overflow may happen if a crafted mangle is

maliciously used to cause denial of service, such as intentional
crashes
by accessing a reserved memory space.


Hi,

Thanks for this.  Is there a test that could trigger this code
path?

I don't think Luis has commit privs, so I went ahead and committed
this
patch.

Yea, a testcase would be great.

Jeff


Does the test suite runned against address sanitization? if yes, I can
submit a patch to make this fail, otherwise it is hard to trigger a
consistent crash for this issue.
Unfortunately, no it doesn't run with sanitization.  If it's too painful 
to create a test, don't worry about it.  It happens from time to time.


jeff

[committed] libstdc++: Add test for std::cmp_greater

[Jonathan Wakely via Gcc-patches]

This was omitted from the commit that added these comparisons.

libstdc++-v3/ChangeLog:

* testsuite/20_util/integer_comparisons/greater.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

commit 824e0855732c601e0866d0e8a9264a85f758213e
Author: Jonathan Wakely 
Date:   Tue Oct 5 10:38:03 2021

libstdc++: Add test for std::cmp_greater

This was omitted from the commit that added these comparisons.

libstdc++-v3/ChangeLog:

* testsuite/20_util/integer_comparisons/greater.cc: New test.

diff --git a/libstdc++-v3/testsuite/20_util/integer_comparisons/greater.cc 
b/libstdc++-v3/testsuite/20_util/integer_comparisons/greater.cc
new file mode 100644
index 000..e564d8d03f2
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/integer_comparisons/greater.cc
@@ -0,0 +1,61 @@
+// { dg-options "-std=gnu++20" }
+// { dg-do run { target c++20 } }
+
+#include 
+#include 
+#include 
+
+void
+test01()
+{
+  unsigned int u = std::numeric_limits::max();
+  int s = -1;
+  VERIFY( !std::cmp_greater(s, u) );
+  VERIFY( std::cmp_greater(u, s) );
+  u = (unsigned) std::numeric_limits::max() + 1U;
+  VERIFY( !std::cmp_greater(s, u) );
+  VERIFY( std::cmp_greater(u, s) );
+}
+
+constexpr bool
+test02()
+{
+  unsigned int u = std::numeric_limits::max();
+  int s = -1;
+  if (std::cmp_greater(s, u))
+throw 1;
+  if (!std::cmp_greater(u, s))
+throw 2;
+  return true;
+}
+
+void
+test03()
+{
+  short ss = -1;
+  int s = -1;
+  VERIFY( !std::cmp_greater(s, ss) );
+  VERIFY( !std::cmp_greater(ss, s) );
+
+  unsigned int u = (unsigned int) -1;
+  VERIFY( !std::cmp_greater(s, u) );
+  VERIFY( std::cmp_greater(u, s) );
+  VERIFY( !std::cmp_greater(ss, u) );
+  VERIFY( std::cmp_greater(u, ss) );
+
+  unsigned long long ul = (unsigned long long) -1;
+  VERIFY( !std::cmp_greater(s, ul) );
+  VERIFY( std::cmp_greater(ul, s) );
+  VERIFY( !std::cmp_greater(ss, ul) );
+  VERIFY( std::cmp_greater(ul, ss) );
+  VERIFY( !std::cmp_greater(u, ul) );
+  VERIFY( std::cmp_greater(ul, u) );
+}
+
+int
+main()
+{
+  test01();
+  static_assert( test02() );
+  test03();
+}

[committed] libstdc++: Simplify constraints for std::any construction

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* include/bits/utility.h (__is_in_place_type_v): Define
variable template to detect in_place_type_t specializations.
(__is_in_place_type): Replace class template with alias
template using __is_in_place_type_v.
* include/std/any (any(T&&)): Check __is_in_place_type first and
avoid instantiating is_copy_constructible unnecessarily.

Tested powerpc64le-linux. Committed to trunk.

commit 6da36b7d0e43b6f9281c65c19a025d4888a25b2d
Author: Jonathan Wakely 
Date:   Mon Oct 4 23:14:30 2021

libstdc++: Simplify constraints for std::any construction

libstdc++-v3/ChangeLog:

* include/bits/utility.h (__is_in_place_type_v): Define
variable template to detect in_place_type_t specializations.
(__is_in_place_type): Replace class template with alias
template using __is_in_place_type_v.
* include/std/any (any(T&&)): Check __is_in_place_type first and
avoid instantiating is_copy_constructible unnecessarily.

diff --git a/libstdc++-v3/include/bits/utility.h 
b/libstdc++-v3/include/bits/utility.h
index 96d350874d9..fce52a4530d 100644
--- a/libstdc++-v3/include/bits/utility.h
+++ b/libstdc++-v3/include/bits/utility.h
@@ -184,17 +184,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline constexpr in_place_index_t<_Idx> in_place_index{};
 
   template
-struct __is_in_place_type_impl : false_type
-{ };
+inline constexpr bool __is_in_place_type_v = false;
 
   template
-struct __is_in_place_type_impl> : true_type
-{ };
+inline constexpr bool __is_in_place_type_v> = true;
 
   template
-struct __is_in_place_type
-  : public __is_in_place_type_impl<_Tp>
-{ };
+using __is_in_place_type = bool_constant<__is_in_place_type_v<_Tp>>;
+
 #endif // C++17
 #endif // C++14
 
diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 625cac619f0..e3d9d774de4 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -183,8 +183,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 /// Construct with a copy of @p __value as the contained object.
 template ,
  typename _Mgr = _Manager<_VTp>,
- enable_if_t::value
- && !__is_in_place_type<_VTp>::value, bool> = true>
+ typename = _Require<__not_<__is_in_place_type<_VTp>>,
+ is_copy_constructible<_VTp>>>
   any(_Tp&& __value)
   : _M_manager(&_Mgr::_S_manage)
   {

Re: [RFC] More jump threading restrictions in the presence of loops.

[Jeff Law via Gcc-patches]

On 10/5/2021 5:22 AM, Richard Biener wrote:

On Mon, Oct 4, 2021 at 6:29 PM Michael Matz  wrote:

Hello,

On Mon, 4 Oct 2021, Jeff Law wrote:


And just in case it got lost.  Here's the analysis on 960218-1 on visium:

We've got this going into ethread:

int f (int x)
{
   int D.1420;
   int a;

;;   basic block 2, loop depth 0, maybe hot
;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
   a_4 = ~x_3(D);
   goto ; [INV]
;;succ:   4 (FALLTHRU,EXECUTABLE)

;;   basic block 3, loop depth 1, maybe hot
;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 (TRUE_VALUE,EXECUTABLE)
   gl = a_1;
;;succ:   4 (FALLTHRU,DFS_BACK,EXECUTABLE)

;;   basic block 4, loop depth 1, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 (FALLTHRU,EXECUTABLE)
;;3 (FALLTHRU,DFS_BACK,EXECUTABLE)
   # a_1 = PHI 
   if (a_1 != 0)
 goto ; [INV]
   else
 goto ; [INV]
;;succ:   3 (TRUE_VALUE,EXECUTABLE)
;;5 (FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 0, maybe hot
;;prev block 4, next block 1, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 (FALSE_VALUE,EXECUTABLE)
   return;
;;succ:   EXIT

}

First notice that this doesn't have an empty latch block to start with
(in fact, there is no separate latch block at all), so the loop optimizers
haven't been initialized for simple latches at this point.  Still, I would
say that even then we want to be careful with the latch edge, as putting
code onto it will most probably create a problem downstream once we _do_
want to intialize the loop optimizers for simple latches.  So, that we are
careful here is okay, we are just too careful in this specific case.

Not sure if the argument about empty or not empty latches is important...

There's a pretty obvious jump thread in there.  3->4->5.

We used to allow this, but it's currently being rejected and I'm not
sure it should.

In simplest terms we're threading from inside the loop, through the
latch to a point outside the loop.  At first glance, that seems safe.

All threadings that start inside the loop and end outside of it are OK
in principle.  Even if the path crosses the latch or the header.
I generally agree, but with one caveat.  If the latch is marked as a 
joiner block, then it will not be OK as that'll create multiple 
backedges to the top of the loop.



Jeff

Re: PING: [LM32] Fix '"LINK_GCC_C_SEQUENCE_SPEC" redefined' warning

[Jeff Law via Gcc-patches]

On 10/5/2021 8:46 AM, Jan-Benedict Glaw wrote:

Hi,

On Thu, 2021-09-30 21:34:51 +0200, Jan-Benedict Glaw  wrote:

gcc/ChangeLog:

* config/lm32/uclinux-elf.h (LINK_GCC_C_SEQUENCE_SPEC):
Undefine before redefinition.

diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
index 370df4c55dd..5b638fa5db2 100644
--- a/gcc/config/lm32/uclinux-elf.h
+++ b/gcc/config/lm32/uclinux-elf.h
@@ -67,6 +67,7 @@
  
  #define TARGET_OS_CPP_BUILTINS() GNU_USER_TARGET_OS_CPP_BUILTINS()
  
+#undef LINK_GCC_C_SEQUENCE_SPEC

  #define LINK_GCC_C_SEQUENCE_SPEC \
"%{static|static-pie:--start-group} %G %{!nolibc:%L} \
 %{static|static-pie:--end-group}%{!static:%{!static-pie:%G}}"

Ok for trunk?

...and a ping for this patch.

OK
jeff

Re: PING: [AVR] Fix unused argument warning

[Jeff Law via Gcc-patches]

On 10/5/2021 8:46 AM, Jan-Benedict Glaw wrote:

Hi,

On Thu, 2021-09-30 21:27:23 +0200, Jan-Benedict Glaw  wrote:

gcc/ChangeLog:

* common/config/avr/avr-common.c (avr_handle_option): Mark
argument as ATTRIBUTE_UNUSED.

diff --git a/gcc/common/config/avr/avr-common.c 
b/gcc/common/config/avr/avr-common.c
index 6486659d27c..a6939ad03d3 100644
--- a/gcc/common/config/avr/avr-common.c
+++ b/gcc/common/config/avr/avr-common.c
@@ -77,7 +77,8 @@ static const struct default_options 
avr_option_optimization_table[] =
  
  static bool

  avr_handle_option (struct gcc_options *opts, struct gcc_options*,
-   const struct cl_decoded_option *decoded, location_t loc)
+   const struct cl_decoded_option *decoded,
+   location_t loc ATTRIBUTE_UNUSED)
  {
int value = decoded->value;
  



   Ok for trunk?

Wanted to give this a ping.
I thought I sent a reply a few days ago.  Instead of using 
ATTRIBUTE_UNUSED, just drop the parameter's name.  You should consider 
that pre-approved for this and any other cases you run into.


jeff

PING: [LM32] Fix '"LINK_GCC_C_SEQUENCE_SPEC" redefined' warning

[Jan-Benedict Glaw]

Hi,

On Thu, 2021-09-30 21:34:51 +0200, Jan-Benedict Glaw  wrote:
> gcc/ChangeLog:
> 
>   * config/lm32/uclinux-elf.h (LINK_GCC_C_SEQUENCE_SPEC):
>   Undefine before redefinition.
> 
> diff --git a/gcc/config/lm32/uclinux-elf.h b/gcc/config/lm32/uclinux-elf.h
> index 370df4c55dd..5b638fa5db2 100644
> --- a/gcc/config/lm32/uclinux-elf.h
> +++ b/gcc/config/lm32/uclinux-elf.h
> @@ -67,6 +67,7 @@
>  
>  #define TARGET_OS_CPP_BUILTINS() GNU_USER_TARGET_OS_CPP_BUILTINS()
>  
> +#undef LINK_GCC_C_SEQUENCE_SPEC
>  #define LINK_GCC_C_SEQUENCE_SPEC \
>"%{static|static-pie:--start-group} %G %{!nolibc:%L} \
> %{static|static-pie:--end-group}%{!static:%{!static-pie:%G}}"
> 
> Ok for trunk?

...and a ping for this patch.

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

PING: [AVR] Fix unused argument warning

[Jan-Benedict Glaw]

Hi,

On Thu, 2021-09-30 21:27:23 +0200, Jan-Benedict Glaw  wrote:
> gcc/ChangeLog:
> 
>   * common/config/avr/avr-common.c (avr_handle_option): Mark
>   argument as ATTRIBUTE_UNUSED.
> 
> diff --git a/gcc/common/config/avr/avr-common.c 
> b/gcc/common/config/avr/avr-common.c
> index 6486659d27c..a6939ad03d3 100644
> --- a/gcc/common/config/avr/avr-common.c
> +++ b/gcc/common/config/avr/avr-common.c
> @@ -77,7 +77,8 @@ static const struct default_options 
> avr_option_optimization_table[] =
>  
>  static bool
>  avr_handle_option (struct gcc_options *opts, struct gcc_options*,
> -   const struct cl_decoded_option *decoded, location_t loc)
> +   const struct cl_decoded_option *decoded,
> +   location_t loc ATTRIBUTE_UNUSED)
>  {
>int value = decoded->value;
>  
> 
> 
>   Ok for trunk?

Wanted to give this a ping.

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

[PATCH] Fix check C99 TR1 support

[Petr Mikhalicin]

From: Petr Mikhalicin 

Autotools tests for libstdc++ check only declaration of required
symbols, but some symbols may not be defined.

This patch adds trying to link "C99 TR1" tests, not only compile them.

Signed-off-by: Petr Mikhalicin 
---
 libstdc++-v3/acinclude.m4 | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 90ecc4a87a2..8bf8b884a7c 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -1645,7 +1645,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   ac_c99_complex_tr1=no;
   if test x"$ac_has_complex_h" = x"yes"; then
 AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
-AC_TRY_COMPILE([#include ],
+AC_TRY_LINK(   [#include ],
   [typedef __complex__ float float_type; float_type tmpf;
cacosf(tmpf);
casinf(tmpf);
@@ -1680,7 +1680,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   # Check for the existence of  functions.
   AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
   AC_CACHE_VAL(glibcxx_cv_c99_ctype_tr1, [
-  AC_TRY_COMPILE([#include ],
+  AC_TRY_LINK(   [#include ],
 [int ch;
  int ret;
  ret = isblank(ch);
@@ -1699,7 +1699,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   ac_c99_fenv_tr1=no;
   if test x"$ac_has_fenv_h" = x"yes"; then
 AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
-AC_TRY_COMPILE([#include ],
+AC_TRY_LINK(   [#include ],
   [int except, mode;
fexcept_t* pflag;
fenv_t* penv;
@@ -1727,7 +1727,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   # Check for the existence of  types.
   AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
   AC_CACHE_VAL(glibcxx_cv_c99_stdint_tr1, [
-  AC_TRY_COMPILE([#define __STDC_LIMIT_MACROS
+  AC_TRY_LINK(   [#define __STDC_LIMIT_MACROS
  #define __STDC_CONSTANT_MACROS
  #include ],
 [typedef int8_t  my_int8_t;
@@ -1827,7 +1827,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   # Check for the existence of  functions.
   AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
   AC_CACHE_VAL(glibcxx_cv_c99_math_tr1, [
-  AC_TRY_COMPILE([#include ],
+  AC_TRY_LINK(   [#include ],
 [typedef double_t  my_double_t;
  typedef float_t   my_float_t;
  acosh(0.0);
@@ -1949,7 +1949,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   darwin*)
 AC_MSG_CHECKING([for ISO C99 rounding functions in ])
 AC_CACHE_VAL(glibcxx_cv_c99_math_llround, [
-  AC_TRY_COMPILE([#include ],
+AC_TRY_LINK([#include ],
 [llrint(0.0);
  llrintf(0.0f);
  llrintl(0.0l);
@@ -1974,7 +1974,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   ac_c99_inttypes_tr1=no;
   if test x"$glibcxx_cv_c99_stdint_tr1" = x"yes"; then
 AC_MSG_CHECKING([for ISO C99 support to TR1 in ])
-AC_TRY_COMPILE([#include ],
+AC_TRY_LINK(   [#include ],
   [intmax_t i, numer, denom, base;
const char* s;
char** endptr;
@@ -1996,7 +1996,7 @@ AC_DEFUN([GLIBCXX_CHECK_C99_TR1], [
   ac_c99_inttypes_wchar_t_tr1=no;
   if test x"$glibcxx_cv_c99_stdint_tr1" = x"yes"; then
 AC_MSG_CHECKING([for wchar_t ISO C99 support to TR1 in ])
-AC_TRY_COMPILE([#include ],
+AC_TRY_LINK(   [#include ],
   [intmax_t base;
const wchar_t* s;
wchar_t** endptr;
-- 
2.31.1

Re: [patch][middle-end/PR102359]Not add initialization for DECL_VALUE_EXPR variables with -ftrivial-auto-var-init

[Qing Zhao via Gcc-patches]

> On Oct 5, 2021, at 3:19 AM, Richard Biener  wrote:
> 
> On Tue, 5 Oct 2021, Qing Zhao wrote:
> 
>> Hi, 
>> 
>> This is the patch to fix this issue based on our discussion.
>> 
>> I have tested it on aarch64 with bootstrap and regtests. X86 bootstrap was 
>> done, regtests is ongoing.
>> 
>> Okay for trunk?
>> 
>> Thanks.
>> 
>> Qing
>> 
>> ==
>> From d349ef0145512efe7f9af2c6bbd01f636475bce3 Mon Sep 17 00:00:00 2001
>> From: qing zhao 
>> Date: Mon, 4 Oct 2021 15:26:03 -0700
>> Subject: [PATCH] middle-end/102359 Not add initialization for variables that
>> have been  initialized by FEs.
>> 
>> C++ FE creates proxy variables, which have associated DECL_VALUE_EXPR
>> and have been initialized by FE. For such auto variable, we should not
>> add initialization when -ftrivial-auto-var-init presents.
>> 
>> gcc/ChangeLog:
>> 
>> 2021-10-04  qing zhao  
>> 
>>  * gimplify.c (is_decl_init_by_fe): New function.
>>  (gimplify_decl_expr): Not add initialization for an auto variable
>>  when it has been initialized by frontend.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> 2021-10-04  qing zhao  
>> 
>>  * g++.dg/pr102359_1.C: New test.
>>  * g++.dg/pr102359_2.C: New test.
>> ---
>> gcc/gimplify.c| 21 -
>> gcc/testsuite/g++.dg/pr102359_1.C | 13 +
>> gcc/testsuite/g++.dg/pr102359_2.C | 13 +
>> 3 files changed, 46 insertions(+), 1 deletion(-)
>> create mode 100644 gcc/testsuite/g++.dg/pr102359_1.C
>> create mode 100644 gcc/testsuite/g++.dg/pr102359_2.C
>> 
>> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
>> index b27776a..d6865ad 100644
>> --- a/gcc/gimplify.c
>> +++ b/gcc/gimplify.c
>> @@ -1819,6 +1819,19 @@ gimple_add_padding_init_for_auto_var (tree decl, bool 
>> is_vla,
>>   gimplify_seq_add_stmt (seq_p, call);
>> }
>> 
>> +/* Return true if the DECL is initialized by FE.
>> +   If the VAR_DECL has DECL_VALUE_EXPR that was created by FE (usually 
>> C++FE),
>> +   it's a proxy varaible, and FE already initializd the DECL_VALUE_EXPR of 
>> it.
>> +*/
>> +static bool
>> +is_decl_init_by_fe (tree decl, bool is_created_by_fe)
>> +{
>> +  if (DECL_HAS_VALUE_EXPR_P (decl)
>> +  && is_created_by_fe)
>> +return true;
>> +  return false;
>> +}
>> +
>> /* Return true if the DECL need to be automaticly initialized by the
>>compiler.  */
>> static bool
>> @@ -1871,8 +1884,13 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
>>   if (VAR_P (decl) && !DECL_EXTERNAL (decl))
>> {
>>   tree init = DECL_INITIAL (decl);
>> +  bool is_value_expr_created_by_fe = false;
> 
> no need for the = false, it's always initialized below.
> 
>>   bool is_vla = false;
>> 
>> +  /* Check whether a decl has FE created VALUE_EXPR here BEFORE 
>> + gimplify_vla_decl creates VALUE_EXPR for vla decl.  */
>> +  is_value_expr_created_by_fe = DECL_HAS_VALUE_EXPR_P (decl);
> 
> That looks a bit weird when looking at ...
> 
>> +
>>   poly_uint64 size;
>>   if (!poly_int_tree_p (DECL_SIZE_UNIT (decl), )
>>|| (!TREE_STATIC (decl)
>> @@ -1934,7 +1952,8 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
>>   /* When there is no explicit initializer, if the user requested,
>>   We should insert an artifical initializer for this automatic
>>   variable.  */
>> -  else if (is_var_need_auto_init (decl))
>> +  else if (is_var_need_auto_init (decl)
>> +   && !is_decl_init_by_fe (decl, is_value_expr_created_by_fe))
> 
> ... which just expands to
> 
> if (DECL_HAS_VALUE_EXPR_P (decl) && DECL_HAS_VALUE_EXPR_P (decl))
> 
> can you please name 'is_value_expr_created_by_fe' as
> 'decl_had_value_expr_p' and check && !decl_had_value_expr_p here?
> So sth like

I can do this -:) I agree that the change will make the code simpler.

However, my major concern with this change is: later when people look at this 
change, they might ask:
Why we should not initialize a variable with VALUE_EXPR? And whether the 
variable whose VALUE_EXPR 
was created by “gimplify_vla_decl” should be excluded? 

My new function and comments were all for this purpose.

If I go with this change, at least we should add some comments to explain this 
as following, what do you think?
> 
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index b27776af7c8..9013f385f13 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -1872,6 +1872,7 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
> {
>   tree init = DECL_INITIAL (decl);
>   bool is_vla = false;

   + /* Check whether a decl has FE created VALUE_EXPR here BEFORE 
   + gimplify_vla_decl creates VALUE_EXPR for vla decl.  */

> +  bool decl_had_value_expr_p = DECL_HAS_VALUE_EXPR_P (decl);
> 
>   poly_uint64 size;
>   if (!poly_int_tree_p (DECL_SIZE_UNIT (decl), )
> @@ -1934,7 +1935,8 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
>   /* When there is no explicit initializer, if the user requested,
> We should 

RE: [PATCH]middle-end convert negate + right shift into compare greater.

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Richard Earnshaw 
> Sent: Tuesday, October 5, 2021 2:52 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: Re: [PATCH]middle-end convert negate + right shift into compare
> greater.
> 
> 
> 
> On 05/10/2021 14:49, Tamar Christina wrote:
> >> -Original Message-
> >> From: Richard Earnshaw 
> >> Sent: Tuesday, October 5, 2021 2:34 PM
> >> To: Tamar Christina ;
> >> gcc-patches@gcc.gnu.org
> >> Cc: nd ; rguent...@suse.de
> >> Subject: Re: [PATCH]middle-end convert negate + right shift into
> >> compare greater.
> >>
> >>
> >>
> >> On 05/10/2021 14:30, Tamar Christina wrote:
> >>>
> >>>
>  -Original Message-
>  From: Richard Earnshaw 
>  Sent: Tuesday, October 5, 2021 1:56 PM
>  To: Tamar Christina ;
>  gcc-patches@gcc.gnu.org
>  Cc: nd ; rguent...@suse.de
>  Subject: Re: [PATCH]middle-end convert negate + right shift into
>  compare greater.
> 
> 
> 
>  On 05/10/2021 13:50, Tamar Christina via Gcc-patches wrote:
> > Hi All,
> >
> > This turns an inversion of the sign bit + arithmetic right shift
> > into a comparison with 0.
> >
> > i.e.
> >
> > void fun1(int32_t *x, int n)
> > {
> >for (int i = 0; i < (n & -16); i++)
> >  x[i] = (-x[i]) >> 31;
> > }
> >
>  Notwithstanding that I think shifting a negative value right is
>  unspecified behaviour, I don't think this generates the same result
>  when x[i] is INT_MIN either, although negating that is also
>  unspecified since it can't be represented in an int.
> 
> >>>
> >>> You're right that they are implementation defined, but I think most
> >>> ISAs do have a sane Implementation of these two cases. At least both
> >>> x86 and AArch64 just replicate the signbit and for negate do two
> >> complement negation. So INT_MIN works as expected and results in 0.
> >>
> >> Which is not what the original code produces if you have wrapping
> >> ints, because -INT_MIN is INT_MIN, and thus still negative.
> >>
> >
> > True, but then you have a signed overflow which is undefined behaviour
> > and not implementation defined
> >
> > " If an exceptional condition occurs during the evaluation of an expression
> (that is, if the result is not mathematically defined or not in the range of
> representable values for its type), the behavior is undefined."
> >
> > So it should still be acceptable to do in this case.
> 
> -fwrapv

If I understand correctly, you're happy with this is I guard it on ! flag_wrapv 
?

Regards,
Tamar
> 
> R.
> 
> >
> >> R.
> >>
> >>>
> >>> But I'm happy to guard this behind some sort of target guard.
> >>>
> >>> Regards,
> >>> Tamar
> >>>
>  R.
> 
> > now generates:
> >
> > .L3:
> >ldr q0, [x0]
> >cmgtv0.4s, v0.4s, #0
> >str q0, [x0], 16
> >cmp x0, x1
> >bne .L3
> >
> > instead of:
> >
> > .L3:
> >ldr q0, [x0]
> >neg v0.4s, v0.4s
> >sshrv0.4s, v0.4s, 31
> >str q0, [x0], 16
> >cmp x0, x1
> >bne .L3
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu,
> > x86_64-pc-linux-gnu and no regressions.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * match.pd: New negate+shift pattern.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/signbit-2.c: New test.
> > * gcc.dg/signbit-3.c: New test.
> > * gcc.target/aarch64/signbit-1.c: New test.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/match.pd b/gcc/match.pd index
> 
> >>
> 7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7
>  190c96d14398143 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > { tree utype = unsigned_type_for (type); }
> > (convert (rshift (lshift (convert:utype @0) @2) @3))
> >
> > +/* Fold (-x >> C) into x > 0 where C = precision(type) - 1.  */
> > +(for cst (INTEGER_CST VECTOR_CST)  (simplify
> > +  (rshift (negate:s @0) cst@1)
> > +   (with { tree ctype = TREE_TYPE (@0);
> > +  tree stype = TREE_TYPE (@1);
> > +  tree bt = truth_type_for (ctype); }
> > +(switch
> > + /* Handle scalar case.  */
> > + (if (INTEGRAL_TYPE_P (ctype)
> > + && !VECTOR_TYPE_P (ctype)
> > + && !TYPE_UNSIGNED (ctype)
> > + && canonicalize_math_after_vectorization_p ()
> > + && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) -
> 1))
> > +  (convert:bt (gt:bt @0 { build_zero_cst (stype); })))
> > + /* Handle vector case 

Re: [PATCH]middle-end convert negate + right shift into compare greater.

[Richard Earnshaw via Gcc-patches]

On 05/10/2021 14:49, Tamar Christina wrote:

-Original Message-
From: Richard Earnshaw 
Sent: Tuesday, October 5, 2021 2:34 PM
To: Tamar Christina ; gcc-patches@gcc.gnu.org
Cc: nd ; rguent...@suse.de
Subject: Re: [PATCH]middle-end convert negate + right shift into compare
greater.



On 05/10/2021 14:30, Tamar Christina wrote:




-Original Message-
From: Richard Earnshaw 
Sent: Tuesday, October 5, 2021 1:56 PM
To: Tamar Christina ;
gcc-patches@gcc.gnu.org
Cc: nd ; rguent...@suse.de
Subject: Re: [PATCH]middle-end convert negate + right shift into
compare greater.



On 05/10/2021 13:50, Tamar Christina via Gcc-patches wrote:

Hi All,

This turns an inversion of the sign bit + arithmetic right shift
into a comparison with 0.

i.e.

void fun1(int32_t *x, int n)
{
   for (int i = 0; i < (n & -16); i++)
 x[i] = (-x[i]) >> 31;
}


Notwithstanding that I think shifting a negative value right is
unspecified behaviour, I don't think this generates the same result
when x[i] is INT_MIN either, although negating that is also
unspecified since it can't be represented in an int.



You're right that they are implementation defined, but I think most
ISAs do have a sane Implementation of these two cases. At least both
x86 and AArch64 just replicate the signbit and for negate do two

complement negation. So INT_MIN works as expected and results in 0.

Which is not what the original code produces if you have wrapping ints,
because -INT_MIN is INT_MIN, and thus still negative.



True, but then you have a signed overflow which is undefined behaviour and not 
implementation defined

" If an exceptional condition occurs during the evaluation of an expression (that 
is, if the result is not mathematically defined or not in the range of representable 
values for its type), the behavior is undefined."

So it should still be acceptable to do in this case.


-fwrapv

R.




R.



But I'm happy to guard this behind some sort of target guard.

Regards,
Tamar


R.


now generates:

.L3:
   ldr q0, [x0]
   cmgtv0.4s, v0.4s, #0
   str q0, [x0], 16
   cmp x0, x1
   bne .L3

instead of:

.L3:
   ldr q0, [x0]
   neg v0.4s, v0.4s
   sshrv0.4s, v0.4s, 31
   str q0, [x0], 16
   cmp x0, x1
   bne .L3

Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* match.pd: New negate+shift pattern.

gcc/testsuite/ChangeLog:

* gcc.dg/signbit-2.c: New test.
* gcc.dg/signbit-3.c: New test.
* gcc.target/aarch64/signbit-1.c: New test.

--- inline copy of patch --
diff --git a/gcc/match.pd b/gcc/match.pd index



7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7

190c96d14398143 100644

--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
{ tree utype = unsigned_type_for (type); }
(convert (rshift (lshift (convert:utype @0) @2) @3))

+/* Fold (-x >> C) into x > 0 where C = precision(type) - 1.  */
+(for cst (INTEGER_CST VECTOR_CST)  (simplify
+  (rshift (negate:s @0) cst@1)
+   (with { tree ctype = TREE_TYPE (@0);
+  tree stype = TREE_TYPE (@1);
+  tree bt = truth_type_for (ctype); }
+(switch
+ /* Handle scalar case.  */
+ (if (INTEGRAL_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (ctype)
+ && !TYPE_UNSIGNED (ctype)
+ && canonicalize_math_after_vectorization_p ()
+ && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (stype); })))
+ /* Handle vector case with a scalar immediate.  */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+  && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (ctype); })))
+ /* Handle vector case with a vector immediate.   */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+ && uniform_vector_p (@1))
+  (with { tree cst = vector_cst_elt (@1, 0);
+ tree t = TREE_TYPE (cst); }
+   (if (wi::eq_p (wi::to_wide (cst), TYPE_PRECISION (t) - 1))
+(convert:bt (gt:bt @0 { build_zero_cst (ctype); })
+
/* Fold (C1/X)*C2 into (C1*C2)/X.  */
(simplify
 (mult (rdiv@3 REAL_CST@0 @1) REAL_CST@2) diff --git
a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-

2.c

new file mode 100644
index



..fc0157cbc5c7996b481f2998bc

30176c96a669bb

--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -0,0 +1,19 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 --save-temps -fdump-tree-optimized" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  

RE: [PATCH]middle-end convert negate + right shift into compare greater.

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Richard Earnshaw 
> Sent: Tuesday, October 5, 2021 2:34 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: Re: [PATCH]middle-end convert negate + right shift into compare
> greater.
> 
> 
> 
> On 05/10/2021 14:30, Tamar Christina wrote:
> >
> >
> >> -Original Message-
> >> From: Richard Earnshaw 
> >> Sent: Tuesday, October 5, 2021 1:56 PM
> >> To: Tamar Christina ;
> >> gcc-patches@gcc.gnu.org
> >> Cc: nd ; rguent...@suse.de
> >> Subject: Re: [PATCH]middle-end convert negate + right shift into
> >> compare greater.
> >>
> >>
> >>
> >> On 05/10/2021 13:50, Tamar Christina via Gcc-patches wrote:
> >>> Hi All,
> >>>
> >>> This turns an inversion of the sign bit + arithmetic right shift
> >>> into a comparison with 0.
> >>>
> >>> i.e.
> >>>
> >>> void fun1(int32_t *x, int n)
> >>> {
> >>>   for (int i = 0; i < (n & -16); i++)
> >>> x[i] = (-x[i]) >> 31;
> >>> }
> >>>
> >> Notwithstanding that I think shifting a negative value right is
> >> unspecified behaviour, I don't think this generates the same result
> >> when x[i] is INT_MIN either, although negating that is also
> >> unspecified since it can't be represented in an int.
> >>
> >
> > You're right that they are implementation defined, but I think most
> > ISAs do have a sane Implementation of these two cases. At least both
> > x86 and AArch64 just replicate the signbit and for negate do two
> complement negation. So INT_MIN works as expected and results in 0.
> 
> Which is not what the original code produces if you have wrapping ints,
> because -INT_MIN is INT_MIN, and thus still negative.
> 

True, but then you have a signed overflow which is undefined behaviour and not 
implementation defined

" If an exceptional condition occurs during the evaluation of an expression 
(that is, if the result is not mathematically defined or not in the range of 
representable values for its type), the behavior is undefined."

So it should still be acceptable to do in this case.

> R.
> 
> >
> > But I'm happy to guard this behind some sort of target guard.
> >
> > Regards,
> > Tamar
> >
> >> R.
> >>
> >>> now generates:
> >>>
> >>> .L3:
> >>>   ldr q0, [x0]
> >>>   cmgtv0.4s, v0.4s, #0
> >>>   str q0, [x0], 16
> >>>   cmp x0, x1
> >>>   bne .L3
> >>>
> >>> instead of:
> >>>
> >>> .L3:
> >>>   ldr q0, [x0]
> >>>   neg v0.4s, v0.4s
> >>>   sshrv0.4s, v0.4s, 31
> >>>   str q0, [x0], 16
> >>>   cmp x0, x1
> >>>   bne .L3
> >>>
> >>> Bootstrapped Regtested on aarch64-none-linux-gnu,
> >>> x86_64-pc-linux-gnu and no regressions.
> >>>
> >>> Ok for master?
> >>>
> >>> Thanks,
> >>> Tamar
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>>   * match.pd: New negate+shift pattern.
> >>>
> >>> gcc/testsuite/ChangeLog:
> >>>
> >>>   * gcc.dg/signbit-2.c: New test.
> >>>   * gcc.dg/signbit-3.c: New test.
> >>>   * gcc.target/aarch64/signbit-1.c: New test.
> >>>
> >>> --- inline copy of patch --
> >>> diff --git a/gcc/match.pd b/gcc/match.pd index
> >>
> 7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7
> >> 190c96d14398143 100644
> >>> --- a/gcc/match.pd
> >>> +++ b/gcc/match.pd
> >>> @@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >>>{ tree utype = unsigned_type_for (type); }
> >>>(convert (rshift (lshift (convert:utype @0) @2) @3))
> >>>
> >>> +/* Fold (-x >> C) into x > 0 where C = precision(type) - 1.  */
> >>> +(for cst (INTEGER_CST VECTOR_CST)  (simplify
> >>> +  (rshift (negate:s @0) cst@1)
> >>> +   (with { tree ctype = TREE_TYPE (@0);
> >>> +tree stype = TREE_TYPE (@1);
> >>> +tree bt = truth_type_for (ctype); }
> >>> +(switch
> >>> + /* Handle scalar case.  */
> >>> + (if (INTEGRAL_TYPE_P (ctype)
> >>> +   && !VECTOR_TYPE_P (ctype)
> >>> +   && !TYPE_UNSIGNED (ctype)
> >>> +   && canonicalize_math_after_vectorization_p ()
> >>> +   && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
> >>> +  (convert:bt (gt:bt @0 { build_zero_cst (stype); })))
> >>> + /* Handle vector case with a scalar immediate.  */
> >>> + (if (VECTOR_INTEGER_TYPE_P (ctype)
> >>> +   && !VECTOR_TYPE_P (stype)
> >>> +   && !TYPE_UNSIGNED (ctype)
> >>> +  && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
> >>> +  (convert:bt (gt:bt @0 { build_zero_cst (ctype); })))
> >>> + /* Handle vector case with a vector immediate.   */
> >>> + (if (VECTOR_INTEGER_TYPE_P (ctype)
> >>> +   && VECTOR_TYPE_P (stype)
> >>> +   && !TYPE_UNSIGNED (ctype)
> >>> +   && uniform_vector_p (@1))
> >>> +  (with { tree cst = vector_cst_elt (@1, 0);
> >>> +   tree t = TREE_TYPE (cst); }
> >>> +   (if (wi::eq_p (wi::to_wide (cst), TYPE_PRECISION (t) - 1))
> >>> +(convert:bt (gt:bt @0 { build_zero_cst (ctype); })
> >>> +
> >>>/* Fold (C1/X)*C2 into (C1*C2)/X.  */
> >>>

[PATCH] loop: Fix profile updates after unrolling [PR102385]

[Richard Sandiford via Gcc-patches]

In g:62acc72a957b5614 I'd stopped the unroller from using
an epilogue loop in cases where the iteration count was
known to be a multiple of the unroll factor.  The epilogue
and non-epilogue cases still shared this (preexisting) code
to update the edge frequencies:

  basic_block exit_bb = single_pred (loop->latch);
  new_exit = find_edge (exit_bb, rest);
  new_exit->probability = profile_probability::always ()
   .apply_scale (1, new_est_niter + 1);
  [etc]

But of course (in hindsight) that only makes sense for the
epilogue case, where we've already moved the main loop's exit edge
to be a sibling of the latch edge.  For the non-epilogue case,
the exit edge stays (and needs to stay) in its original position.

I don't really understand what the code is trying to do for
the epilogue case.  It has:

  /* Ensure that the frequencies in the loop match the new estimated
 number of iterations, and change the probability of the new
 exit edge.  */

  profile_count freq_h = loop->header->count;
  profile_count freq_e = (loop_preheader_edge (loop))->count ();
  if (freq_h.nonzero_p ())
{
  ...
  scale_loop_frequencies (loop, freq_e.probability_in (freq_h));
}

Here, freq_e.probability_in (freq_h) is freq_e / freq_h, so for the
header block, this has the effect of:

  new header count = freq_h * (freq_e / freq_h)

i.e. we say that the header executes exactly as often as the
preheader edge, which would only make sense if the loop never
iterates.  Also, after setting the probability of the nonexit edge
(correctly) to new_est_niter / (new_est_niter + 1), the code does:

scale_bbs_frequencies (>latch, 1, prob);

for this new probability.  I think that only makes sense if the
nonexit edge was previously unconditional (100%).  But the code
carefully preserved the probability of the original exit edge
when creating the new one.

All I'm trying to do here though is fix the mess I created
and get the probabilities right for the non-epilogue case.
Things are simpler there since we don't have to worry about
loop versioning.  Hopefully the comments explain the approach.

The function's current interface implies that it can cope with
multiple exit edges and that the function only needs the iteration
count relative to one of those edges in order to work correctly.
In practice that's not the case: it assumes there is exactly one
exit edge and all current callers also ensure that the exit test
dominates the latch.  I think the function is easier to follow
if we remove the implied generality.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


gcc/
PR tree-optimization/102385
* predict.h (change_edge_frequency): Declare.
* predict.c (change_edge_frequency): New function.
* tree-ssa-loop-manip.h (tree_transform_and_unroll_loop): Remove
edge argument.
(tree_unroll_loop): Likewise.
* gimple-loop-jam.c (tree_loop_unroll_and_jam): Update accordingly.
* tree-predcom.c (pcom_worker::tree_predictive_commoning_loop):
Likewise.
* tree-ssa-loop-manip.c (tree_unroll_loop): Likewise.
(tree_transform_and_unroll_loop): Likewise.  Use single_dom_exit
to retrieve the exit edges.  Make all the old profile update code
conditional on !single_loop_p -- the case it was written for --
and use a different approach for the single-loop case.

gcc/testsuite/
* testsuite/gcc.dg/pr102385.c: New test.
---
 gcc/gimple-loop-jam.c   |   3 +-
 gcc/predict.c   |  37 +++
 gcc/predict.h   |   1 +
 gcc/testsuite/gcc.dg/pr102385.c |  14 
 gcc/tree-predcom.c  |   3 +-
 gcc/tree-ssa-loop-manip.c   | 111 
 gcc/tree-ssa-loop-manip.h   |   5 +-
 gcc/tree-ssa-loop-prefetch.c|   3 +-
 8 files changed, 140 insertions(+), 37 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr102385.c

diff --git a/gcc/predict.h b/gcc/predict.h
index 8860cafa31c..4df51bd615c 100644
--- a/gcc/predict.h
+++ b/gcc/predict.h
@@ -100,6 +100,7 @@ extern void rebuild_frequencies (void);
 extern void report_predictor_hitrates (void);
 extern void force_edge_cold (edge, bool);
 extern void propagate_unlikely_bbs_forward (void);
+extern void change_edge_frequency (edge, profile_probability);
 
 extern void add_reg_br_prob_note (rtx_insn *, profile_probability);
 
diff --git a/gcc/predict.c b/gcc/predict.c
index d9c7249831e..68b11135680 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -4481,6 +4481,43 @@ force_edge_cold (edge e, bool impossible)
 }
 }
 
+/* Change E's probability to NEW_E_PROB, redistributing the probabilities
+   of other outgoing edges proportionally.
+
+   Note that this function does not change the profile counts of any
+   basic blocks.  The caller must do that instead, using whatever
+   information it has about the region that 

Re: [PATCH]middle-end convert negate + right shift into compare greater.

[Richard Earnshaw via Gcc-patches]

On 05/10/2021 14:30, Tamar Christina wrote:




-Original Message-
From: Richard Earnshaw 
Sent: Tuesday, October 5, 2021 1:56 PM
To: Tamar Christina ; gcc-patches@gcc.gnu.org
Cc: nd ; rguent...@suse.de
Subject: Re: [PATCH]middle-end convert negate + right shift into compare
greater.



On 05/10/2021 13:50, Tamar Christina via Gcc-patches wrote:

Hi All,

This turns an inversion of the sign bit + arithmetic right shift into
a comparison with 0.

i.e.

void fun1(int32_t *x, int n)
{
  for (int i = 0; i < (n & -16); i++)
x[i] = (-x[i]) >> 31;
}


Notwithstanding that I think shifting a negative value right is unspecified
behaviour, I don't think this generates the same result when x[i] is INT_MIN
either, although negating that is also unspecified since it can't be
represented in an int.



You're right that they are implementation defined, but I think most ISAs do 
have a sane
Implementation of these two cases. At least both x86 and AArch64 just replicate 
the signbit
and for negate do two complement negation. So INT_MIN works as expected and 
results in 0.


Which is not what the original code produces if you have wrapping ints, 
because -INT_MIN is INT_MIN, and thus still negative.


R.



But I'm happy to guard this behind some sort of target guard.

Regards,
Tamar


R.


now generates:

.L3:
  ldr q0, [x0]
  cmgtv0.4s, v0.4s, #0
  str q0, [x0], 16
  cmp x0, x1
  bne .L3

instead of:

.L3:
  ldr q0, [x0]
  neg v0.4s, v0.4s
  sshrv0.4s, v0.4s, 31
  str q0, [x0], 16
  cmp x0, x1
  bne .L3

Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* match.pd: New negate+shift pattern.

gcc/testsuite/ChangeLog:

* gcc.dg/signbit-2.c: New test.
* gcc.dg/signbit-3.c: New test.
* gcc.target/aarch64/signbit-1.c: New test.

--- inline copy of patch --
diff --git a/gcc/match.pd b/gcc/match.pd
index

7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7
190c96d14398143 100644

--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   { tree utype = unsigned_type_for (type); }
   (convert (rshift (lshift (convert:utype @0) @2) @3))

+/* Fold (-x >> C) into x > 0 where C = precision(type) - 1.  */
+(for cst (INTEGER_CST VECTOR_CST)
+ (simplify
+  (rshift (negate:s @0) cst@1)
+   (with { tree ctype = TREE_TYPE (@0);
+  tree stype = TREE_TYPE (@1);
+  tree bt = truth_type_for (ctype); }
+(switch
+ /* Handle scalar case.  */
+ (if (INTEGRAL_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (ctype)
+ && !TYPE_UNSIGNED (ctype)
+ && canonicalize_math_after_vectorization_p ()
+ && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (stype); })))
+ /* Handle vector case with a scalar immediate.  */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+  && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (ctype); })))
+ /* Handle vector case with a vector immediate.   */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+ && uniform_vector_p (@1))
+  (with { tree cst = vector_cst_elt (@1, 0);
+ tree t = TREE_TYPE (cst); }
+   (if (wi::eq_p (wi::to_wide (cst), TYPE_PRECISION (t) - 1))
+(convert:bt (gt:bt @0 { build_zero_cst (ctype); })
+
   /* Fold (C1/X)*C2 into (C1*C2)/X.  */
   (simplify
(mult (rdiv@3 REAL_CST@0 @1) REAL_CST@2)
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-

2.c

new file mode 100644
index

..fc0157cbc5c7996b481f2998bc
30176c96a669bb

--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -0,0 +1,19 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 --save-temps -fdump-tree-optimized" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 31;
+}
+
+void fun2(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 30;
+}
+
+/* { dg-final { scan-tree-dump-times {\s+>\s+\{ 0, 0, 0, 0 \}} 1 optimized } }

*/

+/* { dg-final { scan-tree-dump-not {\s+>>\s+31} optimized } } */
diff --git a/gcc/testsuite/gcc.dg/signbit-3.c b/gcc/testsuite/gcc.dg/signbit-

3.c

new file mode 100644
index

..19e9c06c349b3287610f817628
f00938ece60bf7

--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-3.c
@@ -0,0 +1,13 @@
+/* { dg-do assemble } */
+/* { dg-options "-O1 --save-temps -fdump-tree-optimized" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 

Re: [RFC] More jump threading restrictions in the presence of loops.

[Aldy Hernandez via Gcc-patches]

On Mon, Oct 4, 2021 at 6:29 PM Michael Matz  wrote:
>
> Hello,
>
> On Mon, 4 Oct 2021, Jeff Law wrote:
>
> > And just in case it got lost.  Here's the analysis on 960218-1 on visium:
> >
> > We've got this going into ethread:
> >
> > int f (int x)
> > {
> >   int D.1420;
> >   int a;
> >
> > ;;   basic block 2, loop depth 0, maybe hot
> > ;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
> >   a_4 = ~x_3(D);
> >   goto ; [INV]
> > ;;succ:   4 (FALLTHRU,EXECUTABLE)
> >
> > ;;   basic block 3, loop depth 1, maybe hot
> > ;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   4 (TRUE_VALUE,EXECUTABLE)
> >   gl = a_1;
> > ;;succ:   4 (FALLTHRU,DFS_BACK,EXECUTABLE)
> >
> > ;;   basic block 4, loop depth 1, maybe hot
> > ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   2 (FALLTHRU,EXECUTABLE)
> > ;;3 (FALLTHRU,DFS_BACK,EXECUTABLE)
> >   # a_1 = PHI 
> >   if (a_1 != 0)
> > goto ; [INV]
> >   else
> > goto ; [INV]
> > ;;succ:   3 (TRUE_VALUE,EXECUTABLE)
> > ;;5 (FALSE_VALUE,EXECUTABLE)
> >
> > ;;   basic block 5, loop depth 0, maybe hot
> > ;;prev block 4, next block 1, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   4 (FALSE_VALUE,EXECUTABLE)
> >   return;
> > ;;succ:   EXIT
> >
> > }
>
> First notice that this doesn't have an empty latch block to start with
> (in fact, there is no separate latch block at all), so the loop optimizers
> haven't been initialized for simple latches at this point.  Still, I would
> say that even then we want to be careful with the latch edge, as putting
> code onto it will most probably create a problem downstream once we _do_
> want to intialize the loop optimizers for simple latches.  So, that we are
> careful here is okay, we are just too careful in this specific case.
>
> > There's a pretty obvious jump thread in there.  3->4->5.
> >
> > We used to allow this, but it's currently being rejected and I'm not
> > sure it should.
> >
> > In simplest terms we're threading from inside the loop, through the
> > latch to a point outside the loop.  At first glance, that seems safe.
>
> Is at least the unrestricted jump threader (the one after loop optimizers)
> picking this up?
>
> Independend of that, I agree, that this specific instance of threading
> through the latch block, even though followed by to-be-copied
> instructions, is okay.  We need to determine precisely when that is okay,
> though.  In this case there are several reasons I could see why this is
> so:
> (a) while the thread is through the latch block, it's _not_ through the
> latch edge (which is 4->3).  That would create the problem, so here
> we're fine.

It seems we all agree Jeff's finding should be allowed, so let's
attack this one first, since it gets almost all of his visium
failures.  I can submit the rest of the cases separately.

The attached patch catches the IL discussed, and adds a relevant
gimple FE test others can use for experimenting :).

Tested on x86-64 and by visual inspection on visium-elf on the
regressions Jeff pointed me at.

OK?

BTW Jeff, this fixes all the regressions you mention except:

1. pr68911.c

The path not being threaded here is 7->10->11->12.  It crosses loops
multiple times, so I believe the restriction code is correct.

7, 10, 12 are in loop1.
11 is in loop 2.

So we have a path going from loop1 -> loop2 -> loop1.  I can't
conceive any scenario where this is ok, but I can attach the entire IL
if I'm missing something.

2. 961125-1.c

This one is a bit trickier.  Here we're trying to thread the following
conditional, which I mentioned when I contributed this work, we don't
handle (and happens infrequently enough not to matter):

+  // Loop 4
+   [local count: 114863531]:
+  # ptr_8 = PHI 
+  if (ptr_8 <   [(void *)":ab" + 3B])
+goto ; [50.00%]
+  else
+goto ; [50.00%]

The hybrid threader doesn't handle  in the final conditional.  As
I mentioned earlier, if this becomes an issue, we can adapt class
pointer_equiv_analyzer like we did for evrp.  I have a gimple FE test
I will contribute as an XFAIL with an associated PR to keep us honest.

That being said... in this particular test, this is all irrelevant
because the path will be disallowed for two reasons:

a) The path crosses loops, and the reason we didn't realize it in the
old code was because the ASSERT_EXPR had pulled the SSA outside the
loop, so it looks like the entire path is l in the same loop.  If you
look at the original IL, it's not.

b) Now the path actually fits the pattern being discussed in this
patch, where there's an early exit out of a loop, so it looks like we
should handle it.  But...in this case, we would fill a presently empty
latch.  Interestingly, the old code didn't catch it, becauseyou
guessed it...there was an ASSERT_EXPR in the latch.

So I argue that even in the 

RE: [PATCH]middle-end convert negate + right shift into compare greater.

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Richard Earnshaw 
> Sent: Tuesday, October 5, 2021 1:56 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: Re: [PATCH]middle-end convert negate + right shift into compare
> greater.
> 
> 
> 
> On 05/10/2021 13:50, Tamar Christina via Gcc-patches wrote:
> > Hi All,
> >
> > This turns an inversion of the sign bit + arithmetic right shift into
> > a comparison with 0.
> >
> > i.e.
> >
> > void fun1(int32_t *x, int n)
> > {
> >  for (int i = 0; i < (n & -16); i++)
> >x[i] = (-x[i]) >> 31;
> > }
> >
> Notwithstanding that I think shifting a negative value right is unspecified
> behaviour, I don't think this generates the same result when x[i] is INT_MIN
> either, although negating that is also unspecified since it can't be
> represented in an int.
> 

You're right that they are implementation defined, but I think most ISAs do 
have a sane
Implementation of these two cases. At least both x86 and AArch64 just replicate 
the signbit
and for negate do two complement negation. So INT_MIN works as expected and 
results in 0.

But I'm happy to guard this behind some sort of target guard.

Regards,
Tamar

> R.
> 
> > now generates:
> >
> > .L3:
> >  ldr q0, [x0]
> >  cmgtv0.4s, v0.4s, #0
> >  str q0, [x0], 16
> >  cmp x0, x1
> >  bne .L3
> >
> > instead of:
> >
> > .L3:
> >  ldr q0, [x0]
> >  neg v0.4s, v0.4s
> >  sshrv0.4s, v0.4s, 31
> >  str q0, [x0], 16
> >  cmp x0, x1
> >  bne .L3
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu,
> > x86_64-pc-linux-gnu and no regressions.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > * match.pd: New negate+shift pattern.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/signbit-2.c: New test.
> > * gcc.dg/signbit-3.c: New test.
> > * gcc.target/aarch64/signbit-1.c: New test.
> >
> > --- inline copy of patch --
> > diff --git a/gcc/match.pd b/gcc/match.pd
> > index
> 7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7
> 190c96d14398143 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >   { tree utype = unsigned_type_for (type); }
> >   (convert (rshift (lshift (convert:utype @0) @2) @3))
> >
> > +/* Fold (-x >> C) into x > 0 where C = precision(type) - 1.  */
> > +(for cst (INTEGER_CST VECTOR_CST)
> > + (simplify
> > +  (rshift (negate:s @0) cst@1)
> > +   (with { tree ctype = TREE_TYPE (@0);
> > +  tree stype = TREE_TYPE (@1);
> > +  tree bt = truth_type_for (ctype); }
> > +(switch
> > + /* Handle scalar case.  */
> > + (if (INTEGRAL_TYPE_P (ctype)
> > + && !VECTOR_TYPE_P (ctype)
> > + && !TYPE_UNSIGNED (ctype)
> > + && canonicalize_math_after_vectorization_p ()
> > + && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
> > +  (convert:bt (gt:bt @0 { build_zero_cst (stype); })))
> > + /* Handle vector case with a scalar immediate.  */
> > + (if (VECTOR_INTEGER_TYPE_P (ctype)
> > + && !VECTOR_TYPE_P (stype)
> > + && !TYPE_UNSIGNED (ctype)
> > +  && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
> > +  (convert:bt (gt:bt @0 { build_zero_cst (ctype); })))
> > + /* Handle vector case with a vector immediate.   */
> > + (if (VECTOR_INTEGER_TYPE_P (ctype)
> > + && VECTOR_TYPE_P (stype)
> > + && !TYPE_UNSIGNED (ctype)
> > + && uniform_vector_p (@1))
> > +  (with { tree cst = vector_cst_elt (@1, 0);
> > + tree t = TREE_TYPE (cst); }
> > +   (if (wi::eq_p (wi::to_wide (cst), TYPE_PRECISION (t) - 1))
> > +(convert:bt (gt:bt @0 { build_zero_cst (ctype); })
> > +
> >   /* Fold (C1/X)*C2 into (C1*C2)/X.  */
> >   (simplify
> >(mult (rdiv@3 REAL_CST@0 @1) REAL_CST@2)
> > diff --git a/gcc/testsuite/gcc.dg/signbit-2.c 
> > b/gcc/testsuite/gcc.dg/signbit-
> 2.c
> > new file mode 100644
> > index
> ..fc0157cbc5c7996b481f2998bc
> 30176c96a669bb
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/signbit-2.c
> > @@ -0,0 +1,19 @@
> > +/* { dg-do assemble } */
> > +/* { dg-options "-O3 --save-temps -fdump-tree-optimized" } */
> > +
> > +#include 
> > +
> > +void fun1(int32_t *x, int n)
> > +{
> > +for (int i = 0; i < (n & -16); i++)
> > +  x[i] = (-x[i]) >> 31;
> > +}
> > +
> > +void fun2(int32_t *x, int n)
> > +{
> > +for (int i = 0; i < (n & -16); i++)
> > +  x[i] = (-x[i]) >> 30;
> > +}
> > +
> > +/* { dg-final { scan-tree-dump-times {\s+>\s+\{ 0, 0, 0, 0 \}} 1 optimized 
> > } }
> */
> > +/* { dg-final { scan-tree-dump-not {\s+>>\s+31} optimized } } */
> > diff --git a/gcc/testsuite/gcc.dg/signbit-3.c 
> > b/gcc/testsuite/gcc.dg/signbit-
> 3.c
> > new file mode 100644
> > index
> 

Re: [PATCH]middle-end convert negate + right shift into compare greater.

[Richard Earnshaw via Gcc-patches]

On 05/10/2021 13:50, Tamar Christina via Gcc-patches wrote:

Hi All,

This turns an inversion of the sign bit + arithmetic right shift into a
comparison with 0.

i.e.

void fun1(int32_t *x, int n)
{
 for (int i = 0; i < (n & -16); i++)
   x[i] = (-x[i]) >> 31;
}

Notwithstanding that I think shifting a negative value right is 
unspecified behaviour, I don't think this generates the same result when 
x[i] is INT_MIN either, although negating that is also unspecified since 
it can't be represented in an int.


R.


now generates:

.L3:
 ldr q0, [x0]
 cmgtv0.4s, v0.4s, #0
 str q0, [x0], 16
 cmp x0, x1
 bne .L3

instead of:

.L3:
 ldr q0, [x0]
 neg v0.4s, v0.4s
 sshrv0.4s, v0.4s, 31
 str q0, [x0], 16
 cmp x0, x1
 bne .L3

Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* match.pd: New negate+shift pattern.

gcc/testsuite/ChangeLog:

* gcc.dg/signbit-2.c: New test.
* gcc.dg/signbit-3.c: New test.
* gcc.target/aarch64/signbit-1.c: New test.

--- inline copy of patch --
diff --git a/gcc/match.pd b/gcc/match.pd
index 
7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7190c96d14398143
 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  { tree utype = unsigned_type_for (type); }
  (convert (rshift (lshift (convert:utype @0) @2) @3))
  
+/* Fold (-x >> C) into x > 0 where C = precision(type) - 1.  */

+(for cst (INTEGER_CST VECTOR_CST)
+ (simplify
+  (rshift (negate:s @0) cst@1)
+   (with { tree ctype = TREE_TYPE (@0);
+  tree stype = TREE_TYPE (@1);
+  tree bt = truth_type_for (ctype); }
+(switch
+ /* Handle scalar case.  */
+ (if (INTEGRAL_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (ctype)
+ && !TYPE_UNSIGNED (ctype)
+ && canonicalize_math_after_vectorization_p ()
+ && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (stype); })))
+ /* Handle vector case with a scalar immediate.  */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+  && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (ctype); })))
+ /* Handle vector case with a vector immediate.   */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+ && uniform_vector_p (@1))
+  (with { tree cst = vector_cst_elt (@1, 0);
+ tree t = TREE_TYPE (cst); }
+   (if (wi::eq_p (wi::to_wide (cst), TYPE_PRECISION (t) - 1))
+(convert:bt (gt:bt @0 { build_zero_cst (ctype); })
+
  /* Fold (C1/X)*C2 into (C1*C2)/X.  */
  (simplify
   (mult (rdiv@3 REAL_CST@0 @1) REAL_CST@2)
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
new file mode 100644
index 
..fc0157cbc5c7996b481f2998bc30176c96a669bb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -0,0 +1,19 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 --save-temps -fdump-tree-optimized" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 31;
+}
+
+void fun2(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 30;
+}
+
+/* { dg-final { scan-tree-dump-times {\s+>\s+\{ 0, 0, 0, 0 \}} 1 optimized } } 
*/
+/* { dg-final { scan-tree-dump-not {\s+>>\s+31} optimized } } */
diff --git a/gcc/testsuite/gcc.dg/signbit-3.c b/gcc/testsuite/gcc.dg/signbit-3.c
new file mode 100644
index 
..19e9c06c349b3287610f817628f00938ece60bf7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-3.c
@@ -0,0 +1,13 @@
+/* { dg-do assemble } */
+/* { dg-options "-O1 --save-temps -fdump-tree-optimized" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 31;
+}
+
+/* { dg-final { scan-tree-dump-times {\s+>\s+0;} 1 optimized } } */
+/* { dg-final { scan-tree-dump-not {\s+>>\s+31} optimized } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/signbit-1.c 
b/gcc/testsuite/gcc.target/aarch64/signbit-1.c
new file mode 100644
index 
..3ebfb0586f37de29cf58635b27fe48503714447e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/signbit-1.c
@@ -0,0 +1,18 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 --save-temps" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 31;
+}
+
+void fun2(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 30;
+}
+
+/* { dg-final { 

RE: [PATCH 5/7]middle-end Convert bitclear + cmp #0 into cm

[Tamar Christina via Gcc-patches]

Hi All,

Here's a new version of the patch handling both scalar and vector modes
and non-uniform constant vectors.

Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.

In order to not break IVopts and CSE I have added a
requirement for the scalar version to be single use.

Thanks,
Tamar

gcc/ChangeLog:

* tree.c (bitmask_inv_cst_vector_p): New.
* tree.h (bitmask_inv_cst_vector_p): New.
* match.pd: Use it in new bitmask compare pattern.

gcc/testsuite/ChangeLog:

* gcc.dg/bic-bitmask-10.c: New test.
* gcc.dg/bic-bitmask-11.c: New test.
* gcc.dg/bic-bitmask-12.c: New test.
* gcc.dg/bic-bitmask-13.c: New test.
* gcc.dg/bic-bitmask-14.c: New test.
* gcc.dg/bic-bitmask-15.c: New test.
* gcc.dg/bic-bitmask-16.c: New test.
* gcc.dg/bic-bitmask-17.c: New test.
* gcc.dg/bic-bitmask-18.c: New test.
* gcc.dg/bic-bitmask-19.c: New test.
* gcc.dg/bic-bitmask-2.c: New test.
* gcc.dg/bic-bitmask-20.c: New test.
* gcc.dg/bic-bitmask-21.c: New test.
* gcc.dg/bic-bitmask-22.c: New test.
* gcc.dg/bic-bitmask-23.c: New test.
* gcc.dg/bic-bitmask-3.c: New test.
* gcc.dg/bic-bitmask-4.c: New test.
* gcc.dg/bic-bitmask-5.c: New test.
* gcc.dg/bic-bitmask-6.c: New test.
* gcc.dg/bic-bitmask-7.c: New test.
* gcc.dg/bic-bitmask-8.c: New test.
* gcc.dg/bic-bitmask-9.c: New test.
* gcc.dg/bic-bitmask.h: New test.
* gcc.target/aarch64/bic-bitmask-1.c: New test.

--- inline copy of patch --

diff --git a/gcc/match.pd b/gcc/match.pd
index 
0fcfd0ea62c043dc217d0d560ce5b7e569b70e7d..7d2a24dbc5e9644a09968f877e12a824d8ba1caa
 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -37,7 +37,8 @@ along with GCC; see the file COPYING3.  If not see
integer_pow2p
uniform_integer_cst_p
HONOR_NANS
-   uniform_vector_p)
+   uniform_vector_p
+   bitmask_inv_cst_vector_p)
 
 /* Operator lists.  */
 (define_operator_list tcc_comparison
@@ -4900,6 +4901,24 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (eqcmp (bit_and @1 { wide_int_to_tree (ty, mask - rhs); })
 { build_zero_cst (ty); }))
 
+/* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z
+   where ~Y + 1 == pow2 and Z = ~Y.  */
+(for cst (VECTOR_CST INTEGER_CST)
+ (for cmp (le eq ne ge gt)
+  icmp (le le gt le gt)
+ (simplify
+  (cmp (bit_and:c@2 @0 cst@1) integer_zerop)
+   (with { tree csts = bitmask_inv_cst_vector_p (@1); }
+ (switch
+  (if (csts && TYPE_UNSIGNED (TREE_TYPE (@1))
+  && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)))
+   (icmp @0 { csts; }))
+  (if (csts && !TYPE_UNSIGNED (TREE_TYPE (@1))
+  && (cmp == EQ_EXPR || cmp == NE_EXPR)
+  && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)))
+   (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); }
+   (icmp (convert:utype @0) { csts; }
+
 /* -A CMP -B -> B CMP A.  */
 (for cmp (tcc_comparison)
  scmp (swapped_tcc_comparison)
diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-10.c 
b/gcc/testsuite/gcc.dg/bic-bitmask-10.c
new file mode 100644
index 
..76a22a2313137a2a75dd711c2c15c2d3a34e15aa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/bic-bitmask-10.c
@@ -0,0 +1,26 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -save-temps -fdump-tree-dce" } */
+
+#include 
+
+__attribute__((noinline, noipa))
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (x[i]&(~255)) == 0;
+}
+
+__attribute__((noinline, noipa, optimize("O1")))
+void fun2(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (x[i]&(~255)) == 0;
+}
+
+#define TYPE int32_t
+#include "bic-bitmask.h"
+
+/* { dg-final { scan-tree-dump {<=\s*.+\{ 255,.+\}} dce7 } } */
+/* { dg-final { scan-tree-dump-not {&\s*.+\{ 4294967290,.+\}} dce7 } } */
+/* { dg-final { scan-tree-dump-not {\s+bic\s+} dce7 { target { aarch64*-*-* } 
} } } */
+
diff --git a/gcc/testsuite/gcc.dg/bic-bitmask-11.c 
b/gcc/testsuite/gcc.dg/bic-bitmask-11.c
new file mode 100644
index 
..32553d7ba2f823f7a21237451990d0a216d2f912
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/bic-bitmask-11.c
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -save-temps -fdump-tree-dce" } */
+
+#include 
+
+__attribute__((noinline, noipa))
+void fun1(uint32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (x[i]&(~255)) != 0;
+}
+
+__attribute__((noinline, noipa, optimize("O1")))
+void fun2(uint32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (x[i]&(~255)) != 0;
+}
+
+#include "bic-bitmask.h"
+
+/* { dg-final { scan-tree-dump {>\s*.+\{ 255,.+\}} dce7 } } */
+/* { dg-final { scan-tree-dump-not {&\s*.+\{ 4294967290,.+\}} dce7 } } */
+/* { dg-final { scan-tree-dump-not {\s+bic\s+} dce7 { target { aarch64*-*-* } 

[PATCH] Allow more kinds of invariant addresses in GIMPLE FE

[Richard Biener via Gcc-patches]

The gimple FE is too restrictive in what it accepts as
literals, the following makes it also accept [10] for example.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2021-10-05  Richard Biener  

PR c/102605
gcc/c/
* gimple-parser.c (c_parser_gimple_postfix_expression):
Accept more address _Literals.

gcc/testsuite/
* gcc.dg/gimplefe-46.c: New testcase.
---
 gcc/c/gimple-parser.c  | 14 +-
 gcc/testsuite/gcc.dg/gimplefe-46.c | 23 +++
 2 files changed, 32 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/gimplefe-46.c

diff --git a/gcc/c/gimple-parser.c b/gcc/c/gimple-parser.c
index c8d9db61f0a..c43ee38a2cf 100644
--- a/gcc/c/gimple-parser.c
+++ b/gcc/c/gimple-parser.c
@@ -1622,16 +1622,20 @@ c_parser_gimple_postfix_expression (gimple_parser 
)
  tree val = c_parser_gimple_postfix_expression (parser).value;
  if (! val
  || val == error_mark_node
- || (!CONSTANT_CLASS_P (val)
- && !(addr_p
-  && (TREE_CODE (val) == STRING_CST
-  || DECL_P (val)
+ || (!CONSTANT_CLASS_P (val) && !addr_p))
{
  c_parser_error (parser, "invalid _Literal");
  return expr;
}
  if (addr_p)
-   val = build1 (ADDR_EXPR, type, val);
+   {
+ val = build1 (ADDR_EXPR, type, val);
+ if (!is_gimple_invariant_address (val))
+   {
+ c_parser_error (parser, "invalid _Literal");
+ return expr;
+   }
+   }
  if (neg_p)
{
  val = const_unop (NEGATE_EXPR, TREE_TYPE (val), val);
diff --git a/gcc/testsuite/gcc.dg/gimplefe-46.c 
b/gcc/testsuite/gcc.dg/gimplefe-46.c
new file mode 100644
index 000..fb91f7d2a90
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-46.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple" } */
+
+char global[10];
+
+void bar (void);
+
+void __GIMPLE (ssa)
+foo (char * p)
+{
+  __BB(2):
+  if (p_2(D) == _Literal (char *)[2])
+goto __BB3;
+  else
+goto __BB4;
+
+  __BB(3):
+  bar ();
+  goto __BB4;
+
+  __BB(4):
+  return;
+}
-- 
2.31.1

[PATCH] More consistently dump GIMPLE FE consumable stmts

[Richard Biener via Gcc-patches]

The following makes more stmts consumable with the GIMPLE FE
when dumping with -gimple.  In particular addresses in GIMPLE
operand position require wrapping with _Literal.

The TDF_ flag space is now exhausted and I've removed overlaps
and re-ordered things as to how it is supposed to work.

Bootstrap & regtest pending on x86_64-unknown-linux-gnu.

2021-10-05  Richard Biener  

PR c/102605
* dumpfile.h (TDF_GIMPLE_VAL): New.  Re-order and adjust
TDF_* flags.
* tree-pretty-print.c (dump_generic_node): Wrap ADDR_EXPR
in _Literal if TDF_GIMPLE_VAL.
* gimple-pretty-print.c (dump_gimple_assign): Add
TDF_GIMPLE_VAL to flags when dumping operands where only
is_gimple_val are allowed.
(dump_gimple_cond): Likewise.
---
 gcc/dumpfile.h| 33 ++---
 gcc/gimple-pretty-print.c | 21 -
 gcc/tree-pretty-print.c   | 10 +-
 3 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/gcc/dumpfile.h b/gcc/dumpfile.h
index 6c7758dd2fb..b2a728e7395 100644
--- a/gcc/dumpfile.h
+++ b/gcc/dumpfile.h
@@ -140,23 +140,29 @@ enum dump_flag
   /* Dump SCEV details.  */
   TDF_SCEV = (1 << 19),
 
-  /* Dump in GIMPLE FE syntax  */
+  /* Dump in GIMPLE FE syntax.  */
   TDF_GIMPLE = (1 << 20),
 
   /* Dump folding details.  */
   TDF_FOLDING = (1 << 21),
 
+  /* Dumping for range path solver.  */
+  TDF_THREADING = (1 << 22),
+
+  /* All -fdump- flags.  */
+  TDF_ALL_VALUES = (1 << 23) - 1,
+
   /* MSG_* flags for expressing the kinds of message to
  be emitted by -fopt-info.  */
 
   /* -fopt-info optimized sources.  */
-  MSG_OPTIMIZED_LOCATIONS = (1 << 22),
+  MSG_OPTIMIZED_LOCATIONS = (1 << 23),
 
   /* Missed opportunities.  */
-  MSG_MISSED_OPTIMIZATION = (1 << 23),
+  MSG_MISSED_OPTIMIZATION = (1 << 24),
 
   /* General optimization info.  */
-  MSG_NOTE = (1 << 24),
+  MSG_NOTE = (1 << 25),
 
   /* Mask for selecting MSG_-kind flags.  */
   MSG_ALL_KINDS = (MSG_OPTIMIZED_LOCATIONS
@@ -175,16 +181,16 @@ enum dump_flag
  sub-option of -fopt-info to show the internal messages.  */
 
   /* Implicitly supplied for messages at the top-level dump scope.  */
-  MSG_PRIORITY_USER_FACING = (1 << 25),
+  MSG_PRIORITY_USER_FACING = (1 << 26),
 
   /* Implicitly supplied for messages within nested dump scopes.  */
-  MSG_PRIORITY_INTERNALS = (1 << 26),
+  MSG_PRIORITY_INTERNALS = (1 << 27),
 
   /* Supplied when an opt_problem generated in a nested scope is re-emitted
  at the top-level.   We want to default to showing these in -fopt-info
  output, but to *not* show them in dump files, as the message would be
  shown twice, messing up "scan-tree-dump-times" in DejaGnu tests.  */
-  MSG_PRIORITY_REEMITTED = (1 << 27),
+  MSG_PRIORITY_REEMITTED = (1 << 28),
 
   /* Mask for selecting MSG_PRIORITY_* flags.  */
   MSG_ALL_PRIORITIES = (MSG_PRIORITY_USER_FACING
@@ -192,16 +198,13 @@ enum dump_flag
| MSG_PRIORITY_REEMITTED),
 
   /* Dumping for -fcompare-debug.  */
-  TDF_COMPARE_DEBUG = (1 << 28),
+  TDF_COMPARE_DEBUG = (1 << 29),
 
-  /* For error.  */
-  TDF_ERROR = (1 << 26),
+  /* Dump a GIMPLE value which means wrapping certain things with _Literal.  */
+  TDF_GIMPLE_VAL = (1 << 30),
 
-  /* Dumping for range path solver.  */
-  TDF_THREADING = (1 << 27),
-
-  /* All values.  */
-  TDF_ALL_VALUES = (1 << 29) - 1
+  /* For error.  */
+  TDF_ERROR = (1 << 31),
 };
 
 /* Dump flags type.  */
diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index 0ca4a949612..72417a08104 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -677,11 +677,18 @@ dump_gimple_assign (pretty_printer *buffer, const gassign 
*gs, int spc,
}
 
   if (gimple_num_ops (gs) == 2)
-dump_unary_rhs (buffer, gs, spc, flags);
+   dump_unary_rhs (buffer, gs, spc,
+   ((flags & TDF_GIMPLE)
+&& gimple_assign_rhs_class (gs) == GIMPLE_SINGLE_RHS)
+   ? flags : (flags | TDF_GIMPLE_VAL));
   else if (gimple_num_ops (gs) == 3)
-dump_binary_rhs (buffer, gs, spc, flags);
+   dump_binary_rhs (buffer, gs, spc,
+(flags & TDF_GIMPLE)
+? (flags | TDF_GIMPLE_VAL) : flags);
   else if (gimple_num_ops (gs) == 4)
-dump_ternary_rhs (buffer, gs, spc, flags);
+   dump_ternary_rhs (buffer, gs, spc,
+ (flags & TDF_GIMPLE)
+ ? (flags | TDF_GIMPLE_VAL) : flags);
   else
 gcc_unreachable ();
   if (!(flags & TDF_RHS_ONLY))
@@ -1085,11 +1092,15 @@ dump_gimple_cond (pretty_printer *buffer, const gcond 
*gs, int spc,
 {
   if (!(flags & TDF_RHS_ONLY))
pp_string (buffer, "if (");
-  dump_generic_node (buffer, gimple_cond_lhs (gs), spc, flags, false);
+  dump_generic_node (buffer, gimple_cond_lhs (gs), spc,
+flags | 

[PATCH]middle-end convert negate + right shift into compare greater.

[Tamar Christina via Gcc-patches]

Hi All,

This turns an inversion of the sign bit + arithmetic right shift into a
comparison with 0.

i.e.

void fun1(int32_t *x, int n)
{
for (int i = 0; i < (n & -16); i++)
  x[i] = (-x[i]) >> 31;
}

now generates:

.L3:
ldr q0, [x0]
cmgtv0.4s, v0.4s, #0
str q0, [x0], 16
cmp x0, x1
bne .L3

instead of:

.L3:
ldr q0, [x0]
neg v0.4s, v0.4s
sshrv0.4s, v0.4s, 31
str q0, [x0], 16
cmp x0, x1
bne .L3

Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

* match.pd: New negate+shift pattern.

gcc/testsuite/ChangeLog:

* gcc.dg/signbit-2.c: New test.
* gcc.dg/signbit-3.c: New test.
* gcc.target/aarch64/signbit-1.c: New test.

--- inline copy of patch -- 
diff --git a/gcc/match.pd b/gcc/match.pd
index 
7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7190c96d14398143
 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 { tree utype = unsigned_type_for (type); }
 (convert (rshift (lshift (convert:utype @0) @2) @3))
 
+/* Fold (-x >> C) into x > 0 where C = precision(type) - 1.  */
+(for cst (INTEGER_CST VECTOR_CST)
+ (simplify
+  (rshift (negate:s @0) cst@1)
+   (with { tree ctype = TREE_TYPE (@0);
+  tree stype = TREE_TYPE (@1);
+  tree bt = truth_type_for (ctype); }
+(switch
+ /* Handle scalar case.  */
+ (if (INTEGRAL_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (ctype)
+ && !TYPE_UNSIGNED (ctype)
+ && canonicalize_math_after_vectorization_p ()
+ && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (stype); })))
+ /* Handle vector case with a scalar immediate.  */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && !VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+  && wi::eq_p (wi::to_wide (@1), TYPE_PRECISION (stype) - 1))
+  (convert:bt (gt:bt @0 { build_zero_cst (ctype); })))
+ /* Handle vector case with a vector immediate.   */
+ (if (VECTOR_INTEGER_TYPE_P (ctype)
+ && VECTOR_TYPE_P (stype)
+ && !TYPE_UNSIGNED (ctype)
+ && uniform_vector_p (@1))
+  (with { tree cst = vector_cst_elt (@1, 0);
+ tree t = TREE_TYPE (cst); }
+   (if (wi::eq_p (wi::to_wide (cst), TYPE_PRECISION (t) - 1))
+(convert:bt (gt:bt @0 { build_zero_cst (ctype); })
+
 /* Fold (C1/X)*C2 into (C1*C2)/X.  */
 (simplify
  (mult (rdiv@3 REAL_CST@0 @1) REAL_CST@2)
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
new file mode 100644
index 
..fc0157cbc5c7996b481f2998bc30176c96a669bb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -0,0 +1,19 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 --save-temps -fdump-tree-optimized" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 31;
+}
+
+void fun2(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 30;
+}
+
+/* { dg-final { scan-tree-dump-times {\s+>\s+\{ 0, 0, 0, 0 \}} 1 optimized } } 
*/
+/* { dg-final { scan-tree-dump-not {\s+>>\s+31} optimized } } */
diff --git a/gcc/testsuite/gcc.dg/signbit-3.c b/gcc/testsuite/gcc.dg/signbit-3.c
new file mode 100644
index 
..19e9c06c349b3287610f817628f00938ece60bf7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/signbit-3.c
@@ -0,0 +1,13 @@
+/* { dg-do assemble } */
+/* { dg-options "-O1 --save-temps -fdump-tree-optimized" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 31;
+}
+
+/* { dg-final { scan-tree-dump-times {\s+>\s+0;} 1 optimized } } */
+/* { dg-final { scan-tree-dump-not {\s+>>\s+31} optimized } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/signbit-1.c 
b/gcc/testsuite/gcc.target/aarch64/signbit-1.c
new file mode 100644
index 
..3ebfb0586f37de29cf58635b27fe48503714447e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/signbit-1.c
@@ -0,0 +1,18 @@
+/* { dg-do assemble } */
+/* { dg-options "-O3 --save-temps" } */
+
+#include 
+
+void fun1(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 31;
+}
+
+void fun2(int32_t *x, int n)
+{
+for (int i = 0; i < (n & -16); i++)
+  x[i] = (-x[i]) >> 30;
+}
+
+/* { dg-final { scan-assembler-times {\tcmgt\t} 1 } } */


-- 
diff --git a/gcc/match.pd b/gcc/match.pd
index 7d2a24dbc5e9644a09968f877e12a824d8ba1caa..581436fe36dbacdcb0c2720b7190c96d14398143 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -826,6 +826,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 { tree utype = unsigned_type_for (type); }
 (convert 

Re: [RFC] More jump threading restrictions in the presence of loops.

[Michael Matz via Gcc-patches]

Hello,

On Tue, 5 Oct 2021, Richard Biener wrote:

> > First notice that this doesn't have an empty latch block to start with 
> > (in fact, there is no separate latch block at all), so the loop 
> > optimizers haven't been initialized for simple latches at this point.  
> > Still, I would say that even then we want to be careful with the latch 
> > edge, as putting code onto it will most probably create a problem 
> > downstream once we _do_ want to intialize the loop optimizers for 
> > simple latches.  So, that we are careful here is okay, we are just too 
> > careful in this specific case.
> 
> Not sure if the argument about empty or not empty latches is important...

In this case it's not (as there are no separate latches anyway), but 
generally a latch that is already non-empty (i.e. problematic) only 
becomes more non-empty, so doing the threading doesn't introduce that 
specific problem.

> > > There's a pretty obvious jump thread in there.  3->4->5.
> > >
> > > We used to allow this, but it's currently being rejected and I'm not
> > > sure it should.
> > >
> > > In simplest terms we're threading from inside the loop, through the
> > > latch to a point outside the loop.  At first glance, that seems safe.
> 
> All threadings that start inside the loop and end outside of it are OK
> in principle.  Even if the path crosses the latch or the header.
> 
> We _might_ end up creating a loop with multiple exits though.

And entries (and hence irreducable loops)!  That's why I also added the 
piece about "all of B2..Bn-1 don't contain jumps back into the loop".  
I'm not sure if candidate paths going into our threader can have this 
problem, but if they have then you also don't want to do the block 
copying.

> > (a) while the thread is through the latch block, it's _not_ through the
> > latch edge (which is 4->3).  That would create the problem, so here
> > we're fine.
> > (b) even if it were through the latch edge, and would be followed by
> > to-be-copied instructions (and hence fill the latch edge) the ultimate
> > end of the path is outside the loop, so all the edges and blocks that
> > would now carry instructions would also be outside the loop, and hence
> > be no problem
> 
> Yep.
> 
> > Now, capture this precisely ;-)
> 
> I tried to capture this with
> 
> +  // The path should either start and end in the same loop or exit the
> +  // loop it starts in but never enter a loop.  This also catches
> +  // creating irreducible loops, not only rotation.
> +  if (entry->src->loop_father != exit->dest->loop_father
> +  && !flow_loop_nested_p (exit->src->loop_father,
> + entry->dest->loop_father))
> +{
> +  cancel_thread (, "Path rotates loop");
> +  return true;
> +}
> 
> it's not really necessary to have (simple) latches to argue about this
> I think.

Correct.  I don't think the above captures the re-entry problem (when 
intermediary blocks contain jumps inside the loop), the one I'm not sure 
we even have, but otherwise I think it does capture the (a) and (b) parts.


Ciao,
Michael.

[PATCH] c++: Implement C++23 P2242R3 - Non-literal variables (and labels and gotos) in constexpr functions

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch implements C++23 P2242R3 - Non-literal variables
(and labels and gotos) in constexpr functions.
I think it is mostly straightforward, don't diagnose certain
statements/declarations just because of their presence in
constexpr/consteval functions, but (except for the non-literal type
var declarations which ought to be caught by e.g. constructor or
destructor call during evaluation not being constexpr and for
labels which are now always allowed) diagnose it during constexpr
evaluation.

The only unclear thing to me is "a control flow that passes through a
declaration".  The patch implements diagnostics when encountering a
DECL_EXPR for such variables.  But because constexpr/consteval functions
support switch statements, another thing that can happen is jump over
such a declaration.  Consider e.g. following testcase (not included
in the patch).  When evaluating foo (12) or bar (12) the patch
accepts those as constant expressions, eventhough it jumps across such
declarations.  For baz (12) and corge (12) it rejects them not
because of jumping across such declarations, but because those
static or thread_local variables aren't initialized with constant
expressions and are accessed.  If baz/corge is modified not to have
const keyword, they are rejected because the vars aren't aren't const.
If they have const keyword and are initialized by constant expression,
accesses to those vars are accepted.  Is that ok?

So far regtested with
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make -j32 -k check-g++
ok for trunk if it passes full bootstrap/regtest?

// { dg-do compile }
// { dg-options "-std=c++2b" }

int qux ();

constexpr int
foo (int x)
{
  switch (x)
{
  static int bar = qux ();
case 12:
  return 1;
}
  return 0;
}

constexpr int
bar (int x)
{
  switch (x)
{
  thread_local int bar = qux ();
case 12:
  return 1;
}
  return 0;
}

constexpr int
baz (int x)
{
  switch (x)
{
  static const int bar = qux ();// { dg-message "'bar' was not 
initialized with a constant expression" }
case 12:
  return bar;
}
  return 0;
}

constexpr int
corge (int x)
{
  switch (x)
{
  const thread_local int bar = qux ();  // { dg-message "'bar' was not 
initialized with a constant expression" }
case 12:
  return bar;
}
  return 0;
}

constexpr int a = foo (12);
constexpr int b = bar (12);
constexpr int c = baz (12); // { dg-error "the value of 'bar' is 
not usable in a constant expression" }
constexpr int d = corge (12);   // { dg-error "the value of 'bar' is 
not usable in a constant expression" }


2021-10-05  Jakub Jelinek  

gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): For -std=c++23 predefine
__cpp_constexpr to 202103L rather than 201907L.
gcc/cp/
* parser.c (cp_parser_jump_statement): Implement C++23 P2242R3.
Allow goto expressions in constexpr function bodies for C++23.
Adjust error message for older standards to mention it.
* decl.c (start_decl): Allow static and thread_local declarations
in constexpr function bodies for C++23.  Adjust error message for
older standards to mention it.
* constexpr.c (ensure_literal_type_for_constexpr_object): Allow
declarations of variables with non-literal type in constexpr function
bodies for C++23.  Adjust error message for older standards to mention
it.
(cxx_eval_constant_expression) : Diagnose declarations
of initialization of static or thread_local vars.
(cxx_eval_constant_expression) : Diagnose goto
statements for C++23.
(potential_constant_expression_1) : Allow declarations
of static and thread_local vars for C++23.
(potential_constant_expression_1) : Allow labels for
C++23.
gcc/testsuite/
* g++.dg/cpp23/feat-cxx2b.C: Expect __cpp_constexpr 202103L rather
than 201907L.
* g++.dg/cpp23/constexpr-nonlit1.C: New test.
* g++.dg/cpp23/constexpr-nonlit2.C: New test.
* g++.dg/cpp23/constexpr-nonlit3.C: New test.
* g++.dg/diagnostic/constexpr1.C: Only expect some diagnostics for
c++20_down.
* g++.dg/cpp1y/constexpr-label.C: Likewise.
* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
* g++.dg/cpp2a/constexpr-try5.C: Likewise.  Adjust some expected
wording.
* g++.dg/cpp2a/constexpr-dtor3.C: Likewise.
* g++.dg/cpp2a/consteval3.C: Likewise.  Add effective target c++20
and remove dg-options.

--- gcc/c-family/c-cppbuiltin.c.jj  2021-09-21 23:31:01.016248936 +0200
+++ gcc/c-family/c-cppbuiltin.c 2021-10-05 12:54:29.898321379 +0200
@@ -1052,7 +1052,8 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_init_captures=201803L");
  cpp_define (pfile, "__cpp_generic_lambdas=201707L");
  cpp_define (pfile, "__cpp_designated_initializers=201707L");
- cpp_define (pfile, 

[committed] gfortran.dg/gomp/pr43711.f90: Change dg-* for XFAIL->PASS

[Tobias Burnus]

Adapt testcase to better catch the current message
and expected follow-up messages + use the proper
dg-*. — Result: XFAIL changed to PASS.

Committed as r12-4185.

Probably some other testcases could be checked as well.
Maybe we also find some real & unfixed bugs that way.

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 7f4192dd3d84cb3f6584ae847eae18519d1eb76d
Author: Tobias Burnus 
Date:   Tue Oct 5 14:28:10 2021 +0200

gfortran.dg/gomp/pr43711.f90: Change dg-* for XFAIL->PASS

gcc/testsuite/
* gfortran.dg/gomp/pr43711.f90: Add dg-error + dg-prune-output,
remove dg-excess-errors to change XFAIL to PASS.

diff --git a/gcc/testsuite/gfortran.dg/gomp/pr43711.f90 b/gcc/testsuite/gfortran.dg/gomp/pr43711.f90
index e47e586ea65..d790e3e6d86 100644
--- a/gcc/testsuite/gfortran.dg/gomp/pr43711.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/pr43711.f90
@@ -11,8 +11,8 @@ program NF03_2_5_2_1a
  print *, 'FAIL'
   !$omp section
  print *, 'FAIL'
-  !$omp end sections nowait nowait ! { dg-error "Unexpected junk" }
-   !$omp end parallel
-end program NF03_2_5_2_1a
+  !$omp end sections nowait nowait ! { dg-error "Unexpected junk after NOWAIT clause" }
+   !$omp end parallel  ! { dg-error "Unexpected !.OMP END PARALLEL statement" }
+end program NF03_2_5_2_1a  ! { dg-error "Unexpected END statement" }
 
-! { dg-excess-errors "Unexpected" }
+! { dg-prune-output "Unexpected end of file" }

Re: [PATCH 3/N] Come up with casm global state.

[Richard Biener via Gcc-patches]

On Mon, Oct 4, 2021 at 1:13 PM Martin Liška  wrote:
>
> On 9/22/21 11:59, Richard Biener wrote:
> > On Thu, Sep 16, 2021 at 3:12 PM Martin Liška  wrote:
> >>
> >> This patch comes up with asm_out_state and a new global variable casm.
> >>
> >> Tested on all cross compilers.
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> >
> >  * output.h (struct asm_out_file): New struct that replaces a
> > ^^^
> > asm_out_state?
>
> Yes, sure!
>
> >
> > You replace a lot of asm_out_file - do we still need the macro then?
> > (I'd have simplified the patch leaving that replacement out at first)
>
> Well, I actually replaced only a very small fraction of the usage of 
> asm_out_file.
>
> $ git grep asm_out_file | grep -v ChangeLog | wc -l
>
> 1601
>
>
> So I think we should live with the macro for some time ...
>
> >
> > You leave quite some global state out of the struct that is obviously
> > related, in the diff I see object_block_htab for example.
>
> Yes, I'm aware of it. Can we do that incrementally?
>
> > Basically
> > everything initialized in init_varasm_once is a candidate (which
> > then shows const_desc_htab and shared_constant_pool as well
> > as pending_assemble_externals_set).
>
> Well, these would probably need a different header file (or another #include 
> ... must
> be added before output.h :// ).
>
> > For the goal of outputting
> > early DWARF to another file the state CTOR could have a mode
> > to not initialize those parts or we could have asm-out-state-with-sections
> > as base of asm-out-state.
>
> Yes, right now asm_out_state ctor is minimal:
>
>asm_out_state (): out_file (NULL), in_section (NULL),
>  sec ({}), anchor_labelno (0), in_cold_section_p (false)
>{
>  section_htab = hash_table::create_ggc (31);
>}
>
> >
> > In the end there will be a target part of the state so I think
> > construction needs to be defered to the target which can
> > derive from asm-out-state and initialize the part it needs.
> > That's currently what targetm.asm_out.init_sections () does
> > and we'd transform that to a targetm.asm_out.create () or so.
> > That might already be necessary for the DWARF stuff.
>
> So what do you want to with content of init_varasm_once function?

It goes away ;)  Or rather becomes the invocation of the
asm-out-state CTOR via the target hook.

> >
> > That said, dealing with the target stuff piecemail is OK, but maybe
> > try to make sure that init_varasm_once is actually identical
> > to what the CTOR does?
>
> So you want asm_out_state::asm_out_state doing what we current initialize
> in init_varasm_once, right?

Yes, asm_out_state should cover everything initialized in init_varasm_once
(and the called targetm.asm_out.init_sections).

targetm.asm_out.init_sections would become

asm_out_state *init_sections ();

where the target can derive from asm_out_state (optionally) and
allocates the asm-out-state & invokes the CTORs.  The middle-end
visible asm_out_state would contain all the tables initialized in
init_varasm_once.

I'm not sure if doing it piecemail is good - we don't want to touch
things multiple times without good need and it might be things
turn out not be as "simple" as the above plan sounds.

I would suggest to try the conversion with powerpc since it
seems to be the only target with two different implementations
for the target hook.

The

static GTY(()) section *read_only_data_section;
static GTY(()) section *private_data_section;
static GTY(()) section *tls_data_section;
static GTY(()) section *tls_private_data_section;
static GTY(()) section *read_only_private_data_section;
static GTY(()) section *sdata2_section;

section *toc_section = 0;

could become #defines to static_cast
(casm)->section_name
and there'd be

class rs6000_asm_out_state : public asm_out_state
{
... add stuff ...
}

in rs6000/xcoff.h and rs6000/sysv4.h and some generic rs6000 header as well
(adding no fields) and the target hook would basically do

 return ggc_new rs6000_asm_state ();

(OK, ggc_alloc + placement new I guess).  The default hook just
creates asm_out_state.

Richard.

> Thanks,
> Cheers,
> Martin
>
>
> >
> > Richard.
> >
> >> Thanks,
> >> Martin
>

Re: [gimple-isel] Remove redundant if condition

[Richard Biener via Gcc-patches]

On Tue, Oct 5, 2021 at 9:11 AM Prathamesh Kulkarni via Gcc-patches
 wrote:
>
> Hi,
> In gimple_expand_vec_cond_expr:
>
>   icode = get_vcond_icode (mode, cmp_op_mode, unsignedp);
>   if (icode == CODE_FOR_nothing)
> {
>   if (tcode == LT_EXPR
>   && op0a == op0)
> {
>   /* A VEC_COND_EXPR condition could be folded from EQ_EXPR/NE_EXPR
>  into a constant when only get_vcond_eq_icode is supported.
>  Try changing it to NE_EXPR.  */
>   tcode = NE_EXPR;
> }
>   if ((tcode == EQ_EXPR || tcode == NE_EXPR)
>   && direct_internal_fn_supported_p (IFN_VCONDEQ, TREE_TYPE (lhs),
>  TREE_TYPE (op0a),
>  OPTIMIZE_FOR_BOTH))
> {
>   tree tcode_tree = build_int_cst (integer_type_node, tcode);
>   return gimple_build_call_internal (IFN_VCONDEQ, 5, op0a, op0b, op1,
>  op2, tcode_tree);
> }
> }
>
>   if (icode == CODE_FOR_nothing)
> {
>   gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0))
>   && can_compute_op0
>   && (get_vcond_mask_icode (mode, TYPE_MODE (TREE_TYPE (op0)))
>   != CODE_FOR_nothing));
>   return gimple_build_call_internal (IFN_VCOND_MASK, 3, op0, op1, op2);
> }
>
> It seems the second check for icode == COND_FOR_nothing is redundant,
> since icode is not reassigned in the previous block ?
> The attached patch removes the second if condition.
> OK to commit after bootstrap+test ?
>
OK.

> Thanks,
> Prathamesh

Re: [PATCH RFA] vec: Fix --enable-gather-detailed-mem-stats

[Richard Biener via Gcc-patches]

On Tue, Oct 5, 2021 at 1:27 PM Richard Biener
 wrote:
>
> On Mon, Oct 4, 2021 at 8:28 PM Jason Merrill via Gcc-patches
>  wrote:
> >
> > When r12-4038 introduced the global auto_vec save_opt_decoded_options,
> > it broke compilers configured with --enable-gather-detailed-mem-stats,
> > due to the memory descriptors getting discarded before the auto_vec was
> > destroyed.  Attached below are two approaches to making this work,
> > either by using the init_priority attribute, or turning vec_mem_desc
> > into a singleton function.  I prefer the first one, primarily because it
> > doesn't require auto_vec variables to force immediate allocation.  It
> > relies on a G++ extension, but I figure that's OK for code that is only
> > exercised with a debugging configure flag.
> >
> > Thoughts?  Either one OK for trunk?
>
> Hmm, isn't the way to fix this to turn the global auto_vec into
> vec<> *x and allocate it at runtime (thus explicitly mange its
> lifetime?).  We don't want global CTORs/DTORs in general
> because of startup cost and of course those pesky ordering issues...

Oh, and maybe we can make

 static mem_alloc_description  vec_mem_desc;

statically initialized with some C++?  (constexpr? constinit? whatever?)

> Richard.

Re: [PATCH RFA] vec: Fix --enable-gather-detailed-mem-stats

[Richard Biener via Gcc-patches]

On Mon, Oct 4, 2021 at 8:28 PM Jason Merrill via Gcc-patches
 wrote:
>
> When r12-4038 introduced the global auto_vec save_opt_decoded_options,
> it broke compilers configured with --enable-gather-detailed-mem-stats,
> due to the memory descriptors getting discarded before the auto_vec was
> destroyed.  Attached below are two approaches to making this work,
> either by using the init_priority attribute, or turning vec_mem_desc
> into a singleton function.  I prefer the first one, primarily because it
> doesn't require auto_vec variables to force immediate allocation.  It
> relies on a G++ extension, but I figure that's OK for code that is only
> exercised with a debugging configure flag.
>
> Thoughts?  Either one OK for trunk?

Hmm, isn't the way to fix this to turn the global auto_vec into
vec<> *x and allocate it at runtime (thus explicitly mange its
lifetime?).  We don't want global CTORs/DTORs in general
because of startup cost and of course those pesky ordering issues...

Richard.

Re: [RFC] More jump threading restrictions in the presence of loops.

[Richard Biener via Gcc-patches]

On Mon, Oct 4, 2021 at 6:29 PM Michael Matz  wrote:
>
> Hello,
>
> On Mon, 4 Oct 2021, Jeff Law wrote:
>
> > And just in case it got lost.  Here's the analysis on 960218-1 on visium:
> >
> > We've got this going into ethread:
> >
> > int f (int x)
> > {
> >   int D.1420;
> >   int a;
> >
> > ;;   basic block 2, loop depth 0, maybe hot
> > ;;prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   ENTRY (FALLTHRU,EXECUTABLE)
> >   a_4 = ~x_3(D);
> >   goto ; [INV]
> > ;;succ:   4 (FALLTHRU,EXECUTABLE)
> >
> > ;;   basic block 3, loop depth 1, maybe hot
> > ;;prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   4 (TRUE_VALUE,EXECUTABLE)
> >   gl = a_1;
> > ;;succ:   4 (FALLTHRU,DFS_BACK,EXECUTABLE)
> >
> > ;;   basic block 4, loop depth 1, maybe hot
> > ;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   2 (FALLTHRU,EXECUTABLE)
> > ;;3 (FALLTHRU,DFS_BACK,EXECUTABLE)
> >   # a_1 = PHI 
> >   if (a_1 != 0)
> > goto ; [INV]
> >   else
> > goto ; [INV]
> > ;;succ:   3 (TRUE_VALUE,EXECUTABLE)
> > ;;5 (FALSE_VALUE,EXECUTABLE)
> >
> > ;;   basic block 5, loop depth 0, maybe hot
> > ;;prev block 4, next block 1, flags: (NEW, REACHABLE, VISITED)
> > ;;pred:   4 (FALSE_VALUE,EXECUTABLE)
> >   return;
> > ;;succ:   EXIT
> >
> > }
>
> First notice that this doesn't have an empty latch block to start with
> (in fact, there is no separate latch block at all), so the loop optimizers
> haven't been initialized for simple latches at this point.  Still, I would
> say that even then we want to be careful with the latch edge, as putting
> code onto it will most probably create a problem downstream once we _do_
> want to intialize the loop optimizers for simple latches.  So, that we are
> careful here is okay, we are just too careful in this specific case.

Not sure if the argument about empty or not empty latches is important...
> > There's a pretty obvious jump thread in there.  3->4->5.
> >
> > We used to allow this, but it's currently being rejected and I'm not
> > sure it should.
> >
> > In simplest terms we're threading from inside the loop, through the
> > latch to a point outside the loop.  At first glance, that seems safe.

All threadings that start inside the loop and end outside of it are OK
in principle.  Even if the path crosses the latch or the header.

We _might_ end up creating a loop with multiple exits though.

> Is at least the unrestricted jump threader (the one after loop optimizers)
> picking this up?
>
> Independend of that, I agree, that this specific instance of threading
> through the latch block, even though followed by to-be-copied
> instructions, is okay.  We need to determine precisely when that is okay,
> though.  In this case there are several reasons I could see why this is
> so:
> (a) while the thread is through the latch block, it's _not_ through the
> latch edge (which is 4->3).  That would create the problem, so here
> we're fine.
> (b) even if it were through the latch edge, and would be followed by
> to-be-copied instructions (and hence fill the latch edge) the ultimate
> end of the path is outside the loop, so all the edges and blocks that
> would now carry instructions would also be outside the loop, and hence
> be no problem

Yep.

> Now, capture this precisely ;-)

I tried to capture this with

+  // The path should either start and end in the same loop or exit the
+  // loop it starts in but never enter a loop.  This also catches
+  // creating irreducible loops, not only rotation.
+  if (entry->src->loop_father != exit->dest->loop_father
+  && !flow_loop_nested_p (exit->src->loop_father,
+ entry->dest->loop_father))
+{
+  cancel_thread (, "Path rotates loop");
+  return true;
+}

it's not really necessary to have (simple) latches to argue about this
I think.

> I think something like so: we have a candidate path
>
>   S -> L -> B1 (-> B2 ... Bn)
>
> (Start, Latch, Blocks 1 to n following the latch).  (I think in our
> notation that means that the jump in L is redirected to Bn, and all code
> from B1..Bn be copied, right?  Do we even support multiple blocks after
> the to-be-redirected jump?)
>
> Now if L is a latch block, but L->B1 is no latch/back edge : no
> restrictions apply.
>
> Otherwise, L->B1 is a latch/back edge (that means B1 is a loop header): if
> all of B2..Bn-1 don't contain jumps back into the loop, and Bn is outside
> the loop, then the thread is okay as well.  (B2..Bn-1 can be inside the
> loop, as long as they don't contain jumps back into the loop, after
> copying by the threader, they don't create problems: their copies will be
> placed outside the loop and won't generate side entries back into the
> loop; the copied latch edge will not be a latch edge anymore, but a loop
> exit edge).
>
> It's quite possible 

[PATCH] Make flow of option processing more readily visible

[Richard Biener via Gcc-patches]

This moves calls to various option processing stages to one place,
toplev::main.

Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.

2021-10-05  Richard Biener  

* toplev.c (no_backend): Remove global var.
(process_options): Pass in no_backend, move post_options
langhook call to toplev::main.
(do_compile): Pass in no_backend, move process_options call
to toplev::main.
(toplev::run_self_tests): Check no_backend at the caller.
(toplev::main): Call post_options and process_options
split out from do_compile, do self-tests only if
no_backend is initialized.
---
 gcc/toplev.c | 43 +++
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/gcc/toplev.c b/gcc/toplev.c
index 52337f0152f..c5001197fb8 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -104,8 +104,6 @@ along with GCC; see the file COPYING3.  If not see
 #endif
 
 static void general_init (const char *, bool);
-static void do_compile ();
-static void process_options (void);
 static void backend_init (void);
 static int lang_dependent_init (const char *);
 static void init_asm_output (const char *);
@@ -114,9 +112,6 @@ static void finalize (bool);
 static void crash_signal (int) ATTRIBUTE_NORETURN;
 static void compile_file (void);
 
-/* True if we don't need a backend (e.g. preprocessing only).  */
-static bool no_backend;
-
 /* Decoded options, and number of such options.  */
 struct cl_decoded_option *save_decoded_options;
 unsigned int save_decoded_options_count;
@@ -1233,7 +1228,7 @@ parse_alignment_opts (void)
 
 /* Process the options that have been parsed.  */
 static void
-process_options (void)
+process_options (bool no_backend)
 {
   const char *language_string = lang_hooks.name;
   /* Just in case lang_hooks.post_options ends up calling a debug_hook.
@@ -1242,12 +1237,6 @@ process_options (void)
 
   maximum_field_alignment = initial_max_fld_align * BITS_PER_UNIT;
 
-  /* Allow the front end to perform consistency checks and do further
- initialization based on the command line options.  This hook also
- sets the original filename if appropriate (e.g. foo.i -> foo.c)
- so we can correctly initialize debug output.  */
-  no_backend = lang_hooks.post_options (_input_filename);
-
   /* Some machines may reject certain combinations of options.  */
   location_t saved_location = input_location;
   input_location = UNKNOWN_LOCATION;
@@ -2150,10 +2139,8 @@ standard_type_bitsize (int bitsize)
 
 /* Initialize the compiler, and compile the input file.  */
 static void
-do_compile ()
+do_compile (bool no_backend)
 {
-  process_options ();
-
   /* Don't do any more if an error has already occurred.  */
   if (!seen_error ())
 {
@@ -2282,11 +2269,6 @@ toplev::start_timevars ()
 void
 toplev::run_self_tests ()
 {
-  if (no_backend)
-{
-  error_at (UNKNOWN_LOCATION, "self-tests incompatible with %<-E%>");
-  return;
-}
 #if CHECKING_P
   /* Reset some state.  */
   input_location = UNKNOWN_LOCATION;
@@ -2373,17 +2355,30 @@ toplev::main (int argc, char **argv)
   /* Exit early if we can (e.g. -help).  */
   if (!exit_after_options)
 {
+  /* Allow the front end to perform consistency checks and do further
+initialization based on the command line options.  This hook also
+sets the original filename if appropriate (e.g. foo.i -> foo.c)
+so we can correctly initialize debug output.  */
+  bool no_backend = lang_hooks.post_options (_input_filename);
+
+  process_options (no_backend);
+
   if (m_use_TV_TOTAL)
start_timevars ();
-  do_compile ();
+  do_compile (no_backend);
+
+  if (flag_self_test)
+   {
+ if (no_backend)
+   error_at (UNKNOWN_LOCATION, "self-tests incompatible with %<-E%>");
+ else
+   run_self_tests ();
+   }
 }
 
   if (warningcount || errorcount || werrorcount)
 print_ignored_options ();
 
-  if (flag_self_test)
-run_self_tests ();
-
   /* Invoke registered plugin callbacks if any.  Some plugins could
  emit some diagnostics here.  */
   invoke_plugin_callbacks (PLUGIN_FINISH, NULL);
-- 
2.31.1

[Aarch64] Do not define DONT_USE_BUILTIN_SETJMP

[Eric Botcazou via Gcc-patches]

Hi,

we have been using an Ada compiler for the Aarch64 architecture configured 
with SJLJ exceptions as for the other architectures for some time, and have 
not run into any problems up to now so the setting looks obsolete.

OK for the mainline?


2021-10-05  Eric Botcazou  

* config/aarch64/aarch64.h (DONT_USE_BUILTIN_SETJMP): Delete.

-- 
Eric Botcazoudiff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 2792bb29adb..f7829baefd8 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -656,10 +656,6 @@ extern unsigned aarch64_architecture_version;
 #define EH_RETURN_STACKADJ_RTX	gen_rtx_REG (Pmode, R4_REGNUM)
 #define EH_RETURN_HANDLER_RTX  aarch64_eh_return_handler_rtx ()
 
-/* Don't use __builtin_setjmp until we've defined it.  */
-#undef DONT_USE_BUILTIN_SETJMP
-#define DONT_USE_BUILTIN_SETJMP 1
-
 #undef TARGET_COMPUTE_FRAME_LAYOUT
 #define TARGET_COMPUTE_FRAME_LAYOUT aarch64_layout_frame
 

[PATCH] Amend function names with UID when dumping with TDF_UID

[Richard Biener via Gcc-patches]

The following makes sure to amend more function names with the
associated DECL_UID when dumping with TDF_UID, in particular
function names printed as part of calls and in the function header.
That allows one to more easily follow the call flow of PR102528
where coroutines cause three clones of the name 'test2' that are
not distinguishable otherwise.

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

Richard.

2021-10-05  Richard Biener  

* tree-cfg.c (dump_function_to_file): Dump the UID of the
function as part of the name when requested.
* tree-pretty-print.c (dump_function_name): Dump the UID when
requested and the langhook produced the actual name.
---
 gcc/tree-cfg.c  | 14 +++---
 gcc/tree-pretty-print.c | 11 ++-
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index 367dcfa20bf..4b4b0b52d9a 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -8127,14 +8127,22 @@ dump_function_to_file (tree fndecl, FILE *file, 
dump_flags_t flags)
fprintf (file, ",%s(%" PRIu64 ")",
 profile_quality_as_string (bb->count.quality ()),
 bb->count.value ());
- fprintf (file, ")\n%s (", function_name (fun));
+ if (dump_flags & TDF_UID)
+   fprintf (file, ")\n%sD_%u (", function_name (fun),
+DECL_UID (fndecl));
+ else
+   fprintf (file, ")\n%s (", function_name (fun));
}
 }
   else
 {
   print_generic_expr (file, TREE_TYPE (fntype), dump_flags);
-  fprintf (file, " %s %s(", function_name (fun),
-  tmclone ? "[tm-clone] " : "");
+  if (dump_flags & TDF_UID)
+   fprintf (file, " %sD.%u %s(", function_name (fun), DECL_UID (fndecl),
+tmclone ? "[tm-clone] " : "");
+  else
+   fprintf (file, " %s %s(", function_name (fun),
+tmclone ? "[tm-clone] " : "");
 }
 
   arg = DECL_ARGUMENTS (fndecl);
diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 0b5bdd78f06..81d86ebf97d 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -344,7 +344,16 @@ dump_function_name (pretty_printer *pp, tree node, 
dump_flags_t flags)
   if (CONVERT_EXPR_P (node))
 node = TREE_OPERAND (node, 0);
   if (DECL_NAME (node) && (flags & TDF_ASMNAME) == 0)
-pp_string (pp, lang_hooks.decl_printable_name (node, 1));
+{
+  pp_string (pp, lang_hooks.decl_printable_name (node, 1));
+  if (flags & TDF_UID)
+   {
+ char uid_sep = (flags & TDF_GIMPLE) ? '_' : '.';
+ pp_character (pp, 'D');
+ pp_character (pp, uid_sep);
+ pp_scalar (pp, "%u", DECL_UID (node));
+   }
+}
   else
 dump_decl_name (pp, node, flags);
 }
-- 
2.31.1

Re: [PATCH] Improve integer bit test on atomic builtin return

[Richard Biener via Gcc-patches]

On Mon, 4 Oct 2021, H.J. Lu wrote:

> commit adedd5c173388ae505470df152b9cb3947339566
> Author: Jakub Jelinek 
> Date:   Tue May 3 13:37:25 2016 +0200
> 
> re PR target/49244 (__sync or __atomic builtins will not emit 'lock 
> bts/btr/btc')
> 
> optimized bit test on atomic builtin return with lock bts/btr/btc.  But
> it works only for unsigned integers since atomic builtins operate on the
> 'uintptr_t' type.  It fails on bool:
> 
>   _1 = atomic builtin;
>   _4 = (_Bool) _1;
> 
> and signed integers:
> 
>   _1 = atomic builtin;
>   _2 = (int) _1;
>   _5 = _2 & (1 << N);
> 
> Improve bit test on atomic builtin return by converting:
> 
>   _1 = atomic builtin;
>   _4 = (_Bool) _1;
> 
> to
> 
>   _1 = atomic builtin;
>   _5 = _1 & (1 << 0);
>   _4 = (_Bool) _5;
> 
> and converting:
> 
>   _1 = atomic builtin;
>   _2 = (int) _1;
>   _5 = _2 & (1 << N);
> 
> to
>   _1 = atomic builtin;
>   _6 = _1 & (1 << N);
>   _5 = (int) _6;

Why not do this last bit with match.pd patterns (and independent on
whether _1 is defined by an atomic builtin)?  For the first suggested
transform that's likely going to be undone by folding, no?

Richard.

> gcc/
> 
>   PR middle-end/102566
>   * tree-ssa-ccp.c (optimize_atomic_bit_test_and): Handle cast
>   between atomic builtin and bit test.
> 
> gcc/testsuite/
> 
>   PR middle-end/102566
>   * g++.target/i386/pr102566-1.C: New test.
>   * gcc.target/i386/pr102566-1a.c: Likewise.
>   * gcc.target/i386/pr102566-1b.c: Likewise.
>   * gcc.target/i386/pr102566-2.c: Likewise.
> ---
>  gcc/testsuite/g++.target/i386/pr102566-1.C  |  12 ++
>  gcc/testsuite/gcc.target/i386/pr102566-1a.c | 188 
>  gcc/testsuite/gcc.target/i386/pr102566-1b.c | 107 +++
>  gcc/testsuite/gcc.target/i386/pr102566-2.c  |  14 ++
>  gcc/tree-ssa-ccp.c  | 136 +-
>  5 files changed, 452 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/g++.target/i386/pr102566-1.C
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr102566-1a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr102566-1b.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr102566-2.c
> 
> diff --git a/gcc/testsuite/g++.target/i386/pr102566-1.C 
> b/gcc/testsuite/g++.target/i386/pr102566-1.C
> new file mode 100644
> index 000..6e33298d8bf
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/i386/pr102566-1.C
> @@ -0,0 +1,12 @@
> +/* { dg-do compile { target c++11 } } */
> +/* { dg-options "-O2" } */
> +
> +#include 
> +
> +bool tbit(std::atomic )
> +{
> +  return i.fetch_or(1, std::memory_order_relaxed) & 1;
> +}
> +
> +/* { dg-final { scan-assembler-times "lock;?\[ \t\]*btsl" 1 } } */
> +/* { dg-final { scan-assembler-not "cmpxchg" } } */
> diff --git a/gcc/testsuite/gcc.target/i386/pr102566-1a.c 
> b/gcc/testsuite/gcc.target/i386/pr102566-1a.c
> new file mode 100644
> index 000..a915de354e5
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr102566-1a.c
> @@ -0,0 +1,188 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +void bar (void);
> +
> +__attribute__((noinline, noclone)) int
> +f1 (int *a, int bit)
> +{
> +  int mask = 1 << bit;
> +  return (__sync_fetch_and_or (a, mask) & mask) != 0;
> +}
> +
> +__attribute__((noinline, noclone)) int
> +f2 (int *a, int bit)
> +{
> +  int mask = 1 << bit;
> +  int t1 = __atomic_fetch_or (a, mask, __ATOMIC_RELAXED);
> +  int t2 = t1 & mask;
> +  return t2 != 0;
> +}
> +
> +__attribute__((noinline, noclone)) long int
> +f3 (long int *a, int bit)
> +{
> +  long int mask = 1l << bit;
> +  return (__atomic_fetch_or (a, mask, __ATOMIC_SEQ_CST) & mask) == 0;
> +}
> +
> +__attribute__((noinline, noclone)) int
> +f4 (int *a)
> +{
> +  int mask = 1 << 7;
> +  return (__sync_fetch_and_or (a, mask) & mask) != 0;
> +}
> +
> +__attribute__((noinline, noclone)) int
> +f5 (int *a)
> +{
> +  int mask = 1 << 13;
> +  return (__atomic_fetch_or (a, mask, __ATOMIC_RELAXED) & mask) != 0;
> +}
> +
> +__attribute__((noinline, noclone)) int
> +f6 (int *a)
> +{
> +  int mask = 1 << 0;
> +  return (__atomic_fetch_or (a, mask, __ATOMIC_SEQ_CST) & mask) != 0;
> +}
> +
> +__attribute__((noinline, noclone)) void
> +f7 (int *a, int bit)
> +{
> +  int mask = 1 << bit;
> +  if ((__sync_fetch_and_xor (a, mask) & mask) != 0)
> +bar ();
> +}
> +
> +__attribute__((noinline, noclone)) void
> +f8 (int *a, int bit)
> +{
> +  int mask = 1 << bit;
> +  if ((__atomic_fetch_xor (a, mask, __ATOMIC_RELAXED) & mask) == 0)
> +bar ();
> +}
> +
> +__attribute__((noinline, noclone)) int
> +f9 (int *a, int bit)
> +{
> +  int mask = 1 << bit;
> +  return (__atomic_fetch_xor (a, mask, __ATOMIC_SEQ_CST) & mask) != 0;
> +}
> +
> +__attribute__((noinline, noclone)) int
> +f10 (int *a)
> +{
> +  int mask = 1 << 7;
> +  return (__sync_fetch_and_xor (a, mask) & mask) != 0;
> +}
> +
> +__attribute__((noinline, noclone)) int
> +f11 (int *a)
> +{
> +  int mask = 1 << 13;
> +  return (__atomic_fetch_xor (a, 

Re: [PATCH] gcov: make profile merging smarter

[Richard Biener via Gcc-patches]

On Mon, Oct 4, 2021 at 1:32 PM Martin Liška  wrote:
>
> On 10/4/21 13:16, Richard Biener wrote:
> > I meant in merge_one_data do not check ->stamp or ->checksum but instead 
> > rely
> > on the counter merging code to detect mismatches (there's read_mismatch and
> > read_error).  There's multiple things we can do when we run into those:
> >
> >   - when we did not actually merged any counter yet we could issue the
> > warning as before and drop the old data on the floor
> >   - when we_did_  merge some counters already we could hard-error
> > (I suppose we can't roll-back merging that took place already)
> >   - we could do the merging two-stage, first see whether the data matches
> > and only if it did perform the merging
>
> I've got your point, you are basically suggesting a fine grained merging
> (function based). Huh, I don't like it much as it's typically a mistake
> in the build setup that 2 objects (with a different checksum) want to emit
> profile to the same .gcda file.

I agree, it's usually a mistake.

> My patch handles the obvious situation where an object file is built exactly
> the same way (so no e.g. -O0 and -O2).

Yeah, but then the two profiles may not be related at all ...

> >
> > Note that all of the changes (including yours) have user-visible effects and
> > the behavior is somewhat unobvious.  Not merging when the object was
> > re-built is indeed the most obvious behavior so I'm not sure it's a good
> > idea.  A new env variable to say whether to simply keep the_old_  data
> > when merging in new data isn't possible would be another "fix" I guess?
>
> Even for a situation when checksum matches, but the timestamp is different?
> Sure, we can provide env. variables that can tweak the behavior.

I suppose another distinguishing factor might be the name of the executable.

But yeah, in the end it's a fishy area ...

So I guess your originally posted patch might be the best way to go - can you
try to amend the documentation as for the behavior with respect to
re-compiling and profile merging?  I suppose that if you re-compile just
a single .o you currently merge into all the other .o file counters but _not_
into the newly compiled old counters.  That would make coverage off
as well for incremental re-compiling?

I only can find

@item
Run the program on a representative workload to generate the arc profile
information.  This may be repeated any number of times.  You can run
concurrent instances of your program, and provided that the file system
supports locking, the data files will be correctly updated.  Unless
a strict ISO C dialect option is in effect, @code{fork} calls are
detected and correctly handled without double counting.

but that's under -coverage, not sure if there's a better place to amend.

Note I see there's -fprofile-dir which eventually can be used to "fix"
the SPEC issue as well?

Richard.

> Cheers,
> Martin
>

Re: [committed] libstdc++: Support printing volatile pointers (P1147R1)

[Daniel Krügler via Gcc-patches]

Am Di., 5. Okt. 2021 um 10:55 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> To avoid needing to export a new symbol from the library (for now) the
> new member function uses __attribute__((always_inline)).
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ostream (operator<<(const volatile void*)):
> Add new overload, as per P1147R1.
> * testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc:
> New test.
>
> Tested powerpc64le-linux. Committed to trunk.

I think the test is insufficient, because it will succeed on every
library implementation regardless of the new feature. Without the new
feature it will select the unexpected operator<<(bool) overload and
just print "1".

- Daniel

[committed] libstdc++: Fix testcase for newly-implemented C++20 semantics [PR102535]

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

PR c++/102535
* testsuite/20_util/is_trivially_constructible/value.cc: Adjust
expected value for C++20.

Tested powerpc64le-linux. Committed to trunk.

commit 7646847df71e57edca5ec5b8c3c3dc4550dcb49d
Author: Jonathan Wakely 
Date:   Tue Oct 5 09:32:11 2021

libstdc++: Fix testcase for newly-implemented C++20 semantics [PR102535]

libstdc++-v3/ChangeLog:

PR c++/102535
* testsuite/20_util/is_trivially_constructible/value.cc: Adjust
expected value for C++20.

diff --git a/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc 
b/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
index 488ea7585ff..fd1fbb07ecb 100644
--- a/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
+++ b/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
@@ -105,7 +105,7 @@ void test01()
   static_assert(test_property(true), "");
   static_assert(test_property(false), "");
+   PODType, int, int>(__cplusplus >= 202002L), "");
   static_assert(test_property(false), "");
   static_assert(test_property

[committed] libstdc++: Add noexcept to some std::function internals

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

* include/bits/std_function.h (_Any_data::_M_access): Add
noexcept.
(_Function_base::_Base_manager::_M_get_pointer): Likewise.
(_Function_base::_Base_manager::_M_not_empty_function):
Likewise.

Tested powerpc64le-linux. Committed to trunk.

commit 9665c2e76849c8e0066c6660779ae082fce67ea8
Author: Jonathan Wakely 
Date:   Mon Oct 4 15:22:58 2021

libstdc++: Add noexcept to some std::function internals

libstdc++-v3/ChangeLog:

* include/bits/std_function.h (_Any_data::_M_access): Add
noexcept.
(_Function_base::_Base_manager::_M_get_pointer): Likewise.
(_Function_base::_Base_manager::_M_not_empty_function):
Likewise.

diff --git a/libstdc++-v3/include/bits/std_function.h 
b/libstdc++-v3/include/bits/std_function.h
index 3dda820bd1a..55738440949 100644
--- a/libstdc++-v3/include/bits/std_function.h
+++ b/libstdc++-v3/include/bits/std_function.h
@@ -82,17 +82,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   union [[gnu::may_alias]] _Any_data
   {
-void*   _M_access()   { return &_M_pod_data[0]; }
-const void* _M_access() const { return &_M_pod_data[0]; }
+void*   _M_access()   noexcept { return &_M_pod_data[0]; }
+const void* _M_access() const noexcept { return &_M_pod_data[0]; }
 
 template
   _Tp&
-  _M_access()
+  _M_access() noexcept
   { return *static_cast<_Tp*>(_M_access()); }
 
 template
   const _Tp&
-  _M_access() const
+  _M_access() const noexcept
   { return *static_cast(_M_access()); }
 
 _Nocopy_types _M_unused;
@@ -131,7 +131,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
// Retrieve a pointer to the function object
static _Functor*
-   _M_get_pointer(const _Any_data& __source)
+   _M_get_pointer(const _Any_data& __source) noexcept
{
  if _GLIBCXX17_CONSTEXPR (__stored_locally)
{
@@ -217,22 +217,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
template
  static bool
- _M_not_empty_function(const function<_Signature>& __f)
+ _M_not_empty_function(const function<_Signature>& __f) noexcept
  { return static_cast(__f); }
 
template
  static bool
- _M_not_empty_function(_Tp* __fp)
+ _M_not_empty_function(_Tp* __fp) noexcept
  { return __fp != nullptr; }
 
template
  static bool
- _M_not_empty_function(_Tp _Class::* __mp)
+ _M_not_empty_function(_Tp _Class::* __mp) noexcept
  { return __mp != nullptr; }
 
template
  static bool
- _M_not_empty_function(const _Tp&)
+ _M_not_empty_function(const _Tp&) noexcept
  { return true; }
   };
 

[committed] libstdc++: Support printing volatile pointers (P1147R1)

[Jonathan Wakely via Gcc-patches]

To avoid needing to export a new symbol from the library (for now) the
new member function uses __attribute__((always_inline)).

libstdc++-v3/ChangeLog:

* include/std/ostream (operator<<(const volatile void*)):
Add new overload, as per P1147R1.
* testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc:
New test.

Tested powerpc64le-linux. Committed to trunk.

commit 96955a82f0e1624a20ea2c9953d76a20ea433c24
Author: Jonathan Wakely 
Date:   Mon Oct 4 15:22:00 2021

libstdc++: Support printing volatile pointers (P1147R1)

To avoid needing to export a new symbol from the library (for now) the
new member function uses __attribute__((always_inline)).

libstdc++-v3/ChangeLog:

* include/std/ostream (operator<<(const volatile void*)):
Add new overload, as per P1147R1.
* 
testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc:
New test.

diff --git a/libstdc++-v3/include/std/ostream b/libstdc++-v3/include/std/ostream
index ddb33feb12f..7d39c5706d5 100644
--- a/libstdc++-v3/include/std/ostream
+++ b/libstdc++-v3/include/std/ostream
@@ -251,6 +251,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   { return *this << "nullptr"; }
 #endif
 
+#if __cplusplus > 202002L
+  __attribute__((__always_inline__))
+  __ostream_type&
+  operator<<(const volatile void* __p)
+  { return _M_insert(const_cast(__p)); }
+#endif
+
   /**
*  @brief  Extracting from another streambuf.
*  @param  __sb  A pointer to a streambuf
diff --git 
a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc
 
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc
new file mode 100644
index 000..1b1a9434a95
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/volatile_ptr.cc
@@ -0,0 +1,11 @@
+// { dg-options "-std=gnu++23 -fno-inline" }
+// { dg-do link { target c++23 } }
+
+#include 
+
+int main()
+{
+  int i = 0;
+  volatile void* p = 
+  std::cout << p << std::endl;
+}

[committed] libstdc++: Update __cpp_lib_adaptor_iterator_pair_constructor value

[Jonathan Wakely via Gcc-patches]

On 01/10/21 20:43 +0100, Jonathan Wakely wrote:

This adds a feature that was recently added to the C++23 working draft.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

* include/bits/stl_queue.h
(__cpp_lib_adaptor_iterator_pair_constructor): Define for C++23, as
per P1425R4.
(queue(InputIterator, InputIterator)): Likewise.
(queue(InputIterator, InputIterator, const Alloc&)): Likewise.
* include/bits/stl_stack.h
(__cpp_lib_adaptor_iterator_pair_constructor): Likewise.
(stack(InputIterator, InputIterator)): Likewise.
(stack(InputIterator, InputIterator, const Alloc&)): Likewise.
* include/std/version (__cpp_lib_adaptor_iterator_pair_constructor):
Define.
* testsuite/23_containers/queue/cons_from_iters.cc: New test.
* testsuite/23_containers/stack/cons_from_iters.cc: New test.


I forgot to update the patch to use the final value of the feature
test macro. It should be 202106L.

Tested powerpc64le-linux. Committed to trunk.


commit 9e136807c5b5476ed02a2a40a14fe0df3c0f4f18
Author: Jonathan Wakely 
Date:   Mon Oct 4 20:16:47 2021

libstdc++: Update __cpp_lib_adaptor_iterator_pair_constructor value

I started implementing this feature before it was voted into the C++ WP,
and forgot to update the feature test macro after it was approved.

This defines it to the correct value, as specified in the C++23 draft.

libstdc++-v3/ChangeLog:

* include/bits/stl_queue.h
(__cpp_lib_adaptor_iterator_pair_constructor): Set to correct
value.
* include/bits/stl_stack.h
(__cpp_lib_adaptor_iterator_pair_constructor): Likewise.
* include/std/version
(__cpp_lib_adaptor_iterator_pair_constructor): Likewise.
* testsuite/23_containers/queue/cons_from_iters.cc: Update
expected value.
* testsuite/23_containers/stack/cons_from_iters.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/stl_queue.h b/libstdc++-v3/include/bits/stl_queue.h
index 3da65c78eb8..68cfe865147 100644
--- a/libstdc++-v3/include/bits/stl_queue.h
+++ b/libstdc++-v3/include/bits/stl_queue.h
@@ -196,7 +196,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	: c(std::move(__q.c), __a) { }
 
 #if __cplusplus > 202002L
-#define __cpp_lib_adaptor_iterator_pair_constructor 202100L
+#define __cpp_lib_adaptor_iterator_pair_constructor 202106L
 
   template>
diff --git a/libstdc++-v3/include/bits/stl_stack.h b/libstdc++-v3/include/bits/stl_stack.h
index f04fa6af479..429743f5514 100644
--- a/libstdc++-v3/include/bits/stl_stack.h
+++ b/libstdc++-v3/include/bits/stl_stack.h
@@ -171,7 +171,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   : c(std::move(__c)) { }
 
 #if __cplusplus > 202002L
-#define __cpp_lib_adaptor_iterator_pair_constructor 202100L
+#define __cpp_lib_adaptor_iterator_pair_constructor 202106L
 
   template>
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 66b3d1704b7..3d4a4142eec 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -281,7 +281,7 @@
 
 #if __cplusplus > 202002L
 // c++2b
-#define __cpp_lib_adaptor_iterator_pair_constructor 202100L
+#define __cpp_lib_adaptor_iterator_pair_constructor 202106L
 #define __cpp_lib_invoke_r 202106L
 #define __cpp_lib_is_scoped_enum 202011L
 #define __cpp_lib_string_contains 202011L
diff --git a/libstdc++-v3/testsuite/23_containers/queue/cons_from_iters.cc b/libstdc++-v3/testsuite/23_containers/queue/cons_from_iters.cc
index de0fc310c24..b826e745988 100644
--- a/libstdc++-v3/testsuite/23_containers/queue/cons_from_iters.cc
+++ b/libstdc++-v3/testsuite/23_containers/queue/cons_from_iters.cc
@@ -22,7 +22,7 @@
 
 #ifndef __cpp_lib_adaptor_iterator_pair_constructor
 #error Feature test macro for iterator pair constructors is missing in 
-#elif __cpp_lib_adaptor_iterator_pair_constructor != 202100L
+#elif __cpp_lib_adaptor_iterator_pair_constructor != 202106L
 #error Feature test macro for iterator pair constructors has wrong value in 
 #endif
 
diff --git a/libstdc++-v3/testsuite/23_containers/stack/cons_from_iters.cc b/libstdc++-v3/testsuite/23_containers/stack/cons_from_iters.cc
index 4c648926d62..ee06679d986 100644
--- a/libstdc++-v3/testsuite/23_containers/stack/cons_from_iters.cc
+++ b/libstdc++-v3/testsuite/23_containers/stack/cons_from_iters.cc
@@ -22,7 +22,7 @@
 
 #ifndef __cpp_lib_adaptor_iterator_pair_constructor
 #error Feature test macro for iterator pair constructors is missing in 
-#elif __cpp_lib_adaptor_iterator_pair_constructor != 202100L
+#elif __cpp_lib_adaptor_iterator_pair_constructor != 202106L
 #error Feature test macro for iterator pair constructors has wrong value in 
 #endif
 

[Ada] Forbids use of Compile_Time_(Error|Warning) as configuration pragma

[Pierre-Marie de Rodat via Gcc-patches]

Before this commit, in case these pragmas were used inside adc file,
gnat1 would fail with a `constraint_error` as it tries to get the
context of the pragma.

This commit induces a regression on dubious uses of these pragmas as
configuration pragmas in ads/adb files.

Review documentation on configuration pragmas list.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_prag.adb (Analyze_Pragma): Forbid use of
Compile_Time_(Error|Warning) as configuration pragma.
* doc/gnat_ugn/the_gnat_compilation_model.rst:
Compile_Time_(Error|Warning) and Compiler_Unit(_Warning) are not
configuration pragmas and shall not be listed as such.  The
following pragmas are either obsolete or undocumented:
No_Run_Time, Propagate_Exceptions, Rational, Ravenscar,
Restricted_Run_Time, Short_Descriptors, Universal_Data.  Fix
some typos (notably on Restriction_Warnings).
* doc/gnat_rm/implementation_defined_pragmas.rst: Move
Rename_Pragma documentation to alphabetical order.
* gnat_rm.texi, gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
--- a/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
+++ b/gcc/ada/doc/gnat_rm/implementation_defined_pragmas.rst
@@ -4916,43 +4916,6 @@ aspects, but is prepared to ignore the pragmas. The assertion
 policy that controls this pragma is ``Post'Class``, not
 ``Post_Class``.
 
-Pragma Rename_Pragma
-
-.. index:: Pragmas, synonyms
-
-Syntax:
-
-
-::
-
-  pragma Rename_Pragma (
-   [New_Name =>] IDENTIFIER,
-   [Renamed  =>] pragma_IDENTIFIER);
-
-This pragma provides a mechanism for supplying new names for existing
-pragmas. The ``New_Name`` identifier can subsequently be used as a synonym for
-the Renamed pragma. For example, suppose you have code that was originally
-developed on a compiler that supports Inline_Only as an implementation defined
-pragma. And suppose the semantics of pragma Inline_Only are identical to (or at
-least very similar to) the GNAT implementation defined pragma
-Inline_Always. You could globally replace Inline_Only with Inline_Always.
-
-However, to avoid that source modification, you could instead add a
-configuration pragma:
-
-.. code-block:: ada
-
-  pragma Rename_Pragma (
-   New_Name => Inline_Only,
-   Renamed  => Inline_Always);
-
-
-Then GNAT will treat "pragma Inline_Only ..." as if you had written
-"pragma Inline_Always ...".
-
-Pragma Inline_Only will not necessarily mean the same thing as the other Ada
-compiler; it's up to you to make sure the semantics are close enough.
-
 Pragma Pre
 ==
 .. index:: Pre
@@ -5737,6 +5700,43 @@ In the generic unit, the formal type is subject to all restrictions
 pertaining to remote access to class-wide types. At instantiation, the
 actual type must be a remote access to class-wide type.
 
+Pragma Rename_Pragma
+
+.. index:: Pragmas, synonyms
+
+Syntax:
+
+
+::
+
+  pragma Rename_Pragma (
+   [New_Name =>] IDENTIFIER,
+   [Renamed  =>] pragma_IDENTIFIER);
+
+This pragma provides a mechanism for supplying new names for existing
+pragmas. The ``New_Name`` identifier can subsequently be used as a synonym for
+the Renamed pragma. For example, suppose you have code that was originally
+developed on a compiler that supports Inline_Only as an implementation defined
+pragma. And suppose the semantics of pragma Inline_Only are identical to (or at
+least very similar to) the GNAT implementation defined pragma
+Inline_Always. You could globally replace Inline_Only with Inline_Always.
+
+However, to avoid that source modification, you could instead add a
+configuration pragma:
+
+.. code-block:: ada
+
+  pragma Rename_Pragma (
+   New_Name => Inline_Only,
+   Renamed  => Inline_Always);
+
+
+Then GNAT will treat "pragma Inline_Only ..." as if you had written
+"pragma Inline_Always ...".
+
+Pragma Inline_Only will not necessarily mean the same thing as the other Ada
+compiler; it's up to you to make sure the semantics are close enough.
+
 Pragma Restricted_Run_Time
 ==
 


diff --git a/gcc/ada/doc/gnat_ugn/the_gnat_compilation_model.rst b/gcc/ada/doc/gnat_ugn/the_gnat_compilation_model.rst
--- a/gcc/ada/doc/gnat_ugn/the_gnat_compilation_model.rst
+++ b/gcc/ada/doc/gnat_ugn/the_gnat_compilation_model.rst
@@ -1409,16 +1409,12 @@ recognized by GNAT::
  Check_Float_Overflow
  Check_Name
  Check_Policy
- Compile_Time_Error
- Compile_Time_Warning
- Compiler_Unit
- Compiler_Unit_Warning
  Component_Alignment
  Convention_Identifier
  Debug_Policy
- Detect_Blocking
  Default_Scalar_Storage_Order
  Default_Storage_Pool
+ Detect_Blocking
  Disable_Atomic_Synchronization
  Discard_Names
  Elaboration_Checks
@@ -1437,7 

Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors

[Richard Biener via Gcc-patches]

On Tue, 5 Oct 2021, Richard Sandiford wrote:

> Richard Biener via Gcc-patches  writes:
> > On Mon, 4 Oct 2021, Qing Zhao wrote:
> >
> >> 
> >> 
> >> > On Oct 4, 2021, at 12:19 PM, Richard Biener  wrote:
> >> > 
> >> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao 
> >> >  wrote:
> >> >> I have several questions on this fix:
> >> >> 
> >> >> 1. This fix avoided expanding ?.DEFERRED_INIT? when !tree_fits_uhwi_p 
> >> >> (TYPE_SIZE_UNIT (var_type)).
> >> >>   As a result, this call to .DEFERRED_INIT will NOT be expanded at all.
> >> > 
> >> > Yes. 
> >> 
> >> Then, should we exclude such auto init during gimplification phase?
> >
> > No, we do want to and can handle such variables just fine.
> >
> >> > 
> >> >>   Then not expanding .DEFERRED_INIT in RTL expanding phase will trigger 
> >> >> more issues in later RTL phases, this looks not correct to me. 
> >> >> (Actually, with is the patch, this testing case still failed in a later 
> >> >> RTL stage). 
> >> >> 
> >> >>   So, If we really want to avoid auto-init for VLA vectors, we should 
> >> >> not add call to .DEFERRED_INIT in gimplification phase at all. 
> >> 
> >> 
> >> >> 
> >> >> 
> >> >> 2. For the added .DEFERRED_INIT:
> >> >> 
> >> >> __SVFloat64_t f64;
> >> >> 
> >> >> f64 = .DEFERRED_INIT (POLY_INT_CST [16, 16], 2, 0);
> >> >> 
> >> >> What does ?POLY_INT_CST[16,16]? mean? Is this a constant size? If YES, 
> >> >> what?s the value of it? If Not, can we use ?memset? to expand it?
> >> > 
> >> > When the target is a register memset doesn't work. I'm not sure the 
> >> > memset expansion path will work as-is either for aggregates with vla 
> >> > parts -
> >> 
> >> Stupid question here:  what does POLY_INT_CST[16,16] mean?   It?s not a 
> >> constant? 
> >
> > It's 16 *  where the factor is determined by the hardware
> > implementation but fixed throughout the programs lifetime.  You could
> > think of the POLY_INT_CST expanding to a multiplication of 16 by a special
> > hardware register.
> >
> > For vector types the zero-init could be done using build_zero_cst and
> > the expand_assignment path.  Also the memset path should just work
> > as well.
> >
> > It's the pattern init that's a bit more complicated but I'm sure
> > Richard will sort that out.
> >
> > Note TYPE_SIZE_UNIT will honor tree_fits_poly_uint64_p but for the
> > pattern init we'd have to repeat the constant and maybe there's
> > a clever way to do this repeating just the single pattern byte.
> >
> > But as said...
> >
> >> > but I'll leave that to Richard S. to sort out. 
> >
> > ^^^
> 
> Yeah, I'm hoping to get to this in stage 3 :-)
> 
> The PR is still open until then and I agree the bypass is a good idea in
> the meantime.

Btw, I've just completed testing the following which restores init
on aarch64 (when you specify -march=armv8.3-a+sve, otherwise we
ICE on SVE register uses) and also restores the init of the VLA
case that was lost.  The only caveat is that we use zero-init
for the VLA vectors even with pattern init - that's something to
improve.  Also initializing from build_zero_cst might explode
later for poly-int sized things I cannot imagine right now ;)

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

Richard.

>From bd73fdacf72563ce27edbcdfc0d06d5378339f85 Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Tue, 5 Oct 2021 09:28:20 +0200
Subject: [PATCH] More .DEFERRED_INIT expansion rework
To: gcc-patches@gcc.gnu.org

This avoids looking at the type size and instead uses the size
as passed to .DEFERRED_INIT to determine the size of the non-MEM
to be initialized.  It also arranges for possibly poly-int
inits to always use zero-initialization rather than not initializing
and when we need to pun puns the LHS instead of the constant value.

That correctly initializes the variable-size typed array in the
testcase for PR102285 and the SVE vector in PR102587 where for
the testcase I needed to add a SVE capable -march as to not
ICE later.

2021-10-05  Richard Biener  

PR middle-end/102587
PR middle-end/102285
* internal-fn.c (expand_DEFERRED_INIT): Fall back to
zero-initialization as last resort, use the constant
size as given by the DEFERRED_INIT argument to build
the initializer.

* gcc.target/aarch64/sve/pr102587-1.c: Add -march=armv8.3-a+sve.
* gcc.target/aarch64/sve/pr102587-2.c: Likewise.
---
 gcc/internal-fn.c | 27 ++-
 .../gcc.target/aarch64/sve/pr102587-1.c   |  2 +-
 .../gcc.target/aarch64/sve/pr102587-2.c   |  2 +-
 3 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 110145218b9..78db25bbac4 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3038,19 +3038,18 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
   /* Expand this memset call.  */
   expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type));
 }
-  /* ???  Deal with poly-int sized 

[PATCH] c++: Implement C++23 P2334R1 - #elifdef/#elifndef

[Jakub Jelinek via Gcc-patches]

Hi!

This patch implements C++23 P2334R1, which is easy because Joseph has done
all the hard work for C2X already.
Unlike the C N2645 paper, the C++ P2334R1 contains one important addition
(but not in the normative text):
"While this is a new preprocessor feature and cannot be treated as a defect
report, implementations that support older versions of the standard are
encouraged to implement this feature in the older language modes as well
as C++23."
so there are different variants how to implement it.
One is in the patch below, ignores that sentence and only implements it
for -std=c++23/-std=gnu++23 like it is only implemented for -std=c23.
Another option would be to implement it also in the older GNU modes but
not in the C/CXX modes (but it would be strange if we did that just for
C++ and not for C).
Yet another option is to enable it unconditionally.
And yet another option would be to enable it unconditionally but emit
a warning (or pedwarn) when it is seen.
Note, when it is enabled for the older language modes, as Joseph wrote
in the c11-elifdef-1.c testcase, it can result e.g. in rejecting previously
valid code:
#define A
#undef B
#if 0
#elifdef A
#error "#elifdef A applied"
#endif
#if 0
#elifndef B
#error "#elifndef B applied"
#endif
Note, seems clang went the enable it unconditionally in all standard
versions of both C and C++, no warnings or anything whatsoever, so
essentially treated it as a DR that changed behavior of e.g. the above code.

2021-10-05  Jakub Jelinek  

libcpp/
* init.c (lang_defaults): Implement P2334R1, enable elifdef for
-std=c++23 and -std=gnu++23.
gcc/testsuite/
* g++.dg/cpp/elifdef-1.C: New test.
* g++.dg/cpp/elifdef-2.C: New test.
* g++.dg/cpp/elifdef-3.C: New test.

--- libcpp/init.c.jj2021-09-02 10:01:15.954715595 +0200
+++ libcpp/init.c   2021-10-05 09:55:15.010620700 +0200
@@ -122,8 +122,8 @@ static const struct lang_flags lang_defa
   /* CXX17*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1, 
1, 0,   1,  0,   1, 0,   0,   0 },
   /* GNUCXX20 */  { 1,  1,  1,  1,  1,  0,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   0,   0 },
   /* CXX20*/  { 1,  1,  1,  1,  1,  0,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   0,   0 },
-  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   0 },
-  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   0 },
+  /* GNUCXX23 */  { 1,  1,  1,  1,  1,  1,0,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   1 },
+  /* CXX23*/  { 1,  1,  1,  1,  1,  1,1,  1,   1,   1,   1,1, 
1, 0,   1,  1,   1, 0,   1,   1 },
   /* ASM  */  { 0,  0,  1,  0,  0,  0,0,  0,   0,   0,   0,0, 
0, 0,   0,  0,   0, 0,   0,   0 }
 };
 
--- gcc/testsuite/g++.dg/cpp/elifdef-1.C.jj 2021-10-05 10:00:41.410057024 
+0200
+++ gcc/testsuite/g++.dg/cpp/elifdef-1.C2021-10-05 10:00:33.110173069 
+0200
@@ -0,0 +1,3 @@
+// { dg-do preprocess { target { ! c++23 } } }
+
+#include "../../gcc.dg/cpp/c11-elifdef-1.c"
--- gcc/testsuite/g++.dg/cpp/elifdef-2.C.jj 2021-10-05 10:01:30.345372808 
+0200
+++ gcc/testsuite/g++.dg/cpp/elifdef-2.C2021-10-05 10:03:36.560608083 
+0200
@@ -0,0 +1,4 @@
+// P2334R1
+// { dg-do preprocess { target c++23 } }
+
+#include "../../gcc.dg/cpp/c2x-elifdef-1.c"
--- gcc/testsuite/g++.dg/cpp/elifdef-3.C.jj 2021-10-05 10:01:36.029293338 
+0200
+++ gcc/testsuite/g++.dg/cpp/elifdef-3.C2021-10-05 10:03:48.896435601 
+0200
@@ -0,0 +1,4 @@
+// P2334R1
+// { dg-do preprocess { target c++23 } }
+
+#include "../../gcc.dg/cpp/c2x-elifdef-1.c"

Jakub

Re: [PATCH] middle-end/102587 - avoid auto-init for VLA vectors

[Richard Sandiford via Gcc-patches]

Richard Biener via Gcc-patches  writes:
> On Mon, 4 Oct 2021, Qing Zhao wrote:
>
>> 
>> 
>> > On Oct 4, 2021, at 12:19 PM, Richard Biener  wrote:
>> > 
>> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao  
>> > wrote:
>> >> I have several questions on this fix:
>> >> 
>> >> 1. This fix avoided expanding “.DEFERRED_INIT” when !tree_fits_uhwi_p 
>> >> (TYPE_SIZE_UNIT (var_type)).
>> >>   As a result, this call to .DEFERRED_INIT will NOT be expanded at all.
>> > 
>> > Yes. 
>> 
>> Then, should we exclude such auto init during gimplification phase?
>
> No, we do want to and can handle such variables just fine.
>
>> > 
>> >>   Then not expanding .DEFERRED_INIT in RTL expanding phase will trigger 
>> >> more issues in later RTL phases, this looks not correct to me. (Actually, 
>> >> with is the patch, this testing case still failed in a later RTL stage). 
>> >> 
>> >>   So, If we really want to avoid auto-init for VLA vectors, we should not 
>> >> add call to .DEFERRED_INIT in gimplification phase at all. 
>> 
>> 
>> >> 
>> >> 
>> >> 2. For the added .DEFERRED_INIT:
>> >> 
>> >> __SVFloat64_t f64;
>> >> 
>> >> f64 = .DEFERRED_INIT (POLY_INT_CST [16, 16], 2, 0);
>> >> 
>> >> What does “POLY_INT_CST[16,16]” mean? Is this a constant size? If YES, 
>> >> what’s the value of it? If Not, can we use “memset” to expand it?
>> > 
>> > When the target is a register memset doesn't work. I'm not sure the memset 
>> > expansion path will work as-is either for aggregates with vla parts -
>> 
>> Stupid question here:  what does POLY_INT_CST[16,16] mean?   It’s not a 
>> constant? 
>
> It's 16 *  where the factor is determined by the hardware
> implementation but fixed throughout the programs lifetime.  You could
> think of the POLY_INT_CST expanding to a multiplication of 16 by a special
> hardware register.
>
> For vector types the zero-init could be done using build_zero_cst and
> the expand_assignment path.  Also the memset path should just work
> as well.
>
> It's the pattern init that's a bit more complicated but I'm sure
> Richard will sort that out.
>
> Note TYPE_SIZE_UNIT will honor tree_fits_poly_uint64_p but for the
> pattern init we'd have to repeat the constant and maybe there's
> a clever way to do this repeating just the single pattern byte.
>
> But as said...
>
>> > but I'll leave that to Richard S. to sort out. 
>
> ^^^

Yeah, I'm hoping to get to this in stage 3 :-)

The PR is still open until then and I agree the bypass is a good idea in
the meantime.

Thanks,
Richard

[Ada] Do not unconditionally inline expression functions with -gnatd.8

[Pierre-Marie de Rodat via Gcc-patches]

This is necessary when expression functions are really too large.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gcc-interface/trans.c (Subprogram_Body_to_gnu): Do not set the
DECL_DISREGARD_INLINE_LIMITS flag if -gnatd.8 is specified.diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
--- a/gcc/ada/gcc-interface/trans.c
+++ b/gcc/ada/gcc-interface/trans.c
@@ -3893,7 +3893,7 @@ Subprogram_Body_to_gnu (Node_Id gnat_node)
 
   /* If the body comes from an expression function, arrange it to be inlined
  in almost all cases.  */
-  if (Was_Expression_Function (gnat_node))
+  if (Was_Expression_Function (gnat_node) && !Debug_Flag_Dot_8)
 DECL_DISREGARD_INLINE_LIMITS (gnu_subprog_decl) = 1;
 
   /* Try to create a bona-fide thunk and hand it over to the middle-end.  */

[Ada] Add case to consider ENODEV a "file not found error"

[Pierre-Marie de Rodat via Gcc-patches]

Starting with VxWorks 21.03, a call to fopen() can now set errno to
ENODEV if a prefix of the path does not match any known device.  This
led the runtime to raise the wrong exception type when trying to a file
for which the parent directory did not exist and caused the acats
testsuite to fail. This patch adds a case to return 1 if errno has been
set to ENODEV. We don't bother with version checking as this affects
both kernel mode and RTP mode, and it does not affect runs done with
previous VxWorks versions.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sysdep.c (__gnat_is_file_not_found_error): Add else if case.diff --git a/gcc/ada/sysdep.c b/gcc/ada/sysdep.c
--- a/gcc/ada/sysdep.c
+++ b/gcc/ada/sysdep.c
@@ -907,6 +907,10 @@ __gnat_is_file_not_found_error (int errno_val)
 if (errno_val == ENOENT)
   return 1;
 #ifdef __vxworks
+/* Starting with VxWorks 21.03, the fopen() function can set errno to
+ * ENODEV when the prefix of the path does not match any known device. */
+else if (errno_val == ENODEV)
+  return 1;
 /* In the case of VxWorks, we also have to take into account various
  * filesystem-specific variants of this error.
  */

[Ada] Fix latent bug in set_end_locus_from_node

[Pierre-Marie de Rodat via Gcc-patches]

Avoid calling End_Label on the Empty node.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* gcc-interface/trans.c (set_end_locus_from_node): Check that
Handled_Statement_Sequence is not Empty before calling
End_Label, because the Empty node has no End_Label, and
depending on the exact node layout chosen by gen_il, calling
End_Label might crash, or might work OK by accident.diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
--- a/gcc/ada/gcc-interface/trans.c
+++ b/gcc/ada/gcc-interface/trans.c
@@ -10507,10 +10507,15 @@ set_end_locus_from_node (tree gnu_node, Node_Id gnat_node)
 case N_Package_Body:
 case N_Subprogram_Body:
 case N_Block_Statement:
-  gnat_end_label = End_Label (Handled_Statement_Sequence (gnat_node));
+  if (Present (Handled_Statement_Sequence (gnat_node)))
+	gnat_end_label = End_Label (Handled_Statement_Sequence (gnat_node));
+  else
+	gnat_end_label = Empty;
+
   break;
 
 case N_Package_Declaration:
+  gcc_checking_assert (Present (Specification (gnat_node)));
   gnat_end_label = End_Label (Specification (gnat_node));
   break;
 

[Ada] introduce stack scrub (strub) feature

[Pierre-Marie de Rodat via Gcc-patches]

This is the GNAT part of the patch that adds the strub attribute for
function and variable types, command-line options, passes and
adjustments to implement it, documentation, and tests.

Besides documentation, the bulk of the patch adds strub(callable) to
subprograms that the compiler may call implicitly.  The reason for
that is that, in -fstrub=strict mode, a context that requires stack
scrubbing can only call subprograms that also perform stack scrubbing,
or that are declared safe to call from strub contexts, i.e.,
strub-callable.  Subprograms that may be implicitly called, and that
are safe to call (i.e., that won't leave on the stack caller-supplied
data that ought to be scrubbed), should thus be marked with this
pragma, so that they don't prevent units from compiling with
-fstrub=strict.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* doc/gnat_rm.rst: Add...
* doc/gnat_rm/security_hardening_features.rst: New.
* doc/gnat_rm/about_this_guide.rst: Link to new chapter.
* gnat_rm.texi: Regenerate.
* gcc-interface/utils.c (handle_strub_attribute): New.
(gnat_internal_attribute_table): Add strub.
* libgnat/a-except.adb: Make Rcheck_CE_* strub-callable.
* libgnat/a-except.ads (Raise_Exception): Likewise.
(Raise_Exception_Always): Likewise.
* libgnat/s-arit128.ads (Multiply_With_Ovflo_Check128):
Likewise.
* libgnat/s-arit64.ads (Multiply_With_Ovflo_Check64):
Likewise.
* libgnat/s-secsta.ads (SS_Allocate, SS_Mark, SS_Release):
Likewise.

patch.diff.gz
Description: application/gzip

[Ada] Mark private component renaming as coming from source

[Pierre-Marie de Rodat via Gcc-patches]

This marks the local renaming generated for private components of protected
types as coming from source, so that the components are displayed when the
'info locals' command is used in GDB.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_ch9.adb (Install_Private_Data_Declarations): Copy the Sloc of
components for the local renamings as well as the Comes_From_Source
flag, and also set Warnings_Off on them.  Use Nam local variable.diff --git a/gcc/ada/exp_ch9.adb b/gcc/ada/exp_ch9.adb
--- a/gcc/ada/exp_ch9.adb
+++ b/gcc/ada/exp_ch9.adb
@@ -13796,14 +13796,15 @@ package body Exp_Ch9 is
Comp: Node_Id;
Comp_Id : Entity_Id;
Decl_Id : Entity_Id;
+   Nam : Name_Id;
 
 begin
Comp := First (Private_Declarations (Def));
while Present (Comp) loop
   if Nkind (Comp) = N_Component_Declaration then
  Comp_Id := Defining_Identifier (Comp);
- Decl_Id :=
-   Make_Defining_Identifier (Loc, Chars (Comp_Id));
+ Nam := Chars (Comp_Id);
+ Decl_Id := Make_Defining_Identifier (Sloc (Comp_Id), Nam);
 
  --  Minimal decoration
 
@@ -13818,6 +13819,14 @@ package body Exp_Ch9 is
  Set_Is_Aliased (Decl_Id, Is_Aliased (Comp_Id));
  Set_Is_Independent (Decl_Id, Is_Independent (Comp_Id));
 
+ --  Copy the Comes_From_Source flag of the component, as
+ --  the renaming may be the only entity directly seen by
+ --  the user in the context, but do not warn for it.
+
+ Set_Comes_From_Source
+   (Decl_Id, Comes_From_Source (Comp_Id));
+ Set_Warnings_Off (Decl_Id);
+
  --  Generate:
  --comp_name : comp_typ renames _object.comp_name;
 
@@ -13828,10 +13837,8 @@ package body Exp_Ch9 is
New_Occurrence_Of (Etype (Comp_Id), Loc),
  Name =>
Make_Selected_Component (Loc,
- Prefix =>
-   New_Occurrence_Of (Obj_Ent, Loc),
- Selector_Name =>
-   Make_Identifier (Loc, Chars (Comp_Id;
+ Prefix => New_Occurrence_Of (Obj_Ent, Loc),
+ Selector_Name => Make_Identifier (Loc, Nam)));
  Add (Decl);
   end if;
 

[Ada] Include errno.h in QNX specific part of the signal handling

[Pierre-Marie de Rodat via Gcc-patches]

To get access to the errno variable, we need to include errno.h.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* init.c (QNX): Add #include errno.h.diff --git a/gcc/ada/init.c b/gcc/ada/init.c
--- a/gcc/ada/init.c
+++ b/gcc/ada/init.c
@@ -2551,6 +2551,7 @@ __gnat_install_handler (void)
 #include 
 #include 
 #include 
+#include 
 #include "sigtramp.h"
 
 void